The name of the ANT GUI development tool is Antodyne. ANT considered to be a great language for the build scripts. ANT tasks encapsulate and parameterize corresponding functions, but the latest releases of ANT introduce a large number of tasks that is hard to memorize. Utilizing dependencies approach, targets can be constructed into an extensive execution tree, however have you tried to search through a big ANT script to track dependent targets? Sometimes it seems to be overwhelming. It can't be easy to figure out a property value when it is nested with other properties. That is when Antodyne comes in. Find a full tool description here http://www.goaldreen.com/products Message was edited by: jvaughan@techtarget.com

Maven. I had to say it.

Maven. I had to say it.

Every time a person runs a Maven build, a mammal is sacrificed.

<Every time a person runs a Maven build, a mammal is sacrificed.</blockquote>I don't get your point. Why?

I don't get your point. Why?

Probably for two reasons. First, if a project follows Maven's conventions and expected structure, it can work quite well. However, if it doesn't, it is likely to turn into a total mess. Second, although this may not be Maven's fault, I don't think I've ever encountered a Maven build that ran successfully the first time. This is probably the fault of the person who set up the build, but it makes for a very discouraging experience. --Matt The Software Grove

I work with many large clients with many very large projects, and as a rule the Maven projects (even those with hundreds of thousands of lines of code and dozens of modules) run without a hitch, and are relatively easy to maintain and evolve. The ant scripts, on the other hand, are maintenance nightmares. In large organizations, the standardization offered by Maven is a *HUGE* benefit.

I don't get your point. Why?

Probably for two reasons. First, if a project follows Maven's conventions and expected structure, it can work quite well. However, if it doesn't, it is likely to turn into a total mess. Second, although this may not be Maven's fault, I don't think I've ever encountered a Maven build that ran successfully the first time. This is probably the fault of the person who set up the build, but it makes for a very discouraging experience.

--Matt
The Software Grove

Gotta love it when pro maven people dismiss real issues as user error. Plenty people setup maven based on "the recommended" conventions and it still sucks. My bias opinion, maven is a special kind of torture for masochists. Ant works perfectly fine without all the stupid guard rails and idiocy of maven. Flame on!

Probably for two reasons. First, if a project follows Maven's conventions and expected structure, it can work quite well. However, if it doesn't, it is likely to turn into a total mess. Second, although this may not be Maven's fault, I don't think I've ever encountered a Maven build that ran successfully the first time. This is probably the fault of the person who set up the build, but it makes for a very discouraging experience.

--Matt
The Software Grove

Gotta love it when pro maven people dismiss real issues as user error. Plenty people setup maven based on "the recommended" conventions and it still sucks.
My bias opinion, maven is a special kind of torture for masochists. Ant works perfectly fine without all the stupid guard rails and idiocy of maven. Flame on!

What about "total mess" and "I don't think I've ever encountered a Maven build that ran successfully the first time" makes you think I'm "pro maven"? I was politely trying to explain to someone who did sound pro maven that others, including myself, have found it a pain to deal with. I theorized that part of that might be a failure in understanding on the part of the person putting together the build, but the fact that Maven seems to confuse a lot of smart people is certainly not an argument in its favor. In another recent thread, I suggested that people check out Gradle before deciding to use Groovy in conjunction with Maven. --Matt

@M. Lin Eclipse, Itellij, jdeveloper... all use their own suggestion of a java structure. Most try to mimic the jee setup. Maven also suggest a structure. As in all of these tools you can use your own. BUT beware of the consequences. if you develop in a team, then using your own quirky way is not appreciated. I with my co-workers can startup blindly by retrieving the source from the repo and for example compile mvn compile. No configuring whatsoever. I have seen many projects using ant that really suck when you want to get started. minimun 1/2 day to get going due to incomprehensible undocumented ant scripts with lots of localized configuration

Iam going to bite. You do not understand Maven User inexperience or plain stupidity is the fault that maven build does not run on your first try. If you want a structure different from Maven, then you are throwing the best practice/experience down the drain of numerous veterans of java development. There is absolutely no need to use a different structure opposed to the maven suggested one. If you do, you are making it unnecessarily difficult for yourself and the team. If you persist in using ant, good luck debugging ant scripts, maintaining them etc. But you won't make my team. i want to build software, not repair broken ant scripts all the time. Enough flame for now. Welcome to the forum dino. :)

If you persist in using ant, good luck debugging ant scripts,

At least for ant, there exists a debugger.

Sigh... Back when it was still fresh, I told myself I should just let this ridiculous thread die, but then I came upon it again just now and couldn't resist replying one more time. I am happy to admit that I "do not understand Maven". That places me in the company of some VERY smart people. However, I still have an open mind about it. Notice what I said earlier: "if a project follows Maven's conventions and expected structure, it can work quite well." Have you ever downloaded a widely-used open source project, run "maven site" on it, and encountered numerous errors? That's happened to me with several projects. If I'm doing something as simple as that, do you really believe that the failures are my fault? What makes you think I "persist in using ant"? In my reply right above yours, I mention that Gradle is a good alternative to Maven. It's simpler than ant, more sophisticated than ant, and more flexible than Maven. Given your knee-jerk obnoxious responses, I wouldn't want to work on a team with you anyway. --Matt

Iam going to bite.
You do not understand Maven
User inexperience or plain stupidity is the fault that maven build does not run on your first try.
If you want a structure different from Maven, then you are throwing the best practice/experience down the drain of numerous veterans of java development.
There is absolutely no need to use a different structure opposed to the maven suggested one. If you do, you are making it unnecessarily difficult for yourself and the team.
If you persist in using ant, good luck debugging ant scripts, maintaining them etc. But you won't make my team. i want to build software, not repair broken ant scripts all the time.
Enough flame for now. Welcome to the forum dino. :)

Maven. I had to say it.

I also prefer maven than ant, but it'll better if I can find a maven repository for the oracle ojdbc driver.

Go to http://repository.sonatype.org/ and type in ojdbc in the search box.

Maven. I had to say it.

I also prefer maven than ant, but it'll better if I can find a maven repository for the oracle ojdbc driver.

Maven + Nexus is the optimal solution: you have a project management tool with a libraries repository under your complete control. You can deploy your own artifact (for example oracle's libraries if some thing is not present) within 2 minutes. I don't understand why people search "alternatives" to Maven: in the most cases the alternatives are very similar to the original one; so why? Moreover if Maven is complicated or ugly, there is a good Open Source alternative: Apache Ivy, it's free and very easy to use (Ivy is an Ant sub project).

Ivy is not equal to Maven by a long shot. Ivy is only a dependency manager, whilst Maven is a life cycle tool of which dependency management is only 1 element. Furthermore. why use Ivy when you have Maven. Have not found a project yet, that i needed to use Ivy. If you have such a complex structure, you should reconsider your set up and simplify it.

Go to http://repository.sonatype.org/ and type in ojdbc in the search box.

Also, you can do something like this: 1. Add inner local repo reference to pom.xml: local file://lib 2. Put any artifacts which you can't find in any public repository to your local repository inside project structure according to Maven directory convention, for example: \lib\com\oracle\ojdbc14\10.2.0.2.0\ojdbc14-10.2.0.2.0.jar 3. PROFIT.

The file:// strategy described above is a recipe for non-portable build scripts - to be avoided at all costs! Just deploy the Oracle JAR to your enterprise repository, it's that simple.

The file:// strategy described above is a recipe for non-portable build scripts - to be avoided at all costs! Just deploy the Oracle JAR to your enterprise repository, it's that simple.

Absolutely wrong statement. Strategy, described above is the best recipe to create fully-portable build scripts. The trick is that "lib" folder should be a part of source code (/trunk/lib for example), and it should be committed into source control system. In that case, you even don't need to deploy any jars to your enterprise repository (by the way, not all companies has such separate repositories), all users will automatically get specific jars to their local repository after first Maven build execution. Also, this approach doesn't require any additional activities from build integrator.

The first rule of writing maintainable ant scripts is to *never* use the depends attribute. It's unfortunate that it was ever included in ant in the first place, more unfortunate that it seems to be used in every example ant script, and even more unfortunate that it has contaminated a much better build system known as gradle). Stop the insanity! As for the product mentioned above, I have no opinion since I've never tried it. However, my first recommendation for improving your build experience would be to move off of ant.

Even I vouch for Maven.

I went to their website and downloaded their product description. It provides an extremely tedious user interface to build an Ant file. They want money for this application. There are several apps that already do similar things and for free. See http://ant.apache.org/projects.html for a good list. Once again, it looks like TheServerSide is posting advertisements rather than articles.