Trouble with Maven 2 project data (10574).

Hi,

I'm having a bit of trouble with some of my build configuations.  I have several maven modules that use flexmojos and whenever I go to the 'Maven 2' tab in those configurations I get the following error:

An error occurred during collecting maven data: org.apache.maven.extension.ExtensionScanningException: Cannot resolve pre-scanned plugin artifact (for use as an extension): org.sonatype.flexmojos:flexmojos-maven-plugin: Failed to resolve extension plugin: org.sonatype.flexmojos:flexmojos-maven-plugin:maven-plugin:RELEASE

I can't figure out what the problem is, so I was hoping someone could point me in the right direction.  I run TeamCity on Linux and it runs under the system user 'teamcity'.  The file /home/teamcity/.m2/settings.xml is configured to use an internal Nexus mirror.

The teamcity.log doesn't have any additional info.  My builds all work fine, but I'm using a custom maven install for all of them.  Any ideas?

10 comments
Comment actions Permalink

Hello, Ryan

Try upgrading to the latest EAP. It contains significant improvements in dealing with Maven data.

Thank you

0
Comment actions Permalink

I'll give it a try later today and let you know how it goes.  Thank you
for the quick reply.


0
Comment actions Permalink

Hi Sergey,

I've updated to 10626.  I'm now able to view the Maven 2 tab and use Maven properties in my builds (ex: %maven.project.version%) which I couldn't before, so things have definitely improved.  However, it seems to have trouble analyzing the dependencies for my project.  Everything builds fine though.  I'll attach 2 screenshots to show where things look incorrect.

The first is a build for a module named itma-services-core.  This is a plain java module that has a single direct dependency; itma-domain.  Build 10574 used to list the scope of the itma-domain module as 'complie'.  I've marked the spot with a red arrow.  Additionally, the  section below 'Build Configurations Dependent Upon' is very wrong.  As far as I know, it should only list the itma-domain module.  I've marked it with a green star.  Also note the 'Produces Artifacts' for every 'Configuration' are listed as the itma-domain module.  This is not correct as these modules all produce a single artifact that matches the names I've used for the configurations.

The second screenshot is of one of my flex modules.  It's named itma-flex-ui and has two direct dependencies; itma-flex-core and itma-blazeds-config.  The 'External Dependencies' section appears to be correct with the exception of the missing 'Scope' values.  The 'Build Configurations Dependent Upon' is again incorrect.  It should only list the two modules I've added green stars beside.  Also note that all 5 incorrect entries list the same 'Produces Artifacts' and there are 2 for each 'Configuration'.  I'm sure you already know, but having a single Maven configuration produce more than one artifact would be, although possible, not the normal way of doing things.

Let me know if you'd like any additional info.



Attachment(s):
teamcityMavenAnalysis2.png
teamcityMavenAnalysis1.png
0
Comment actions Permalink

Hello Ryan,

Thank you for your notes. I'll try to figure out what's going wrong.
Is it possible for you to send me your pom files so that I could debug it locally?

I mean that I would appreciate it very much if you could send me all the pom files related to the problem. No sources needed. Just pom files with appropriate directory layout.
You can send to teamcity-feedback@jetbrains.com, if you don't want them to be exposed in the public forum.

Thanks a lot!

0
Comment actions Permalink

Hey Sergey,

I'll create a test project for you that does the same thing and attach it here when I'm done.

0
Comment actions Permalink

Great!

Thank you very much for your effort!

0
Comment actions Permalink

Here's a skeleton project that doesn't behave correctly for me.  I've attached a screenshot of the skeleton-services-core module and put a red box around the area that is incorrect.  Here's some info about the project setup:

skeleton-project - The parent pom.  Controls versioning for dependencies and plugins.

skeleton-domain - Set up as a POJO module for JavaEE entity objects.  It uses two profiles; glassfish and jboss.  All they do is filter different persistence.xml files for glassfish or jboss since the implementation is vendor specific.  These profiles will not be necessary once EJB 3.1 standardizes JNDI naming.

skeleton-services-core - Core services EJB module.  Depends on skeleton-domain.  Nothing special here.

skeleton-services-java - Java (RMI) based service adapters and special use cases for Java UIs.  Most of the implementation would be deferred to skeleton-services-core.  Again, nothing special as far as Maven is concerned.  It's also an EJB module and depends on skeleton-services-core.

third-party-artifacts - The skeleton-domain module is dependent on the JavaEE API.  I included the .jar and the .pom so you don't have to go looking for it.  It will need to be installed locally or into a local maven proxy (repository).

I add all 4 modules using one build configuration for each (4 build configurations total).  If you want any more info about what I use for settings let me know and I'll elaborate.

Have a good weekend!
Ryan



Attachment(s):
skeleton-project.rar.zip
TeamCitySkeletonConfig.png
0
Comment actions Permalink

Hello Ryan,

Thank you for your example. I difined the build configurations exactly as you described and got the same result.

And I think this is the correct behavior. See my explanations below.

skeleton-project is an agregator project that consists of three modules: skeleton-domain, skeleton-services-core, skeleton-services-java. In this sense the build configuration "skeleton-project" produces four artifacts:

1) ca.jptech.skeleton.skeleton-project.pom.0.1-SNAPSHOT
2) ca.jptech.skeleton:skeleton-domain:jar:0.1-SNAPSHOT
3) ca.jptech.skeleton:skeleton-services-core:ejb:0.1-SNAPSHOT
4) ca.jptech.skeleton:skeleton-services-java:ejb:0.1-SNAPSHOT


Build configuration "skeleton-domain" is represented by a single module without submodules and produces a single artifact: ca.jptech.skeleton:skeleton-domain:jar:0.1-SNAPSHOT

So now we have TWO build configurations ("skeleton-project" and "skeleton-domain") which produce the SAME artifact - ca.jptech.skeleton:skeleton-domain:jar:0.1-SNAPSHOT

Thats why in build configuration "skeleton-services-core" you see both "skeleton-project" and "skeleton-domain" configurations in the list.


In general, Maven artifacts relate to TeamCity build configurations as many-to-many. And this is the main problem of automatic dependency resolution.
So currently the list just show what other configurations may produce artifacts which this maven build is dependent of.

Maybe the name of the section is confusing. I've changed it to "Related Build Configurations".

0
Comment actions Permalink

Hi Sergey,

Thank you for taking the time to look at this and explain it.  I understand what that section is intended for now and everything is correct in my main project.  Using the sample project I will try to explain why I was confused.

When I build skeleton-services-core from the command line I think of it as producing one artifact (skeleton-services-core-0.1-SNAPSHOT.jar) and being dependent on one artifact (skeleton-domain-0.1-SNAPSHOT.jar).  I wasn't thinking of the process in the context of the build server and the way it needs to analyze + manage a chain of dependencies.  Now that you've explained it, it makes perfect sense.  When I run the build for skeleton-services-core it will cause both artifacts to be produced as part of the build chain.

I'm not positive if 'build chain' is the correct term.  I mean when the build server analyzes all build configurations and determines which ones need to be built an the order they need to be built in.

Thanks again for taking the time to help,
Ryan

0
Comment actions Permalink

Hello Ryan,

I really understand your confusion.

In our future Maven support development we're going to move towards more artifact oriented logic in contrast to the current build configuration oriented logic.
This should significantly simplify and automate Maven-based build production and I think this would look more as you expected.

Again, thank you for all your efforts

0

Please sign in to leave a comment.