We had a similar problem in Accumulo. We wanted the artifact ID of our tarballs to just be "accumulo". So our parent pom is now called "accumulo-project", and one of the modules (that creates the tarballs) is called just "accumulo".
This works for our -bin tarball (classifier: "bin" in the assembly descriptor), but is more complicated for the -src tarball which is created at the root of the project. For the -src tarball, we let the apache-release profile run its execution of the maven-assembly-plugin, but we use pluginManagement to override the default behavior of that plugin so it does not attach the artifact by default. Then, in the "accumulo" module, we use the build-helper-maven-plugin to attach this artifact with the "src" classifier, right next to the -bin tarball. It a bit complicated, but it works, and it's pretty understandable once you realize why it's done that way. Perhaps something like that might be needed here, since this is in a similar multi-module situation. On Fri, May 20, 2016 at 11:36 AM sebb <seb...@gmail.com> wrote: > On 20 May 2016 at 15:39, Josh Elser <els...@apache.org> wrote: > > > > > > Benedikt Ritter wrote: > >> > >> Hello Josh, > >> > >> Josh Elser<els...@apache.org> schrieb am Fr., 20. Mai 2016 um 05:28 > Uhr: > >> > >>> > One more (final?) snafu: turns out I used the "wrong" name for the > >>> > artifacts in dist.a.o which caused the website to have the wrong > >>> > links. > >>> > > >>> > Just corrected that, sadly the website will continue to be a little > >>> > off > >>> > for another 24hrs. These are some more places that the docs could > use > >>> > some help (I knew what needed to be done already, but, obviously, I > >>> > didn't do it quite right on my own). > >>> > > >> > >> > >> Are you talking about [1]? Please add any improvements you find > necessary. > >> I've done it so often that I'm probably unaware of little > inconsistencies. > >> :-) > >> > >> Benedikt > >> > >> [1]http://commons.apache.org/releases/release.html > >> > > > > Well, the problem this time is the inconsistency between what file names > > that Maven generates and what the website is expecting the names to be > > (notably the "-distribution" for both binary and source releases and a > > "-bin" for the binary release are present built by Maven, but not > expected > > by the website). > > The -bin suffix is controlled by the pom used by the commons:download > plugin to generate the website source file. > > The entry <commons.binary.suffix /> means the suffix is suppressed by > the plugin. > > The download name is defined by > > <commons.release.name>commons-vfs-${commons.release.version}</ > commons.release.name> > > This could be changed to add the -distribution suffix if it's > difficult to tell Maven not to add it. > > > I think this is ultimately something else that should be fixed in the > Maven > > build (rather than docs) now that I give it some more thought. Ideally, > we > > just create all of the files with the correct name during the build and > we > > don't touch them after that :) > > Yes. > > It looks as if the Maven install plugin is responsible for adding the > -distribution suffix based on the artifactId from the dist module. > > We cannot remove the -distribution suffix from the id as it would then > clash with the core module. > > I don't know enough Maven to solve this. > > But a work-round would be to accept the -distribution suffix and just > ensure the download page agrees. > That's trivial to do (can even be done manually by editting the xml) > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
