Don’t you have to copy the files into the dist directory so you can commit them? Why is renaming them during that step a problem?
Ralph > On May 20, 2016, at 1:57 PM, Christopher <ctubb...@apache.org> wrote: > > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
