I think we also had to override the finalName in the root execution of maven-assembly-plugin, so unpacking the source tarball wouldn't have a directory called "accumulo-project-<version>", and instead would look like "accumulo-<version>".
On Fri, May 20, 2016 at 2:29 PM Christopher <ctubb...@apache.org> wrote: > 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 >> >>
