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) 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 "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). >/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<[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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
