I’ve been battling getting JBoss source to import into eclipse for a couple of days now. I just got the project to show no errors.  Here’s the steps I took.
Checked the project out from Subversion:
svn co http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_5_1_0_GA jbossas
Built using maven install. Note that I have a local install of Maven at ~/apps/maven which is version 2.0.9, higher than the 2.0.4 from the Fedora 11 repo.
I created a file ~/.m2/settings.xml and populated it with the JBoss repo information. I’ll include a link.
Opened the Galileo version of Eclipse JEE. Created a vanilla workspace.
Importing the workspace into Eclipse showed many issues, mostly dealing with bad classpaths. If you look at the .classpath files for each of the sub proejcts, you will see that they refer to libs in /thirdparty/. This is the local maven repository defined in a pom.xml in the project. However, the maven build puts them under the thirdparty subproject inside of your build, leading to most of the projects having the majority of their references unmet.
Open up the buildpath for a project. Click on the libraries tab and create a new variable. This variable, which I called THIRD_PARTY points to your jbossas/thirdparty directory.
Close eclipse to safely munge the .classpaths.
I ran variations of the following bash commands to rewire the dependencies.
for CLASSPATH in `find . -name .classpath `; do awk ‘/thirdparty/ {   sub ( “kind=\”lib\””, “kind=\”var\”” ); sub ( “/thirdparty” , “THIRD_PARTY” ) ; print $0 } $0 !~ /thirdparty/ { print $0 } ‘ < $CLASSPATH > $CLASSPATH.new ; mv $CLASSPATH.new $CLASSPATH ;  ; done
Note that I should have used gsub instead of sub, as there are two instances of converting /thirparty to THIRD_PARTY:  path and sourcepath. Instead, I ran the command twice.
Reopening the project in eclipse showed a slew of build problems due to multiple definitions of the same jar files. Argh!
Close eclipse.
Run the following bash command to get rid of multiples.
for CLASSPATH in `find . -name .classpath `; do awk ‘$0 != PREVLINE { print $0 } {PREVLINE=$0 }’ < $CLASSPATHÂ > $CLASSPATH.new ; mv $CLASSPATH.new $CLASSPATHÂ ; done
I’m sure there is a better way of getting rid of duplicate lines, but this worked well enough. When I reopened the proejct, most of the duplicate library build errors were gone. I deleted the rest by hand on individual projects libraries page.
The next set of errors involved the source paths being incorrectly set up for generated code. Again, I mopdified these by hand:
A svn diff shows these changes in the .classpath files to be of the form
-Â Â Â <classpathentry kind=”src” path=”output/gen-src”/>
I’ve been battling getting JBoss source to import into eclipse for a couple of days now. I just got the project to show no errors.  Here’s the steps I took.
Checked the project out from Subversion:
svn co http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_5_1_0_GA jbossas
Built using maven install. Note that I have a local install of Maven at ~/apps/maven which is version 2.0.9, higher than the 2.0.4 from the Fedora 11 repo.
I created a file ~/.m2/settings.xml and populated it with the JBoss repo information. I’ll include a link.
Opened the Galileo version of Eclipse JEE. Created a vanilla workspace.
Importing the workspace into Eclipse showed many issues, mostly dealing with bad classpaths. If you look at the .classpath files for each of the sub proejcts, you will see that they refer to libs in /thirdparty/. This is the local maven repository defined in a pom.xml in the project. However, the maven build puts them under the thirdparty subproject inside of your build, leading to most of the projects having the majority of their references unmet.
Open up the buildpath for a project. Click on the libraries tab and create a new variable. This variable, which I called THIRD_PARTY points to your jbossas/thirdparty directory.
Close eclipse to safely munge the .classpaths.
I ran variations of the following bash commands to rewire the dependencies.
for CLASSPATH in `find . -name .classpath `; do awk ‘/thirdparty/ {   sub ( “kind=\”lib\””, “kind=\”var\”” ); sub ( “/thirdparty” , “THIRD_PARTY” ) ; print $0 } $0 !~ /thirdparty/ { print $0 } ‘ < $CLASSPATH > $CLASSPATH.new ; mv $CLASSPATH.new $CLASSPATH ;  ; done
Note that I should have used gsub instead of sub, as there are two instances of converting /thirparty to THIRD_PARTY:  path and sourcepath. Instead, I ran the command twice.
Reopening the project in eclipse showed a slew of build problems due to multiple definitions of the same jar files. Argh!
Close eclipse.
Run the following bash command to get rid of multiples.
for CLASSPATH in `find . -name .classpath `; do awk ‘$0 != PREVLINE { print $0 } {PREVLINE=$0 }’ < $CLASSPATHÂ > $CLASSPATH.new ; mv $CLASSPATH.new $CLASSPATHÂ ; done
I’m sure there is a better way of getting rid of duplicate lines, but this worked well enough. When I reopened the proejct, most of the duplicate library build errors were gone. I deleted the rest by hand on individual projects libraries page.
The next set of errors involved the source paths being incorrectly set up for generated code. Again, I mopdified these by hand:
A svn diff shows these changes in the .classpath files to be of the form
+Â Â Â <classpathentry kind=”src” path=”target/generated-sources/idl”/>
-Â Â Â <classpathentry kind=”src” path=”output/gen-src”/>
The final changes involved adding in excludes rules in the source paths for certain files that do not build. These can be gleaned from the pom.xml files. For instance
./varia/pom.xml:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â <exclude>org/jboss/varia/stats/*JDK5.java</exclude>
I was never able to get the embedded project to build correctly. I closed that project and ignored it.
I had to create a couple of test classes for the test code to compile as well: MySingleton and CtsCmp2Local.java. I suspect that these should be generated or just didn’t get checked in. Obviously, this didn’t break the Maven build.
Now I just need to figure out how to run it.