Re: Using the classpath clause in the document of a build script

[Nate]

Hi Cristian,
(CCed Scar mailing list)

Glad you like Scar. :) It hasn't seen much usage, a few people here and there. I use it for all my build stuff.

I've personally found writing a build in a Java class is the most pleasant. You could have a separate IDE project with any dependencies to solve your classpath issue. Including some code at the end of the project.yaml is ok, but you don't get code completion, etc. Eg, here is one of my more complex builds:
http://pastebin.com/PUqGeJEj
I just added the sftpUpload method today. :)

That said, you're right that the "classpath" entry for the executeCode method should needs to be fixed. I just committed a change similar to yours, can you verify it works for you? I used System.getProperty("java.class.path") rather than URLClassLoader.

Thanks for the fix!
-Nate

On Thu, Jan 10, 2013 at 1:45 PM, Cristian Plutis <c.pl...@gmail.com> wrote:

Hi,

  First of all thank you for this simple and easy to use tool! The idea and its execution are brilliant in that they expose the whole build process of a project in clear and complete details, unlike most established builders that add their own complexity instead, engulfing the actual process in a mysterious shroud.

  I tried using the tool with custom code in the document part of the project.yaml. I tried to add a jar to the classpath using the dedicated clause but it seemed to be ignored. I don't know if my code was correct but it appears the call to the method getTask() of JavaCompiler used in Scar.executeCode() needs an opt parameter of type List (containing the "-classpath " option) in order to succeed. I attached a source containing the change. 

  I hope Scar will be extended and include more features as it already looks very promising!

Regards,

Chris

[Cristian Plutis]

Happy to help! I checked the new Scar.java and my build script works perfectly. If there is anything I can do to help, I'd love to contribute.

You are absolutely right about the convenience of writing the build in Java. I wrote the code in the yaml file because I saw the last example and thought that classpath clause was really awesome and felt the urge to give it a try. Having used traditional build tools for some time my mind got stuck on the idea that a build must be described by scripts you edit with plain editors and run over and over until they get right. 

The BuildSpine class is quite complex indeed with obfuscation, native library packaging for 3 OSs and that continuation stuff. And it doesn't look much more verbose than a Groovy script either. In the long run sticking with pure Java might prove the best move from the compatibility, performance and ease of use points of view.

Btw, I didn't see the sftpUpload() in rev52 of Scar.java.

If I find a way to manage dependencies I'll start building the application I work on at my job with Scar instead of gradle. Basically all it needs is to download jars with a certain version from a Nexus repository.

I think Scar will be adopted by many projects, it just needs some time and maybe some promotion although it's already on the 4th page when googling 'java build tool'.

Good luck with your projects!

Chris

[Nate]

On Thu, Jan 10, 2013 at 10:46 PM, Cristian Plutis <c.pl...@gmail.com> wrote:

Happy to help! I checked the new Scar.java and my build script works perfectly. If there is anything I can do to help, I'd love to contribute.

Nice. :) I haven't been developing much on Spine, just occaisionally I need something small for my builds.
 

You are absolutely right about the convenience of writing the build in Java. I wrote the code in the yaml file because I saw the last example and thought that classpath clause was really awesome and felt the urge to give it a try. Having used traditional build tools for some time my mind got stuck on the idea that a build must be described by scripts you edit with plain editors and run over and over until they get right. 

executeCode is pretty neat. :) Including the code in a project.yaml is most useful for a project other projects depend on. This way when you build a project, it also builds the dependency projects. If a Java class was used for the dependency, it wouldn't know how to build it, but when the code is in the project.yaml, it does.
 

The BuildSpine class is quite complex indeed with obfuscation, native library packaging for 3 OSs and that continuation stuff. And it doesn't look much more verbose than a Groovy script either. In the long run sticking with pure Java might prove the best move from the compatibility, performance and ease of use points of view.

You can develop the build with Java and paste it in the project.yaml. Not as nice, but better than using a plain text editor.
 

Btw, I didn't see the sftpUpload() in rev52 of Scar.java.

Oops! Fixed.
 

If I find a way to manage dependencies I'll start building the application I work on at my job with Scar instead of gradle. Basically all it needs is to download jars with a certain version from a Nexus repository.

You could download JARs to the libs directory and the rest should work. If you make a nice general purpose HTTP download method we can slap it on the Scar class. :)
 

I think Scar will be adopted by many projects, it just needs some time and maybe some promotion although it's already on the 4th page when googling 'java build tool'.

I posted some stuff about Scar here:
http://www.java-gaming.org/topics/scar-simple-java-based-build-system/22840/view.html
Here we discuss the usefulness of integrating Maven and Scar:
http://www.java-gaming.org/topics/easily-deploy-jws-and-applets-with-scar/25342/view.html

-Nate

[Cristian Plutis]

If I find a way to manage dependencies I'll start building the application I work on at my job with Scar instead of gradle. Basically all it needs is to download jars with a certain version from a Nexus repository.

You could download JARs to the libs directory and the rest should work. If you make a nice general purpose HTTP download method we can slap it on the Scar class. :)

I was thinking to write another module, packaged in a different jar that would act as a front end for Ivy. In this way all the dependency resolving and downloading would be delegated while leaving Scar lean and clean. The people who need dependency management can just tack it on, as you wrote, and then configure it (add ivy to classpath, define the repository) while others are not affected. 

Chris