FAQ

On 25 November 2012 22:14, Peter Janes wrote:

Anders Hammar wrote:
The Enunciate plugin "attaches" its own artifact with a unique
artifactId.


Do you have an example of this? I checked the docs (
http://enunciate.codehaus.org/**executables.html#maven<http://enunciate.codehaus.org/executables.html#maven>)
and I can't see
this.
The install and deploy goals are what I was referring to.


I'm not sure of the implementation details, but it's got its own
install-artifact and deploy-artifact goals that do the work.

Those just work the same way as install:install-file and
deploy:deploy-file, which are not supposed to be bound a project's
build
lifecycle. At least that's how I read the plugin's documentation.
There's better documentation on the Codehaus wiki:

http://docs.codehaus.org/**display/ENUNCIATE/Client-side+**
artifacts+and+Maven<http://docs.codehaus.org/display/ENUNCIATE/Client-side+artifacts+and+Maven>

"Instead of attaching the client-side artifacts to the project, a better
solution would be to deploy the artifacts with their own (generated) pom"
that doesn't include the project's dependencies (which is why the goals
were added).

That screws up the reactor's build plan though... which turns it into a
completely shitty idea



/Anders

(Just to note that there's at least one other plugin doing something
similar, not making a claim that it's right or wrong to do so.)

Anders Hammar wrote:

How would you attach an artifact with a DIFFERENT artifactId than the
project? It doesn't make sense.
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.

/Anders


On Sun, Nov 25, 2012 at 4:55 PM, Benson Margulies
wrote:

Shade has a collection of related parameters for controlling where
the
results end up. To me, they feel like a collection of individual
items
that are fairly confusing to the reader of the documentation.
Since I'm planning to bump the major version and change the
behavior,
I'd like to consider rationalizing all of them.
It seems to me that there are, in fact, three modes of operation:

1) replace the primary artifact of the project.
2) attach an artifact with the user's choice of artifactId and

classifier.
3) just drop a file someplace.
In modes (1) and (2), it's also reasonable for the user to control

the
filename in the output directory, since every other plugin seems to
allow that.

So, what do people think of the following:

Four parameters:

<attach>true/false</attach>

<attachArtifact>
<artifactId/>
<classifier/>
</attachArtifact>

<outputDirectory/>
<finalName/>

This puts all the information about the attached result in one
place.
Shade is the only plugin I know that allows you to attach with your
choice of artifactId.

To replace the primary artifact, the user would write:

<artifactId>${project.****artifactId}</artifactId>
<classifier/>

The defaults would be:

<attach>true</attach>

<attachArtifactId>
<artifactId>${project.****artifactId}</artifactId>
<classifier>shaded</****classifier>
</attachArtifactId>

<outputDirectory>${project.****buildDirectory}</****outputDirectory>



<finalName>${attachArtifact.****artifactId}-${attachArtifact.****
classifier}-${project.version}****.jar</finalName>


------------------------------****----------------------------**--**
---------
To unsubscribe, e-mail:
dev-unsubscribe@maven.apache.****org<dev-unsubscribe@maven.**apache.org<dev-unsubscribe@maven.apache.org>
For additional commands, e-mail: dev-help@maven.apache.org


--
"Fighting a war is easy. Destroying is easy. Building a new world out of
what's left of the old, that is what's hard." —J. Michael
Straczynski



------------------------------****----------------------------**
--**---------
To unsubscribe, e-mail:
dev-unsubscribe@maven.apache.****org<dev-unsubscribe@maven.**apache.org<dev-unsubscribe@maven.apache.org>

For additional commands, e-mail: dev-help@maven.apache.org

--
"Fighting a war is easy. Destroying is easy. Building a new world out of
what's left of the old, that is what's hard." —J. Michael Straczynski


------------------------------**------------------------------**---------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<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 | 17 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