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:29:22 GMT
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