Jamake - Pure Java Build Tool
Hello, guys.
Once me and my friend, we have counted number of languages, dialects and syntaxes that you have to be familiar with to handle one simple web site project and I was amazed. We got numbers like 10 to 15. Java, HTML, XML (minimum 5 dialects), SQL, PHP, Python, Javascript, Ruby, Annotations... This is crazy. It is too much even for very genius programmer.
Then I thought "why ANT?". Why build project is not described in our lovely java? What about pure Java Build Tool?
Here I want to discuss with you possibility of building pure Java Build tool which will be able to do everything ANT, MAVEN, BUILDR or whatever build tool does, plus it will get all strength of Java as programming language. Imagine writing build project with all intellisense Eclipse does for your java classes, with all automation you already have for java, with simple, serial and very familiar code, with availability of thousands of useful libraries and tools. Plus, I hope it will have converting utilities like ant2jamake, buildr2jamake etc to suck existing build projects in (all business aggression goes here :-) ).
I have started project Jamake on Google Code. It is about JAVA and MAKE. Anyone wants to participate in the project can contact me directly and I will add him into the project developers team. No salary, by the way :-). I am doing it on my "free" time.
It is on the stage of conceptual design now.
I would be happy to hear ideas, suggestions or even critics.
I know that this is not a first such attempt to build such tool, but who knows, may be this time it will succeed...
---
Now about dark side. It is quite possible that it is just a stupid idea and it doesn't worse to put any energy into such project. But lets argue about it. I would be happy if you will stop me now, before spending my quality time on useless work. Bring you arguments, bring some heavy ones...
Comments
did you look at jmk (http://sourceforge.net/projects/jmk/)? if i remember correctly, you can use it in a programmatic way (not through writing a make-like file). also why did you not like http://code.google.com/p/buildobjects?
As I understand from their description, JMK is java wrapper for Unix make utility, it is still not pure java, still requires some scripting and might have problems running on Windows, it also talks most about incremental deployment rather about whole build process as "update, compile, package, deploy, test, notify, report, version, documentation" cycle. Also I didn't find good documentation on it, so I am afraid that it is not most popular tool.
As about Buildobjects, as the main weakness of this package I see the fact that it requires Java 6, I want to stay on Java 1.4 base to make it available for old and new projects. Also it is kinda expecting the "standard" project structure which we all have seen as a weakness, very rarely java (or other) projects fit the ideal directory structure. I had maybe one demo project in my over 8 years java experience. Also you might noticed that "standard" project structure is a big problem within Windows environment, Windows simply doesn't like long file names and extra dirs. The Build tool must provide here some flexibility.
jmk is pure java. But it is still a make clone, so it relies on executing external commands. I think it can be extended to run
if you are looking for something more than just make clone, then I suggest reading more about buildr since they use idioms which solve the issues you raised.
another approach is to just programmatically call ant tasks. there are several projects to do that. i think leafcutter is one. also, maybe https://gosling.dev.java.net/ will interest you. or http://code.google.com/p/pjmake/
Thank you for your inputs, Itay. I will try to go over all projects you are mentioned here.
Few words about buildr. First of all it is Ruby, another language to learn, and I consider this as VERY big weakness. With all respects to Ruby as language we all live in Java world and I believe should use and support it. The main issue is the language. Also Ruby, as I see it, is not perfect language anyway, claimed Pure Object it still suffers of Type tyranny.
I am not for making another clone. I believe that Jamake will learn tough lessons from other build tools and will be able to provide better solutions.
As about Ant, IMHO the main problem is parallelism it introduces into pretty serial world. Calling ant task from java is not yet a solution because it inherits all problems and limitations of Ant.
about java vs. ruby, generally i agree that learning ruby for the build scripts may be an obstacle. however, we have a client that uses buildr and the developers picked up ruby rather quickly and manage to do more than just copy&paste. writing code in ruby (or any other dynamic language) *will* be quicker than in java if you're willing to learn it, simply because the language offers more mechanisms and because you're not bound by type safety. from my experience, navigating the code is easy, because there is less of it and it is more intuitive, because of the dynamic nature of the language. another thing i liked about ruby is that you can re-open any class and rewrite some of its methods. this helped me fix some bugs in core buildr. in a java tool that would have meant getting the source code of the tool, patching it, compiling and using the new jar instead. in ruby it just means my build file requires (includes) a workarounds.rb file.
There are hundreds, maybe thousands of programming languages out there. Each has its cons and pros. But the question is still about if it worse to learn another, and another, and another language every time you need some tool, or framework, or UI, or automation. Although, I personally have absolutely nothing against Ruby, more than this I do consider it as very good language, I still believe that build process for java project must be described as java and not ruby.
I wouldn't position the issue here as "java vs ruby". I would simply ask "why not java?"
interesting discussion,
I think that a developer preparing a build, using *any* tool/technology/programming language should anyway get herself familiar with some type of DSL describing the (sometimes complex) build tool concepts. Semantics may change and may be atomic (like ant), lifecycle-driven(like maven) or other, but the learning curve is always there, hiding in the details.
Therefore, I think that a Java-based build tool is not necessarily easier to use than a Ruby-based one; rather, the question asked regarding build technology (a) vs. (b) should be answered according to the actual features, ease of use, length of build script/code etc.
my shneqel :)
Had a look on pjmake project.
Although it has a good starting skeleton, the project is incomplete. It is on alpha stage and has some conceptual, design and coding problems. For example it invokes javac as undocumented "com.sun.tools.javac.Main" class which is already taken off the standard java installations. Their code "Class clazz = Class.forName("com.sun.tools.javac.Main");
" doesn't run in my Eclipse with java 1.5 and java 6.
In my Jamake project already this I am doing differently. I am calling "javac" utility according to environment settings passed to the process. This will work on any computer which has any jdk installed. Even the one which is not in PATH or JAVA_HOME. Even with many of them, so build can choose one, etc.
But must say that some good ideas I will take from this project anyway.
do you have tools.jar in your classpath?
calling javac as an external process is less efficient than invoking a class method.
I will compare performance of both methods. Still the question is how better it would be comparing to the whole build process. If improvement is less than 5% it would be better to stay with execution of javac utility rather than require tools.jar to be in the classpath, I think. But if it will show big difference I will probably go for tools.jar.
---
You know, having a possibility to compile different parts of the projects set with different java compiler is still sounds sexy to me. So I am confused a bit. Let's say for now I will stay with "exec", may be later I will think about tools.jar solution.
Today I have built my first jar with Jamake. Hopefully in a month time I will have a Jamake Alpha version ready. As about javac I have decided to do following:
1. If javac is set (as name of executable) I am running the one which is set
2. If tools.jar is in the classpath I am running the com.sun.tools.javac.Main.compile
3. If none of above I am executing "javac" with a hope it is in the PATH
4. If everything fails printing out an error, smashing a glass if wine on the floor, screaming on my neighbor and terminating the whole process. :-)
I believe other build tools do the same...