commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VFS] Final steps for 2.1
Date Fri, 20 May 2016 18:30:43 GMT
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
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message