qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrewinternatio...@gmail.com>
Subject Re: Eclipse project files for Java code
Date Sun, 12 Dec 2010 22:13:43 GMT
On 11 Dec 2010, at 18:59, Marnie McCormack wrote:
> Much as I hate to raise the subject - isn't this primarily a debate  
> about
> dependency management ?
> I have the same problems using IntelliJ. It was pretty much the  
> onlt thing I
> liked about the maven build -> generated project files !
> How about using the ant-eclipse generator, has anyone been using it ?
> http://ant-eclipse.sourceforge.net/

Interesting, thanks. If it works like the Maven 'mvn  
eclipse:eclipse' (or, of course, something like 'mvn  
intellij:intellij' which I believe does the same thing Marnie  
mentioned, from the command line) then great. I have had a brief  
look, and it seems useful. The problem is then how we cater for the  
two choices for project setup in an IDE, namely:

a.) Load all modules (most directories under 'qpid/java') as separate  
projects, and manage inter-project dependencies, as well as the  
external ones, in the CLASSPATH.
b.) Create a single project with all module source directories  
loaded, and only reference external library dependencies (from 'qpid/ 
java/lib') in the CLASSPATH.

I use method b. (as does Robbie, see previous discussion) however we  
should probably support both, using e.g. 'ant eclipse' for a. which  
would recurse through modules doing the same, which would be quite  
simple with the Ant 'module.xml' build file, and then 'ant eclipse- 
single' for b. which can go in the main 'build.xml' file?

On 11 Dec 2010, at 02:39, Robbie Gemmell wrote:
> You can use the existing build.xml files to run the build etc within
> Eclipse, I don't think there is anything specific needing done there.
> Running individual tests etc using the built in JUnit plugin is  
> another
> matter, and needs quite a lot of configuration. Again though, I  
> tend to use
> the cmd line for all these tasks.

You're right, this is what I was thinking of. Running the JUnit tests  
easily inside an IDE would be a useful goal, and would make things  
easier for a lot of people, certainly. Not sure that any of the  
proposed mechanisms would solve this problem?

> I'm not sure compatibility would be a problem, the files are pretty  
> simple
> and don't seem to have changed for as long as I've ever looked  
> inside them.
> Differences between developer preference is what will cause issues  
> most I
> think.

I *have* had issues when upgrading Eclipse and have had to re-import  
broken projects, of course, this could always have been user-error ;)  
Developer preference is probably the thing to keep in mind here.

> Example project files could always be checked in to a directory in  
> the tree,
> rather than into a location Eclipse would actually pick them up  
> directly and
> use them. Of course, then they will simply become out date if no  
> one kept
> them fresh, defeating the point.

True, but shouldn't this go into the developer documentation, with  
links or attachments for examples for various IDEs? Someone still has  
to keep the documentation up to date, obviously. This would still  
give developers the freedom to choose their workflow, without  
worrying about 'svn update' or whatever doing something bad to their  

Anyway, I am willing to try and configure 'ant-eclipse' and see if we  
can get something useful out of it? I'm still philosophically opposed  
to putting files under revision control that can be generated  
automatically, and are not actually required for the project build,  
which is why this appeals to me.

-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message