release prepare : when generate-reactor-projects can't resolve transitively dependency.

the problem does not arise because of transitive dependencies but because of the type used for the dependency.
When using a specific type, example :

<dependency>
<groupId>fr.paris.lutece</groupId>
<artifactId>lutece-core</artifactId>
<version>2.2.1</version>
<type>lutece-core</ type>
</dependency>

The release prepare phase don't work, because the dependencies is not found.

When using no type, example :

<dependency>
<groupId>fr.paris.lutece</groupId>
<artifactId>lutece-core</artifactId>
<version>2.2.1</version>
</dependency>

The release prepare phase work correctly.

This issue is still present in Continuum 1.2.2 with Maven 2.0.9.
Has someone any info about the resolution of this issue?

I just modified the GenerateReactorProjects Class of the continuum-release module to invoke the usual "build()" instead of the "buildWithDependencies()" Method of the MavenProjectsBuilder (see attached Source snippet).
This resolves the problems with transitive Dependencies in my project.

I didn't had the time to read about the exact difference of this two methods, the idea to change it was the result of reading this comment in the "buildWithDependencies()" Method

// ----------------------------------------------------------------------
// Typically when the project builder is being used from maven proper
// the transitive dependencies will not be resolved here because this
// requires a lot of work when we may only be interested in running
// something simple like 'm2 clean'. So the artifact collector is used
// in the dependency resolution phase if it is required by any of the
// goals being executed. But when used as a component in another piece
// of code people may just want to build maven projects and have the
// dependencies resolved for whatever reason: this is why we keep
// this snippet of code here.
// ----------------------------------------------------------------------

I would appreciate if someone could look over this workaround

Continuum: 1.2.2
Maven: 2.0.9

I'm using Contiuum 1.3.2 and Maven 2.0.9 and i have this issue.

My dependency is:

<dependency>
<groupId>datacom.ivs.service</groupId>
<artifactId>ivs-services-ejb</artifactId>
<version>${project.version}</version>
<type>ejb</type>
</dependency>

And it works when i run release:prepare from the command line, but not through continuum.

I've tried changing the release preparationGoals to use clean install but still have the issue.

Any ideas?

This might be related to CONTINUUM-1997

Is this still happening with the latest release?

If so, we need an example project that demonstrates the problem so we can use it as an integration test.

This has votes and a patch, still not sure if it's a problem in the latest release, but I'll add it to the backlog for someone to take a look.

Attaching a project that reproduces the bug. Releases occur normally if executing from the command line, but releasing through continuum fails (on release:prepare at release phase generate-reactor-projects).

For the record, I have reproduced this on continuum 1.3.5 running under jetty with Java6.

I think this is the same problem I had performing a release on NPanday as well that I was meant to file.

In continuum-1.3.5, the stack trace is:

Thread [pool-3-thread-1] (Suspended (breakpoint at line 395 in DefaultMavenProjectBuilder))	
	DefaultMavenProjectBuilder.buildWithDependencies(File, ArtifactRepository, ProfileManager, TransferListener) line: 395	
	DefaultMavenProjectBuilder.buildWithDependencies(File, ArtifactRepository, ProfileManager) line: 343	
	GenerateReactorProjectsPhase.addModules(List<MavenProject>, MavenProject, ArtifactRepository) line: 153	
	GenerateReactorProjectsPhase.getReactorProjects(ReleaseDescriptor) line: 111	
	GenerateReactorProjectsPhase.execute(ReleaseDescriptor, Settings, List) line: 78	
	DefaultReleaseManager.prepare(ReleaseDescriptor, Settings, List, boolean, boolean, ReleaseManagerListener, ReleaseResult) line: 194	
	DefaultReleaseManager.prepareWithResult(ReleaseDescriptor, Settings, List, boolean, boolean, ReleaseManagerListener) line: 107	
	PrepareReleaseTaskExecutor.execute(ReleaseProjectTask) line: 44

From initial inspection, it appears that the submitted code might be appropriate. Why does continuum use buildWithDependencies(...)? I ran the attached build under maven 2.0.9 and it is never called. Instead, build(...) [line 198] is called. It also isn't called from anywhere else in the continuum codebase.

I've attached a patch based on continuum 1.3.5. It replaces usage of buildWithDependencies() with build() in continuum-release.

is there anything using the dependency artifacts that relies on them being resolved?

I tried reproducing this using the attached project and the build fails in ear-module when I built it on Continuum. It wasn't able to resolve the har-module jar because of the custom type. When I built the project from the root dir in the command line, everything builds successfully. But if I build each module individually, I also get the same error (failed to resolve artifact) in ear-module from the command-line.

Continuum builds each module/project separately that's why the build is failing in Continuum as well. Did you encounter the same problem if just building the project?

To get to the releasing part, I changed the default build defs to just run 'clean' in order to get a successful build for ear-module. I also encountered the same error posted above during release:prepare.

Moving up the jboss-packaging-maven-plugin config from har-module to the root pom in the test project fixed the build error when building each module/project individually. The failed to resolve artifact error still encountered during release:prepare.

I think it is sufficient to use MavenProjectBuilder#build(...) instead of MavenProjectBuilder#buildWithDependencies(...) since we only need to get the projects to be added to the reactor in the GenerateReactorProjectsPhase and not the transitive dependencies.

Thanks for the patches Sebastian and Brent! I applied CONTINUUM-1814.patch to trunk -r917918.

Changing fix version to 1.3.6. Merged the changes to 1.3.x branch -r917967.