815
I have installed it, configured paths for our multi component project,
compiled (we only compile with Ant) and ran.
I repeat again what I iterated more than once: We believe here that any work
done on a separate compilation and project configuration not based on Ant is
a waste of time.
Example: In order to have IntelliJ recognize the sources I had to configure
the paths in IntelliJ where in fact I had everything in our Ant scripts.
Multiple components = multiple ANT files and one that calls all of them.
directory excludes, properties for compilation, JUnit tests, all there.
I am confident that it would be simpler to implement and much better if
IntelliJ would just compile with ANT, package with ANT, etc, so that the
user (in any UI you would want to provide) would simply be editting an ANT
script (or several) and not do everything twice (e.g. adding a new component
means for us adding a new ANT file and also configuring the paths in
IntelliJ).
This is probably my only major gripe about IntelliJ or any other IDE that
forces me to do stuff in 2 places. It's prone to errors and problems and I
think a waste of time for the people that develop IntelliJ.
Amnon
Please sign in to leave a comment.
As someone who only uses Ant for build as well, I would be inclined to agree with you on the subject of compilation. However, I don't see how what you say could actually work for project management. There is simply way too much flexibility in Ant to allow any IDE to be able to intelligently figure out just what your source and classpaths actually are. I've worked on projects, for instance, where the Ant script first dynamically created a properties file, and then loaded the classpath for the rest of the build from that. It worked great both on developer's desktops and for our central build system, but there was no way I would expect any other tool to figure it out. It was simply too idiosyncratic.
As another example, on seemingly the last half-dozen projects I've been on, substantial chunks of the code base were auto-generated at build time. Ant made that pretty easy, although you had to be careful with just what went in the classpath when. It wasn't unusual to end up with >5 classpaths managed in any given Ant file. All very sweet, but how would IDEA figure that out.
I don't really see any way out of IDEA having it's own project management data structures, parallel to those in Ant.
(Not that I can't think of plenty of ways to improve IDEA's project management. Something like "put lib/*.jar in my classpath, keeping that current if I drop in new jars" would be an excellent start. )
Absolutely. I don't think any IDE could be expected to interpret the intent of an ANT file.
I also absolutely agree that defining paths in Intellij using the same wildcard syntax ANT uses for filesets would be awesome.
I agree with most of what you are saying, but I do think that Any source and
classpath capabilities are mappable to UI.
IntelliJ already has some knowledge about Ant, and that could be an
extension of that.
If JetBrains work with Jakarta people they could leverage Ant own code to
understand the ant file and walk it just like Ant itself would.
I think that it is possible that IntelliJ will create Ant scripts, at least
as a first step, before it can work with existing ones.
"Dave Griffith" <dave.griffith@trilogy.com> wrote in message
news:8348596.1053028356842.JavaMail.jrun@is.intellij.net...
>
agree with you on the subject of compilation. However, I don't see how what
you say could actually work for project management. There is simply
way too much flexibility in Ant to allow any IDE to be able to
intelligently figure out just what your source and classpaths actually are.
I've worked on projects, for instance, where the Ant script first
dynamically created a properties file, and then loaded the classpath for the
rest of the build from that. It worked great both on developer's desktops
and for our central build system, but there was no way I would expect any
other tool to figure it out. It was simply too idiosyncratic.
on, substantial chunks of the code base were auto-generated at build time.
Ant made that pretty easy, although you had to be careful with just what
went in the classpath when. It wasn't unusual to end up with >5 classpaths
managed in any given Ant file. All very sweet, but how would IDEA figure
that out.
>
data structures, parallel to those in Ant.
>
management. Something like "put lib/*.jar in my classpath, keeping that
current if I drop in new jars" would be an excellent start. )
Unfortunately, IDEA created Ant scripts, while theoretically useful for holding project management data, would be pretty useless as production build scripts. They just be expected to do everything that a production build script does. You might add a few build features that Ant currently supports but IDEA does not (jar creation and javadoc certainly, rmic maybe), but no way could IDEA be expected to add file and directory manipulation, templated file creation, arbitrary scripting, mail, third-party tags, custom tags, etc., etc., which many production builds use on a daily basis. If I had to dumb down my Ant scripts enough that IDEA could use them to figure out it's project management information, Ant would no longer be powerful enough to run my builds.
Now maybe, this could all be made to work with a 'higher-level' build system like Maven. The problem with that is that I can't stand Maven.
Exactly. Ant is basically a script (batch) language describing the sequense
of procedures that do something. In addition it just provides a very simple
target dependency management. There is no good way it could be used for
describing the project structure. Even the opposite, I would expect from
Ant if I could pass it some project structure data and an elegant way to use
it in the build.xml.
Regarding adding a directory's contents to the classpath by adding the
directory only is planned for Aurora.
--
Eugene Belyaev, CTO
JetBrains, Inc
http://www.intellij.com
"Develop with pleasure!"
"Dave Griffith" <dave.griffith@trilogy.com> wrote in message
news:8348596.1053028356842.JavaMail.jrun@is.intellij.net...
>
agree with you on the subject of compilation. However, I don't see how what
you say could actually work for project management. There is simply
way too much flexibility in Ant to allow any IDE to be able to
intelligently figure out just what your source and classpaths actually are.
I've worked on projects, for instance, where the Ant script first
dynamically created a properties file, and then loaded the classpath for the
rest of the build from that. It worked great both on developer's desktops
and for our central build system, but there was no way I would expect any
other tool to figure it out. It was simply too idiosyncratic.
on, substantial chunks of the code base were auto-generated at build time.
Ant made that pretty easy, although you had to be careful with just what
went in the classpath when. It wasn't unusual to end up with >5 classpaths
managed in any given Ant file. All very sweet, but how would IDEA figure
that out.
>
data structures, parallel to those in Ant.
>
management. Something like "put lib/*.jar in my classpath, keeping that
current if I drop in new jars" would be an excellent start. )
>Regarding adding a directory's contents to the classpath by adding the
>directory only is planned for Aurora.
Bliss.
For that, we have maven.
I'm not sure that would be a good idea.
Firstly, I think it would be very difficult to shoehorn a GUI-based project manager, into the structure of command-line make-facility.
They could easily find themselves whereby there is a new feature that they want to build into the project manager, but can't because ANT won't allow them to support it. Having their own structure gives Jetbrains more flexibility.
Secondly, ANT may be the flavour of the month now, but what happens in a few years time when a new way of building projects drops into our laps. Do they support TWO project file formats?
"
Regarding adding a directory's contents to the classpath by adding the
directory only is planned for Aurora.
"
Will it support the ant "exclude"-pattern ?
My "lib" directory usually contains all the librairies (*.jar) needed for compiling, running the Junit tests, running the app...
So I need to be able to accuratly specify the *.jar to import into the classpath, and using the "exclude" filter would be a good start.
Dan
/