JBossDeveloper

 

"Kevin.Conner@jboss.com" wrote:
there should be no need to keep classpath/project files in maven.

Of course I meant to say subversion :-)

 

"pgier" wrote:
I think that dependency is currently being picked up through kernel.
deployers -> kernel -> dependency.
Did the build fail for you? I tried a clean checkout, and it seems ok for me.

Interesting, the transitive dependencies should have picked it up in that case. My build still fails with the following

[INFO] [compiler:compile]
Compiling 12 source files to /home/kevin/microcontainer/microcontainer/deployers/target/classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure

/home/kevin/microcontainer/microcontainer/deployers/src/main/org/jboss/deployers/plugins/deployers/kernel/BeanMetaDataDeployer.java:[67,19] cannot access org.jboss.dependency.spi.dispatch.InvokeDispatchContext
file org/jboss/dependency/spi/dispatch/InvokeDispatchContext.class not found
 controller.install(context);

This is a version as of about two days ago. I'll delve deeper into it since the transitive dependency should exist.

 

"pgier" wrote:
Yes, I think that's a good idea. I'm planning that the next version of the <a href="https://svn.labs.jboss.org/labs/jbossbuild/jboss-parent/trunk/pom.xml"> jboss-parent</a> pom will use the eclipse plugin to generate eclipse project files. I just haven't had time yet to add (and test) this for microcontainer. Feel free to add it if you want.

What needs adding? mvn eclipse:eclipse will generate them and mvn:add-maven-repo will configure the workspace. I run this on all maven projects :-)

I have a local project for ESB which uses a profile to create a workspace and initialise formatting, checkstyle and pmd. Are you planning on doing something similar?

I get the following error while running this: 'C:\projects\microcontainer>mvn install'

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).


Project ID: jboss:jboss-container
POM Location: C:\projects\microcontainer\container\pom.xml
Validation Messages:

 [0] 'dependencies.dependency.version' is missing for jboss:jbossxb


Reason: Failed to validate POM


[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Failed to validate POM
 at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:373)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:286)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to validate POM
 at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:949)
 at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:760)
 at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:431)
 at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:195)
 at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:523)
 at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:455)
 at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:499)
 at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:359)
 ... 11 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Sun Apr 01 09:41:31 CEST 2007
[INFO] Final Memory: 1M/2M
[INFO] ------------------------------------------------------------------------

What am I missing?

 

"pgier" wrote:
I think that dependency is currently being picked up through kernel.
deployers -> kernel -> dependency.
Did the build fail for you? I tried a clean checkout, and it seems ok for me.

Okay, the reason it is failing in my build is two fold
- I am using maven 2.0.5 instead of 2.0.4 (this appears to build under 2.0.4)
- there is a second transitive specification of jboss-dependency
The second dependency is coming from deployers->jboss-aop->jboss-dependency(2.0.0.Beta)

It is this 2.0.0.Beta version which is being picked up by the 2.0.5 compile stage, hence the failure.

I'm not yet sure why 2.0.4 and 2.0.5 resolve their dependencies in a different way but I will investigate further tomorrow.

 

"Kevin.Conner@jboss.com" wrote:

The second dependency is coming from deployers->jboss-aop->jboss-dependency(2.0.0.Beta)

The jboss-aop dependency was updated overnight to 2.0.0-SNAPSHOT. This now allows my current version to build but is obviously not a proper fix as it may occur in future.

 

"pgier" wrote:

Try doing an "mvn -U -up" to make sure that you have everything up to date. If that doesn't work, the jbossxb version number that it's looking for should be picked up from the microcontainer parent. Make sure that this parent pom is up to date with svn and includes the jbossxb dependency in the dependencyManagement section.

It was my mistake, my IDE doesn't update files in project's root directory (strange, but real ;-).
Thanks for the help and also to Kevin, who also realized what the problem is.

 

"pgier" wrote:
I changed the aop dependency so that it does not transitively include jboss-container, and jboss-dependency.

The versions I am downloading still have them included albeit at version 2.0.0-SNAPSHOT. There is no present conflict between those and the MC dependencies but the potential still exists.

"pgier" wrote:
Do you have some ideas for a better long term solution?

My understanding of the 2.0.5 transitive dependency resolution is that it depends on two factors
- the depth of the dependency, in other words how many indirects in the chain
- the order in which they are encountered, for those at the same depth

Precedence goes to the dependency with the shortest path and, for those at the same depth, the one encountered first.

There are three possible solutions that I can think of
- declare the dependency
- declare peer projects prior to other dependencies
- specify exclusions on the other dependencies

I do not believe the second solution is a good one as it relies on the depth of the dependency. I would therefore suggest explicit declaration or exclusions. Exclusions would look as follows

<dependency>
 <groupId>jboss</groupId>
 <artifactId>jboss-aop</artifactId>
 <version>2.0.0-SNAPSHOT</version>
 <exclusions>
 <exclusion>
 <groupId>jboss</groupId>
 <artifactId>jboss-dependency</artifactId>
 </exclusion>
 </exclusions>
</dependency>

 

"Kevin.Conner@jboss.com" wrote:

"pgier" wrote:
Yes, I think that's a good idea. I'm planning that the next version of the <a href="https://svn.labs.jboss.org/labs/jbossbuild/jboss-parent/trunk/pom.xml"> jboss-parent</a> pom will use the eclipse plugin to generate eclipse project files. I just haven't had time yet to add (and test) this for microcontainer. Feel free to add it if you want.

What needs adding? mvn eclipse:eclipse will generate them and mvn:add-maven-repo will configure the workspace. I run this on all maven projects :-)

The Maven eclipse:eclipse build is currently broken.

Some of the obvious things that don't work:

1) It uses the wrong project name for dependencies
e.g. jboss-container instead of container

2) Things like src/resources/tests end up as a source import when it should be a class
library import. If they are source, you can't find the xml, etc. in the classpath

 

"adrian@jboss.org" wrote:
The Maven eclipse:eclipse build is currently broken.

Not for me it isn't :-)

"adrian@jboss.org" wrote:
1) It uses the wrong project name for dependencies
e.g. jboss-container instead of container

My container project is calles jboss-container. It is likely that you have not imported the generated projects.

To rectify do the following
- delete projects (not contents)
- run mvn eclipse:eclipse from root
- File->Import
- Choose Existing Projects
- Browse to root
- Import generated projects

All your project names will be consistent and will work :-)

"adrian@jboss.org" wrote:
2) Things like src/resources/tests end up as a source import when it should be a class
library import. If they are source, you can't find the xml, etc. in the classpath

Not sure why it can't be found on the classpath, all sources are there by default. Do you have a specific example?

 

"Kevin.Conner@jboss.com" wrote:

"adrian@jboss.org" wrote:
1) It uses the wrong project name for dependencies
e.g. jboss-container instead of container

My container project is calles jboss-container. It is likely that you have not imported the generated projects.

To rectify do the following
- delete projects (not contents)
- run mvn eclipse:eclipse from root
- File->Import
- Choose Existing Projects
- Browse to root
- Import generated projects

All your project names will be consistent and will work :-)

Ok I will try that, but since I hit the problem with a clean checkout of the
Microcontainer and a build with Maven before creating the new eclipse
projects, I don't know whether this entirely consistent? -)

I've also seen this problem before with the common project.

"adrian@jboss.org" wrote:
2) Things like src/resources/tests end up as a source import when it should be a class
library import. If they are source, you can't find the xml, etc. in the classpath

Not sure why it can't be found on the classpath, all sources are there by default. Do you have a specific example?

src/resources/schema or src/resources/xml-tests in the container project
would be examples. After an eclipse:eclipse these are invisible to tests
run inside eclipse. They have type="src" instead of type="lib' in the .classpath