Make use of maven artifact when computing location for deployable and dependency

Hi Tuomas

Can you please explain this with an example? I don't understand the idea / issue / requirement :o

Cheers

What I'm trying to achieve is hot code replacement without redeploying.

I'd like to see deployable location derived from file path of the maven artifact as for instance ~/workspace/myproject/target/test-classes/ instead of having the location computed to ~/workspace/myproject/target/myproject-0.0.1-SNAPSHOT-tests.jar by cargo. In most cases the computed location and the artifact file are identical but not when using M2E 'Resolve Workspace Artifacts'.

In order to get a hold to the real artifact location and not the computed one would be to retrieve the location directly either from MavenProject::getArtifact MavenProject::getAttachedArtifact where the Artifact::getFile is already pointing to correct location. I checked the code so far that the artifacts mentioned above could be merged to the set of other artifacts already present in cargo project.

These artifacts are also used to calculate the classloader and classpaths that are provided to the (embedded) container. Currently I seem to be missing the deployables that maven project itself is providing. That is the deployables that get their location via computeLocation method.

–
Tuomas

Thanks,

That is a good workaround which I honestly should brought up myself in the first place, because it makes this makes this a rather minor issue. I'd appreciate it if you could still bare with me a bit longer.

<location>$

</location> does in deed point to the correct location which suits me well when I manually use cargo:run and hot code replace when fixing tests. But when using phased integration test goals the location still points to test output directory. IT tests will pass fluently but they are not tested using the attached test artifact which location the M2E dynamically computes based on the maven lifecycle.

So what I'm really after is a convention over configuration for using projects output directory for cargo:run and (attached) artifact project.build.testOutputDirectory}. I can achieve this by duplicating/inheriting the container configuration to cargo:run goal and just changing locations of project deployables but this solution became clear to me only after debugging the cargo plugins source code.

–
Tuomas

Here's a patch that I currently use although certainly I can live with the workaround as well. It looks a bit of a hack but that kept the patch focused on the task at hand avoiding the type vs. packaging issue.

This example configuration could be integration tested as usual. cargo:run by itself would utilize hot code replacement without configuration workarounds that would have to be documented for future reader <https://github.com/TuomasKiviaho/org.codehause.cargo.container.osgi/blob/master/README.md>

Hi Tumoas

Your patch makes many tests fail:

Tests in error: 
  testCreateConfigurationWithAPropertyWithNullValue(org.codehaus.cargo.maven2.configuration.ConfigurationTest)
  testAddResources(org.codehaus.cargo.maven2.configuration.ConfigurationTest)
  testComputeLocationWhenEjbPackaging(org.codehaus.cargo.maven2.configuration.DeployableTest)
  testComputeLocationWhenUberwarPackaging(org.codehaus.cargo.maven2.configuration.DeployableTest)
  testComputeLocationWhenJBossSarPackaging(org.codehaus.cargo.maven2.configuration.DeployableTest)
  testComputeLocationWhenJBossHarPackaging(org.codehaus.cargo.maven2.configuration.DeployableTest)
  testComputeLocationWhenJBossSpringPackaging(org.codehaus.cargo.maven2.configuration.DeployableTest)
  testComputeLocationWhenJBossEsbPackaging(org.codehaus.cargo.maven2.configuration.DeployableTest)
  testComputeLocationWhenAnyPackagingWithDeployableTypeFile(org.codehaus.cargo.maven2.configuration.DeployableTest)
  testSettingANullDeployableProperty(org.codehaus.cargo.maven2.configuration.DeployableTest)

... did you really test it?

Thank you

I forgot to include patches for the tests but here they are as well. I hope this helps.

–
Tuomas

Looks much better now

Committed revision 3271. Thank you.