FAQ
I've had a look at the code. Kill it!

On 25 November 2012 20:22, Benson Margulies wrote:

Given that all it turns out to *do* is to construct finalName, I am
perfectly willing to kill it. If bentmann decides to relax his vow of
never talking to us, I'm happy to hear what he says.


On Sun, Nov 25, 2012 at 2:58 PM, Stephen Connolly
wrote:
No. Not expected to remember... But sometimes one does... especially
bentmann in my experience ;-)
On Sunday, 25 November 2012, Anders Hammar wrote:

Just a check, is one supposed to remember why one did something 4.5
years
ago? I can hardly remember what I did last week....

I'm currently searching JIRA to see if I can find a ticket that would
match
Benjamin's fix.

/Anders


On Sun, Nov 25, 2012 at 8:45 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
So it is not to create the shaded artifact at a different coordinate
without requiring the creation of an additional module?

I agree it seems a tad insane, but if we could get bentmann to chime
in
as
to what it is actually supposed to do, then I think we can make a
correct
decision...

Of course the code may not work... Which is a different issue...

But having to create a module with a Pom that has to be kept in sync
just
to put the shaded artifact with dependency reduced Pom at a different
coordinate... Does seem wasteful... Otoh how is the reactor to know
the
artifact will magically appear and hence produce the correct build plan...
So I have nearly convinced myself that it is insane... But let's ask!
On Sunday, 25 November 2012, Benson Margulies wrote:

I am fairly depressed here, and I agree with Anders.

The shadedArtifactId was added in svn rev 640405 by bbentman.

The log for that change consists of:
------------------------------------------------------------------------
r640405 | bentmann | 2008-03-24 09:17:58 -0400 (Mon, 24 Mar 2008) |
1
line
o Added svn:eol-style=native
------------------------------------------------------------------------
That really does not shed any light. Further, the name is completely
misleading. it does not, in fact, change how the attach happens, it
is
just a baroque means of specifying the final name in pieces. So I
modify my proposal to consist of:

attach

attachClassifier

outputDirectory

finalName

no sub-objects.






On Sun, Nov 25, 2012 at 2:11 PM, Benson Margulies <
bimargulies@gmail.com
wrote:
Anders,

I'm willing to go on a history expedition to see who added the
feature. The MavenProjectHelper API suports this feature, let
alone
the naked MavenProject API.


On Sun, Nov 25, 2012 at 2:06 PM, Anders Hammar <anders@hammar.net
wrote:
How would you attach an artifact with a DIFFERENT artifactId
than
the
project? It doesn't make sense.
This is *already* a feature of the plugin. I didn't invent it,
I'm
just trying to clean up how your configure it.
Why would you try to clean up how to configure something that
doesn't
make
sense and is plain wrong? Maven is about best-practices and we
should
help
people do the right thing.

And btw, finalName should be nuked out of the Maven world. :-)

/Anders


I would vote for doing changes that make it impossible to use
the
plugin
as
I-would-like-to-create-any-file-the-way-i-used-to-with-Ant
solution.
I
think that the possibilities to alter the final name of the
built
artifact
fools people into thinking that you can specify the name of
the
artifact.
You migth be able to specify the name of the build file in the
build
folder, but that's not something you should create a build
solution
around.

Well, finalName in the pom it
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 12 of 19 | next ›
Discussion Overview
groupdev @
categoriesmaven
postedNov 25, '12 at 3:56p
activeNov 25, '12 at 11:06p
posts19
users5
websitemaven.apache.org
irc#maven

People

Translate

site design / logo © 2021 Grokbase