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
