Ant Build Files Should Be Generated, As Should Project Files For IDEs
They should be generated from simple, easily editable description files
Ant wasn't around when I started my first Java project. We used Makefiles. We used elaborate Makefiles that are copied and tweaked from project to project. Cruft accumulates as time goes on. Until at one point, no one dared to touch the Makefile except between the lines:
# You can change these values SOURCES=src/com/weiqi/client/*.java src/com/weiqi/server/*.java CLASSES=classes # You should not touch anything below this line
Then Ant came along. We threw away the Makefiles. I wrote my fair share of Ant build files. Some quite elaborate. The build files are in XML, which was cool new thing back then. It was also easier to read.
Then came the IDEs. They each has their own brand of project files that are generated when you start a new project, probably using the New Project Wizard.
The problem with project files is that they don't share that well. If you check them in to source control system and check them out on a different machine, it may not work. Even if it worked, they are prone to be modified while you are working on the project, which causes them to be checked back in, causing conflicts for everybody else.
Then there is Maven, which is a step forward from Ant build files. However its XML syntax is quite cumbersome and hard to remember.
Which brings me to MPC—The Makefile, Project and Workspace Creator. It generates Makefiles, Visual Studio solution files, and workspace files for other development environments from simple, human editable, comprehensible, and maintainable description files.
We use MPC for all of our C++ projects. And everyone loved it. You know the crowd, the C++ crowd. It's not easy for us to love anything. One benefit of using MPC is that one set of description files can be used to generate the files needed by multiple IDEs and environments: solution files for Visual Studio and Makefiles for GCC and Eclipse.
It saves time and hassle. That's why we love it.
Over the last two weeks, I've seen something similar in two different places, although on a smaller scale. The first place is Google Web Toolkit, where they provide tools to generate Ant build files and Eclipse project files. The second place is Celtix, where their wsdl2java tool has an option of generating an Ant build file.
What I would like to see is for this idea to spread to all Java projects in a generic way. I mean if you include in your tar ball an Ant build file, you surely have enough information to construct IDEA, Eclipse, NetBeans project files. That information, surely can be abstracted into something simple and easy:
// MPC file: myproject.mpc
project : hibernate_project, sprint_project {
Source_Files {
//list of sources
}
Mapping_Files {
//list of mapping files
}
// etc.
}
From this file, we would generate project files for all sorts of IDEs and maybe Ant build files (maybe even Makefiles now that we don't have to maintain them):
[weiqi@gao] $ mpc.pl -type idea5 myproject.mpc Generating idea5 output using myproject.mpc Generation Time: 5s [weiqi@gao] $ mpc.pl -type eclipse32 myproject.mpc Generating eclipse32 output using myproject.mpc Generation Time: 6s [weiqi@gao] $ mpc.pl -type ant myproject.mpc Generating ant output using myproject.mpc Generation Time: 3s [weiqi@gao] $ mpc.pl -type gnumake myproject.mpc Generating gnumake output using myproject.mpc Generation Time: 3s
What do you think?
Re: Ant Build Files Should Be Generated, As Should Project Files For IDEs
Re: Ant Build Files Should Be Generated, As Should Project Files For IDEs
BuildDesk certainly looks interesting. However, it is different from what I want. What I want is generation in the reverse direction. I would like to be able to generate IntelliJ IDEA project files (and project files for other IDEs) from simple hand editable/edited description files.
For this to work, the project file formats from the various IDEs would have to be published and stable.
Re: Ant Build Files Should Be Generated, As Should Project Files For IDEs
Not as much as switching IDEs, but to allow the use of different IDEs on a project.
Use Case #1: Tom just got on a project. Rene wouldn't have to spend twenty minutes walking Tom through bootstrapping his IDEA project. (Or spend twenty minutes writing a Word document of the procedure for creating a project file: Click on the blue icon, stand up and jump to the left three times, come back and click the OK button, check the I'm sure box and click on the Go Ahead button ...
Use Case #2: Simon released his project as Open Source. He included his personal IDEA iml, ipr, and iws files. Not all developers use IDEA. And the IDEA project files are of no help to an Eclipse user, or a JBuilder user, or a NetBeans user, or an Emacs user. Being able to generate a project file for these IDEs would seem a win for the project.
Re: Ant Build Files Should Be Generated, As Should Project Files For IDEs
Maven can generate the IDE project files for you, not sure if it can generate the build.xml files, but you don't need that if you have Maven in the first place.
Check out these links:- Maven IDEA Plug-in
- Maven Eclipse Plug-in
- Netbeans Freeform Module
- Eclipse Maven Plug-in for running Maven *in* Eclipse
Re: Ant Build Files Should Be Generated, As Should Project Files For IDEs
That's very good news if it were true. However these plugins seem to be dead projects by the look of the website.
Another issue I had with Maven is its own verbosity. XML is an anti-human file format. Any tool that require the hand editing of XML files (with the exception of document oriented material, such as this comment I'm editing) provoke the most violent reaction from me.
Yet another issue I had with Maven is its out of control dependencies of itself. A couple of years ago, when I tried to install as many packages as possible from JPackage.org, there are only two thing that I did not install at the end because I'm burned out trying to figure out all the non-free dependencies. One of them is Maven (the other is NetBeans 3.)
Re: Ant Build Files Should Be Generated, As Should Project Files For IDEs
1) All of the IDE plugins are fully functional so they're not updated very often. The documentation might be a bit lacking, but generally just running eclipse:eclipse or idea:idea is sufficient.
2) We've always used the rather XML format and haven't really found it to be a big issue. A typical Maven 2 pom.xml is much smaller than a Maven 1 POM because of proper POM inheritance and better default values.
The Mevenide project gives you project.xml file editors (which are for Maven 1), but there are also coming editors for the Maven 2. There are people actively working on Eclipse and Netbeans support right now.
Neither Maven 1 nor Maven 2 has ever had any non-free dependencies, I have no idea where the JPackage and Debian guys got that from. I've spend a whole lot of hours trying to package Maven 2 for Debian but have given up now because if silly rules and akward rules and policies (for Java software).
Re: Ant Build Files Should Be Generated, As Should Project Files For IDEs
> 1) All of the IDE plugins are fully
> functional so they're not updated very
> often. The documentation might be a
> bit lacking, but generally just
> running eclipse:eclipse or idea:idea
> is sufficient.
I'm not trying to knock down Maven here. If it indeed is working that's good news. I'll give it a try and report back my findings.
I trust it that when I read the Maven documentation it would be obvious to me what "just running eclipse:eclipse" means. (As you can see I'm not a Maven user. But if it does what I want I'm willing to give it a try.)
>2) We've always used the rather XML
> format and haven't really found it to
> be a big issue. A typical Maven 2
> pom.xml is much smaller than a Maven 1
> POM because of proper POM inheritance
> and better default values.
When will Maven 2 be released?
>The Mevenide project gives you
> project.xml file editors (which are</br>
> for Maven 1), but there are also
> coming editors for the Maven 2. There
> are people actively working on Eclipse
> and Netbeans support right now.
Can I write a script to drive the editor?
>Neither Maven 1 nor Maven 2 has ever
> had any non-free dependencies, I have
> no idea where the JPackage and Debian
> guys got that from. I've spend a whole
> lot of hours trying to package Maven 2
> for Debian but have given up now
> because if silly rules and akward
> rules and policies (for Java
> software).
I went with JPackage for convenience. The fact that I can't easily get Maven installed hurts my chance of using Maven. I would very much like for this non-free nonsense to go away. And it seems people (Sun and Debian) are trying to do the right things.
Thanks for the information.
Re: Ant Build Files Should Be Generated, As Should Project Files For IDEs
(sorry for the lame replying but it's too anoying to copy and paste and then html'ize everything)
> I trust it that when I read the Maven documentation it would be obvious to me what "just running eclipse:eclipse" means. (As you can see I'm not a Maven user. But if it does what I want I'm willing to give it a try.)
Sorry, "eclipse:eclipse" means that you will run "mvn eclipse:eclipse" on the command line and it will generate the .classpath and .project files for you.
> When will Maven 2 be released?
Maven 2 was release almost a year ago and the latest release is 2.0.4. If you do give it a go, make sure you get the new Maven 2 book ("Books and Articles" on the site).
> Can I write a script to drive the editor?
No, I don't see why you would do that. What are you trying to do? Automate changes? If so we have readers and writers for the pom.xml that you can use in a plugin. The release plugin does (among other things) that.
> I went with JPackage for convenience. The fact that I can't easily get Maven installed hurts my chance of using Maven. I would very much like for this non-free nonsense to go away. And it seems people (Sun and Debian) are trying to do the right things.
Yes, I realize. That is also why I have been trying to package Maven 2 for Debian (the distro of my choice), but gave up because of their silly requirements. But I have offered my help and co-maintain any packages.