On 25 November 2012 22:14, Peter Janes <[email protected]>wrote:

> Anders Hammar <[email protected]> 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 <[email protected]> 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
>>>> <[email protected]>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:
>>>>>
>>>> [email protected].****org<dev-unsubscribe@maven.**apache.org<[email protected]>
>> >
>>
>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>>
>>>>>  --
>>> "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:
>>>
>> [email protected].****org<dev-unsubscribe@maven.**apache.org<[email protected]>
>> >
>>
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
> --
> "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: 
> [email protected].**org<[email protected]>
>
> For additional commands, e-mail: [email protected]
>
>

Reply via email to