[
https://issues.apache.org/activemq/browse/SM-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63230#action_63230
]
Kari J. Niemi commented on SM-2008:
-----------------------------------
Hi, thanks for taking the issue.
As far as I can see the problem is caused by these lines in
GenerateServiceAssemblyMojo.java
---------------
* @parameter expression="${project.build.finalName}.zip"
private String finalName;
...
createArchive(new File(outputDirectory, finalName));
...
archiver.setOutputFile(installerFile);
...
projectHelper.attachArtifact(project, "zip", null, new File(outputDirectory,
finalName));
---------------
So the jar and zip files get created with the same maven coordinates.
In GenerateComponentMojo.java the attached zip Artifact is given the
"installer"-classifier:
projectHelper.attachArtifact(project, "zip", "installer", new
File(outputDirectory, installerName));
And because of that the zip artifact can referenced using the
<classifier>installer</classifier> in the maven dependency.
I'm feeling lazy about creating a simple test project, but if you would really
need it, I could try of course...
> jbi maven plugin: service assembly & attached artifact
> ------------------------------------------------------
>
> Key: SM-2008
> URL: https://issues.apache.org/activemq/browse/SM-2008
> Project: ServiceMix
> Issue Type: Bug
> Components: tooling
> Reporter: Kari J. Niemi
> Assignee: Lars Heinemann
>
> jbi maven plugin would seem the behave badly when creating a service
> assembly. At least when the pom file with packaging jbi-service-assembly
> contains only dependencies to jbi-service-units (and the project for that
> pom.xml does not contain any java code in src/main/java), the plugin first
> creates a jar, installs it as a _zip_, then creates the correct zip and
> installs it as an attached artifact.
> If I got it right from the plugins source code, it's contradicting the
> "correct way" that's referred here:
> http://maven.40175.n5.nabble.com/Missing-search-results-with-assembly-attached-artifacts-td131996.html
> "What happens in those cases is that you end up with empty jar, and a zip
> that has _same_ coordinates as main artifact, but only different extension.
> Since Nexus reads POM to figure out the packaging, it will think in these two
> cases it is "JAR"."
> I ran in to this problem when trying to package the service assebly using the
> maven-rpm-plugin. When using dependencies to package the rpm, it just keeps
> packing the jar whiles of the service assembly -not the zip file at all. I
> suppose it's because the jar & zip files have the same maven coordinates.
> With the BCs/SEs the zip file gets the classifier "installer", and with that
> I can get the BC/SE zip file to the rpm(but I'm also getting the jar there
> even if I'm setting the dependency type to zip...)
> maven 2.09,2.2.1,3 tried. latest beta of maven-rpm-plugin,
> jbi-maven-plugin:4.0,4.3...errrr....at least some combinations of these...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
