Just keep in mind, that overriding the finalName only works for adjusting the local file name when it's not attached to the build (in addition to the directory name in an assembly). The final name is not used when it is deployed to a Maven server or installed to the local repository. In those cases, the artifact will be renamed according to the module's artifactId it is in. It works for Accumulo only because we explicitly attach it to the module with the desired artifactId.
On Fri, May 20, 2016 at 2:49 PM Josh Elser <els...@apache.org> wrote: > Overriding the finalName is what I was assuming I'd need to change, but > thanks for the extra context, Christopher. > > At least I know where I can look if I find the time to try to fix this > for the next sucker.. I mean release manager ;) > > Christopher wrote: > > 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 > >>> > >>> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
