commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [VFS] Final steps for 2.1
Date Sun, 22 May 2016 02:54:41 GMT
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. Renaming them by hand 
just makes things harder, IMO.

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<ctubbsii@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<elserj@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<ctubbsii@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<sebbaz@gmail.com>   wrote:
>>>>>
>>>>>> On 20 May 2016 at 15:39, Josh Elser<elserj@apache.org>   wrote:
>>>>>>> Benedikt Ritter wrote:
>>>>>>>> Hello Josh,
>>>>>>>>
>>>>>>>> Josh Elser<elserj@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message