I'm finally getting back to loading trunk into eclipse, and the eclipse projects are incorrect, even after running mvn eclipse:eclipse. 1. jbossas-remoting does not have a source path for the tests so they have an incorrect package 2. the varia project is missing org.exolab.castor in its classpath 3. connector has conflicting jdk5/6 jdbc uses 4. iiop has an obsolete jdk4 reference It looks like the eclipse plugin is not using the excludes from the pom. Is this supposed to be picked up automatically? Paul Gier wrote: > I have refactored the AS 6 build so that the thirdparty pom is no longer needed. > The thirdparty pom has now been replaced by two poms. The first one is in > the build directory and contains module dependencies and anything else included > in the AS distribution. The second pom is a new pom in the testsuite directory > and it contains dependencies that are only used in the testsuite. > > The thirdparty pom should now be considered deprecated, and I will remove the > thirdparty directory in trunk after a little more testing. If you want to > add/update dependencies in the AS, here is how to do it. > > Add a new dependency just to the distribution > --------------------------------------------- > 1. add/update the dependency in component-matrix/pom.xml > 2. add/update the dependency in build/pom.xml > 3. the Ant build can then reference the dependency with the format: > ${groupId:artifactId:[classifier:]type} > > Add/update a dependency used only in the testsuite > -------------------------------------------------- > 1. add/update the dependency in component-matrix/pom.xml > 2. add/update the dependency in testsuite/pom.xml > 3. the Ant testsuite build can then reference the dependency with the format: > ${groupId:artifactId:[classifier:]type} > > Add/update a module dependency > ------------------------------ > 1. add/update the dependency in component-matrix > 2. add/update the dependency in the module pom > > > I will also add this information to the wiki [1] when clearspace starts working > for me again. > > [1]http://www.jboss.org/community/wiki/jbossasbuild > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Ok, I am using m2eclipse on other projects, but did not know that the eclipse:eclipse plugin was discouraged. Are the jbossas eclipse users ok with updating the project files to rely on m2eclipse? Seems like there is not much of a choice. Max Rydahl Andersen wrote: > I've seen you guys keep mentioning mvn eclipse:eclipse. > > I like to point out that the Maven guys (sonatype) discourage usage of > this since it is not maintained > and in some cases just utterly broken. > > If it works for you guys, then that is great - but please consider > installing m2eclipse plugin which > adds "native" support for maven in eclipse; and if you find issues > there then we (jboss tools team) can > maybe even help out. > > Just a suggestion. > > Note: the issues below can also just as well be pom.xml bugs, but just > wanted to point out mvn eclipse:eclipse > is not the best way to use eclipse with maven. > > /max > > Scott Stark wrote: >> I'm finally getting back to loading trunk into eclipse, and the eclipse >> projects are incorrect, even after running mvn eclipse:eclipse. >> >> 1. jbossas-remoting does not have a source path for the tests so they >> have an incorrect package >> 2. the varia project is missing org.exolab.castor in its classpath >> 3. connector has conflicting jdk5/6 jdbc uses >> 4. iiop has an obsolete jdk4 reference >> >> It looks like the eclipse plugin is not using the excludes from the pom. >> Is this supposed to be picked up automatically? >> >> Paul Gier wrote: >> >>> I have refactored the AS 6 build so that the thirdparty pom is no longer needed. >>> The thirdparty pom has now been replaced by two poms. The first one is in >>> the build directory and contains module dependencies and anything else included >>> in the AS distribution. The second pom is a new pom in the testsuite directory >>> and it contains dependencies that are only used in the testsuite. >>> >>> The thirdparty pom should now be considered deprecated, and I will remove the >>> thirdparty directory in trunk after a little more testing. If you want to >>> add/update dependencies in the AS, here is how to do it. >>> >>> Add a new dependency just to the distribution >>> --------------------------------------------- >>> 1. add/update the dependency in component-matrix/pom.xml >>> 2. add/update the dependency in build/pom.xml >>> 3. the Ant build can then reference the dependency with the format: >>> ${groupId:artifactId:[classifier:]type} >>> >>> Add/update a dependency used only in the testsuite >>> -------------------------------------------------- >>> 1. add/update the dependency in component-matrix/pom.xml >>> 2. add/update the dependency in testsuite/pom.xml >>> 3. the Ant testsuite build can then reference the dependency with the format: >>> ${groupId:artifactId:[classifier:]type} >>> >>> Add/update a module dependency >>> ------------------------------ >>> 1. add/update the dependency in component-matrix >>> 2. add/update the dependency in the module pom >>> >>> >>> I will also add this information to the wiki [1] when clearspace starts working >>> for me again. >>> >>> [1]http://www.jboss.org/community/wiki/jbossasbuild >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >>> >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development >> > ------------------------------------------------------------------------ > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development > ------------------------------------------------------------------------ _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Its not just a jar, so it actually can not be needed for compilation: [504][valkyrie: trunk]$ jar -tf /home/svn/repository.jboss.org/maven2/jboss/jbossts/jbossts-tools/4.6.1.GA/jbossts-tools-4.6.1.GA.sar META-INF/ META-INF/MANIFEST.MF META-INF/jboss-beans.xml embedded-tools.jar toolsframework.xml tools/ tools/plugins/ tools/plugins/osbv-defaults.jar tools/tsmx-objectstorebrowser.jar tsmx-tools.jar Its only being included in the build distribution as an example: [612][valkyrie: bin]$ find .. -name 'jbossts-tools*' ../docs/examples/transactions/jbossts-tools.sar so we need to clean up the dependency on this to only be relevant to the packaging phase or something. Can that be done Paul? Max Rydahl Andersen wrote: > Question: Are those .sar *really* treatable as .jar's ? > > If yes, then I would consider pushing on JDT to not care about the postfix > (assuming that javac works with .sar?) > > If no and these are purely for JBoss AS understanding, then why are these > .sar's even in the classpath ? > > /max > ------------------------------------------------------------------------ _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

jbossxts.sar is the only one with classes in the root that could be used in the classpath, but I don't know if these are what the testsuite is using. It has other embeded api jars which is what I would expect is what is needed.