Vincent Brabant's Blog

November 2003 Archives

I want an IDE that manage his projects by using Ant !

But, you are not developping with Ant, you are developping with an IDE

And when you write your project in the IDE, you can compile it, test it, debug it, deploy it.

And then, you want to put in place the daily build.

And therefore you have to build your ant build.xml file from scratch. Even if your IDE is already configured to compile, build jar, war, zip, docs, test reports, ...

Why are IDEs not using Ant to build the project ?

Then, you will have possibility to reuse what the IDE has automatically done for you.

Why not, have IDE where you can import an existing Ant project ?

That IDE would be able to create his internal structure of the project from the Ant Build.XML file.

I know that today, with NetBeans 3.5, you can compile your class by calling an Ant target. You can run your class by calling a Ant target.

Why is it very interresting ?

You are sure that the way your IDE is compiling, executing, testing your project on your local PC, is exactly the same way as the nightly build that run on the server.

But it's not yet sufficient.

Did you remember my preceding blog concerning freedom of codestyle?

Imagine now that when you use the action Commit in your IDE, it launch the target commit of your Ant file.

You can customize that target to

1. execute jalopy,
2. run checkstyle,
3. run PMD,
4. run somes metrics
5. run somes JUNIT test
6. and then
   • refuse to commit
   or
   • accept to commit
   depending of the result of checkstyle, for example, or if junit tests are broken or if metrics are bad.

It means that you are sure that the code you commited in the repository is well-formated, has up to date javadoc, is following your standards, ...

It can only enhance the quality of code commited in the CVS repository.

That would be a nice enhancement, because, today, no versionning tools permits you to refuse commit depending of somes criteria.

By having all IDE using Ant build.xml file, you will be able to work in a team where everyone can choose his IDE. You will assure that commited code is compliant with your rules.

I am happy to learn that NetBeans 3.6 will enhance integration with Ant.

What's happens with Marketing by Sun ?

• Before, you had iPlanet AppSrv 6
• then you had Sun One Application Server 7
• now, you have Java System Application Server 7/8.

Look at Java IDE:

• Before you had Forté For Java
• Then you had Sun One Studio
• Now, you have Sun Java Studio

Impossible in those conditions that people have good opinions of Sun and their products in general.

Each time you convince the commercial of your company to buy a Sun's product, it disappears of the catalog under the name.

So the conclusion of commercial is :

I don't want to buy product by Sun if they don't continue to give support to their product.

Sorry, but the product you wanted (xxx) disappears of their catalog. No more posible to buy it.

We dont want to take risk to migrate our development from Forté For Java to Sun ONE Studio.

I am really convinced that changing name of a product each time a new version is released is a very bad strategy for Sun, it it's a strategy !

Hoppefully that the future Java 1.5 is always named Java. And that the future NetBeans 3.6 is always named NetBeans 3.6

I want to continue to use my own style, even if I work in a team !!!

Why am I obliged to follow the team convention

public static final String hello = "HelloWorld";

final static public String hello = "HelloWorld";

Why am I obliged to declare variables of the class before the constructor and methods, and not after ?

Why am I obliged to put open brackets on the same line than the declaration method, If I prefer the other style where I put the open brackets on the next line.

Why have I to indent my code with 8 spaces, if I prefer two spaces only ?

Why, why, why ?

Because you are working in a team, and when you are working in a team, you are obliged to follow somes rules, otherwize it's the chaos.

I can agree with that, but I think it's possible to solve that in another way than oblige people to lose their freedom.

i agree that it's really important that the code you share with other people follows somes code style rules, otherwize, it will be a nightmare when you have to merge, or patch, or diff two different versions of the class.

So, hereafter my proposition of a way of work.

1. Take a source formatter product, like jalopy and customize it to format your code in your style.
2. Create also another customization file, respecting the code convention of the team.

So, each time you receive a source from someone,

1. just execute jalopy with your rules file and you will have a nice and readable source (in your mind).
2. Do, your modifications.
3. Before give it back to the team; reexecute jalopy with the rules file of the team, and you will have a ugly and unreadable source (in your mind) that will enjoy the others.

Thanks to the fact that jalopy can be integrated into NetBeans, it become really easier to do that. And by doing so, you keep your freedom of coding and your team leader continue to be happy

This work is licensed under a Creative Commons License.