commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [VFS] Final steps for 2.1
Date Fri, 20 May 2016 18:49:06 GMT
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<>  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<>  wrote:
>>> On 20 May 2016 at 15:39, Josh Elser<>  wrote:
>>>> Benedikt Ritter wrote:
>>>>> Hello Josh,
>>>>> Josh Elser<>   schrieb am Fr., 20. Mai 2016 um
>>> 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
>>>>>>> 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
>>> use
>>>>>>>   some help (I knew what needed to be done already, but, obviously,
>>>>>>>   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]
>>>> 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-vfs-${commons.release.version}</
>>> 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:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message