On 22 May 2016 at 03:54, Josh Elser <els...@apache.org> wrote: > It's not a problem, it's an inconvenience. > > Ideally, Maven builds the artifacts with the intended names. This creates > consistency through every VOTE message, xsum/sig verification automation, > website links, and dist.a.o files.
Does not follow, see below. > Renaming them by hand just makes things harder, IMO. The vote mail should be on the dist/dev archives for the archives intended for the ASF mirrors and on Nexus for the Maven jars. The distribution files don't belong in Maven Central and they should be copied/deleted from Nexus to dist/dev before the vote. So there should be no inconsistency. The only extra manual stage is the rename which must be done before the dist/dev files are committed. I agree it would be simpler if no rename was involved. But it does not affect vote consistency. == Note: the ASF archive files are also created under dist/target. They don't have the -distribution suffix. And there are associated .asc files. However Maven only creates the hashes when deploying the files, and it also appends the -distribution suffix. So a better solution might be to configure Maven to not deploy the ASF archives but to create the hashes instead. This should work for all components, not just VFS. I think this has been looked at, but for single module components the gain is not that great for the effort involved, so it was not pursued. > > Ralph Goers wrote: >> >> 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 >> > > --------------------------------------------------------------------- > 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
