Checking in Eclipse project files into Remoting 3 repository

[trustin]

I've just managed to import all Remoting 3 components into Eclipse. For those who will try to import Remoting 3 into their Eclipse workbench, I thought it might be a good idea to check in the project files into the source code repository.

I know it's not really a good idea to check in files which is specific to a certain IDE, but configuring all the classpaths and project dependencies is a time-consuming task. Moreover, Remoting 2 already has Eclipse IDE files in the repository.

If we are not going to migrate to Maven 2, we could check in our IDE files meanwhile although it might be pain in the butt to maintain two files - build.xml and .classpath (and probably IntelliJ ones?)

WDYT?

[trustin]

Another option I'd like to suggest to is the migration to Maven 2. As you know JBossAS 5 is also in course of Mavenization, and we will eventually pull dependencies from the Maven repository.

Maven still provides ant-task plugin, so we should be able to run any custom tasks we did in Ant. Moreover, IntelliJ and NetBeans have good Maven integration and the plugin for Eclipse is working pretty well now although it's not that comparable to that of NetBeans or IntelliJ.

I think it's really good time to mavenize Remoting 3 considering it's in the early stage of development. The build.xml also looks pretty easy for Mavenization.

[dmlloyd]

I would not be against including .classpath files for each module into SVN (yes, my opinion on this has changed - at this point I guess the positives outweigh the negatives). If you want, I can even have IDEA produce these for you, and check them in?

As for Maven 2 - I wouldn't be against using Maven to fetch dependencies. But I'm not sure that Maven is able to understand that artifacts are built from more than one module.

And in any case - it is far, far more important that we work on the remaining coding tasks than it is to replace the already-working build right now. There is much work to be done before the final 3.0.0 release, and replacing the build right now is not going to help us get there. It is something I think we can revisit in a couple of months.

[trustin]

In Maven 2, there's only one artifact for one module. Actually having an artifact assembled from more than one module causes some complication in dependency reolution.

For example, let's assume that module A produces artifact A, module B produces artifact B and artifact C is assembled from the artifact A and B. In this case, if project X depends on artifact C, project Y depends on artifact A and project Z depends on artifact X and Y, there's no easy way for Maven to figure out artifact C includes artifact A. If project X depended on artifact A & B, dependency resolution will be easier. (Uh... poor English, eh? ;)

I was obnoxious about this restriction at the first time Maven 2 was released, but I found it is pretty good restriction that reduces the confusion about the relationship between artifacts and modules.

Anyway, it doesn't mean that you cannot create an artifact of artifacts (e.g. artifact C) with Maven assembly plugin, which is often used to generate a tarball distribution and all-in-one JAR.

I believe I can mavenize Remoting 3 within a couple days. Then you can simply type 'mvn package' to build all artifacts and the build shouldn't break at all, hopefully not slowing us down very much. WDYT? ;)

[dmlloyd]

I'd rather have those couple days spent working towards the M2 release :)

[trustin]

I've just checked in the Eclipse project files for all modules in Remoting 3. I don't use IntelliJ these days, so it's up to you to check in your IntelliJ project files.

Anyway... it's time to rock..! :)