Is "Generate Ant Build" useful?

I've come to the same conclusions myself. Although I think IDEA is in
the right direction, this feature still needs some more work.

What I'd really like to see is having IDEA base its project build cycle
on Ant (or at least allow to) like Netbeans' ant-based projects.


Keith Lea wrote:

I've personally used "Generate Ant Build" a few times (maybe 5 times)
and each time it's turned out to be more work than it's worth, because I
have to change the generated file extensively to make it readable and
reasonably simple.
1. The generated build files are complex and verbose
- I don't have test classes, but there are targets made just for test
classes, for each of my 4 modules
- I don't have files to be copied to the output path, but there's a big
ugly <copy> task after the javac task
- I have never, once, ever, modified my JDK classpath from the defaults,
but IDEA still specifies the JDK classpath, bootclasspath, etc.
- many unnecessary properties are defined, like one for the build root
(which is the current directory in my case, so it does not need to be
specified)

2. They do not specify source="1.4" for javac even though my language
level is set to 1.4.

3. They use long target names, like "compile.module.common.production"
which in my case could be shortened to "compile.common"

What does everyone else think about this feature? Are these problems for
you too? If so I'll probably file some requests about it.

What I'd really like to see is having IDEA base its project build
cycle on Ant (or at least allow to) like Netbeans' ant-based projects.

I don't think that makes sense at all. I think Ant should adapt to fit IDE's,
not the other way around. I would have no problem with an Ant task which
read an IDEA project or module file and compiled based on that.

I strongly agree that an Ant-requiring build system like NetBeans has created is a horrible, horrible idea. It presents the beginning user with a simply atrocious user experience, particularly if they simply don't know Ant (don't snicker, you were there once). Additionally, whatever one thinks of the Maven effort, Java best practices seem to be converging rapidly enough that eventually a declarative build system will become practical for production use. At that point, having an imperative build system like Ant built into IDEA will be a liability.

As for the current "Generate Ant Build", it would probably be fine if it were just a little less verbose. Particularly for single module projects, the results are just too cumbersome. It's also not really necessary to describe each JDK jar explicitly (that's what people use JAVA_HOME for).

--Dave Griffith

By the way, #1 could be fixed with some heuristics and checkboxes - if I
don't have any test classes, show a checkbox asking whether to include test
compilation targets, etc.

I've personally used "Generate Ant Build" a few times (maybe 5 times)
and each time it's turned out to be more work than it's worth, because
I have to change the generated file extensively to make it readable
and reasonably simple.

1. The generated build files are complex and verbose
- I don't have test classes, but there are targets made just for test
classes,
for each of my 4 modules
- I don't have files to be copied to the output path, but there's a
big ugly
<copy> task after the javac task
- I have never, once, ever, modified my JDK classpath from the
defaults,
but IDEA still specifies the JDK classpath, bootclasspath, etc.
- many unnecessary properties are defined, like one for the build root
(which
is the current directory in my case, so it does not need to be
specified)
2. They do not specify source="1.4" for javac even though my language
level is set to 1.4.

3. They use long target names, like "compile.module.common.production"
which in my case could be shortened to "compile.common"

What does everyone else think about this feature? Are these problems
for you too? If so I'll probably file some requests about it.

Keith Lea wrote:

I don't think that makes sense at all. I think Ant should adapt to fit
IDE's, not the other way around. I would have no problem with an Ant
task which read an IDEA project or module file and compiled based on that.

Yes, but what if the user doesn't have to see the Ant file at all? For
instance, the normal GUI can still work, but instead of saving it to IPR
files, they would be saved to Ant files.

This way, I can use the same project both in UNIX systems (say
continuous integration, etc) AND inside my favorite IDE(A)...

As for Ant adapting to IDEs - I'm not sure this should be the way, since
projects are used and built not only inside an IDE (something IDE
developers tend to forget) but also on continuous integration servers,
by cvs commits by remote build requests or simply on a machine with IDE
license...

But don't get me wrong - I absolutely LOVE idea and would trade it with
no other IDE - the problem is, many others prefer other IDEs (Eclipse,
Netbeans, you-name-it) and why shouldn't they be able to build my
project without the hassle of adapting it to another IDE?

2cents posts only! ;)

Arik.

Now that you mention it - why not expose the Ant build file template to
the developers? just like live templates or file templates? now THAT
would be a powerful feature!


Keith Lea wrote:

By the way, #1 could be fixed with some heuristics and checkboxes - if I
don't have any test classes, show a checkbox asking whether to include
test compilation targets, etc.

>> I've personally used "Generate Ant Build" a few times (maybe 5 times)
>> and each time it's turned out to be more work than it's worth, because
>> I have to change the generated file extensively to make it readable
>> and reasonably simple.
>>
>> 1. The generated build files are complex and verbose
>> - I don't have test classes, but there are targets made just for test
>> classes,
>> for each of my 4 modules
>> - I don't have files to be copied to the output path, but there's a
>> big ugly
>> task after the javac task >> - I have never, once, ever, modified my JDK classpath from the >> defaults, >> but IDEA still specifies the JDK classpath, bootclasspath, etc. >> - many unnecessary properties are defined, like one for the build root >> (which >> is the current directory in my case, so it does not need to be >> specified) >> 2. They do not specify source="1.4" for javac even though my language >> level is set to 1.4. >> >> 3. They use long target names, like "compile.module.common.production" >> which in my case could be shortened to "compile.common" >> >> What does everyone else think about this feature? Are these problems >> for you too? If so I'll probably file some requests about it. >>]]>

I agree mostly. It also contains a fair number of usability bugs that I put in the tracker a while back but the devs said that this was the way it was supposed to work. Right now the build files are just monstrosities that are a pain to sift through and edit to get them to do the right thing because you might (heaven forbid) have to generate the ant build file again.

I agree mostly. It also contains a fair number of
usability bugs that I put in the tracker a while back
but the devs said that this was the way it was
supposed to work. Right now the build files are just
monstrosities that are a pain to sift through and
edit to get them to do the right thing because you
might (heaven forbid) have to generate the ant build
file again.

It's a shame because I get the feeling that the ant build generation feature is almost there. It just needs a few more tweaks.