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<ctubb...@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<els...@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<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
---------------------------------------------------------------------
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
