Hi Graham, With that proposal you would still get the artifact id with potentially some different version number.
Imagine a jar with the following maven coordinates (I know that this is not the bundle): <dependency> <groupId>net.redora</groupId> <artifactId>api</artifactId> <version>1.9.2</version> </dependency> The filename for this would be api-1.9.2.jar which is hardly a very distinguishing name especially if there is another jar like <dependency> <groupId>com.google.code.jscep</groupId> <artifactId>api</artifactId> <version>1.3</version> </dependency> which will get the filename api-1.3.jar... With maven filenames the groupId is encoded in the path, so the bare filename may not be very distinguishing. I still favor something with the bundle symbolic name in the filename, as these names are the ones you see for the deployed artifacts if you look into the container later. Best regards Stephan From: Graham Charters [mailto:[email protected]] Sent: Mittwoch, 11. September 2013 17:36 To: [email protected] Subject: Re: name of archived dependencies in esa-maven-plugin Hi Stephan, I started looking into this and am thinking that what we have today and what you propose are both wrong. I think the file name should be the same file name you would download from maven central, not something fabricated based on ids or symbolic names. This would mean changing: zipArchiver.addFile(artifact.getFile(), artifact.getArtifactId() + "-" + artifact.getVersion() + "." + (artifact.getType() == null ? "jar" : artifact.getType())) to zipArchiver.addFile(artifact.getFile(), artifact.getFile().getName()); I think this is a good approach because the same artifacts may been obtainable from other routes and if the names are consistent, this can be useful. Do you have any strong opinions against this change? Regards, Graham. On 28 August 2013 06:30, Siano, Stephan <[email protected]<mailto:[email protected]>> wrote: Hi Graham, When you are at looking at the stuff, you might also look into https://issues.apache.org/jira/browse/ARIES-1103 . The bundle version is not taken from the manifest, but is somehow calculated from the maven version. This may work for the most common cases, but can break with qualifiers, especially with snapshots. Best regards Stephan From: Graham Charters [mailto:[email protected]<mailto:[email protected]>] Sent: Dienstag, 27. August 2013 14:22 To: [email protected]<mailto:[email protected]> Subject: Re: name of archived dependencies in esa-maven-plugin Hi Stephan, I don't think the current naming approach you are observing was by-design. thanks for the patch. I'll take a look. Regards, Graham. On 22 August 2013 08:03, Siano, Stephan <[email protected]<mailto:[email protected]>> wrote: Hi, I have created jira entry for this (https://issues.apache.org/jira/browse/ARIES-1101) and attached a patch. I put this to the Subsystem component because I couldn't find any component for the esa-maven-plugin. Best regards Stephan From: Siano, Stephan [mailto:[email protected]<mailto:[email protected]>] Sent: Mittwoch, 21. August 2013 10:48 To: [email protected]<mailto:[email protected]> Subject: name of archived dependencies in esa-maven-plugin Hi, the esa-maven-plugin names artifacts bundled in an esa always [artifactId]-[version].[type], so a bundle with the maven corrdinates com.foo:bar:7.1.2:jar is named "bar-7.1.2.jar"in the bundle (see the coding below): zipArchiver.addFile(artifact.getFile(), artifact.getArtifactId() + "-" + artifact.getVersion() + "." + (artifact.getType() == null ? "jar" : artifact.getType())); Is there any reason for this? It might be better to use the bundle symbolic name or subsystem symbolic name or make this configurable. Just an example for the issue: Let us create two subsystems with the maven coordinates com.foo:baz:1.0.0:esa and com.bar:baz:1.0.0:esa. The esa-maven-plugin will generate the subsystem symbolic names com.foo.baz and com.bar.baz for it. If both are included (and stored) within a third subysystem with the same esa-maven-plugin, both are supposed to have the filename baz-1.0.0.esa. Best regards Stephan
