HI Richard, I've seen both notations used; however, I've only seen the string name approach in plugins such as jar and assembly, where they were used as filters to exclude elements from an established dependency list.
I have written a plugin, on the other hand, which needed to pull artifacts from the repository, and used the artifacts object, with each coordinate in a separate element. So there's good precedent for the string name approach, although I've never used it. I would check the assembly plugin and manifest utility to see how they are handled. - Russ On Jul 16, 2013, at 11:43 PM, Richard Sand <rs...@idfconnect.com> wrote: > Hi Russell - the plugin I've been working on obfuscates certain artifacts of > a project. I'm using ResolutionScope.COMPILE_PLUS_RUNTIME to gather the > input artifacts, then the plugin configuration determines which of these > available artifacts should be obfuscated. > > Basically the question is whether my plugin configuration can easily use the > xml elements to specify an artifact by way of some helper class in the API, > or should I just stick to specifying each artifact by its String name, e.g. > right now I configure the plugin as follows: > > <configuration> > <inputArtifacts> > > <inputArtifact>com.somegroup:someartifact</inputArtifact> > </inputArtifacts> > ..... > > So my question is, is it better (more "maven'ish") to specify it this way > instead? And if so, what object from the API can I use in the @Param > inputArtifacts object should I use instead of String? > > <configuration> > <inputArtifacts> > <inputArtifact> > <groupId>com.somegroup</groupId> > <artifactId>someartifact</artifactId> > <inputArtifact> > </inputArtifacts> > > Best regards, > > Richard > > -----Original Message----- > From: Russell Gold [mailto:r...@gold-family.us] > Sent: Saturday, July 13, 2013 10:28 PM > To: Maven Users List > Subject: Re: input artifacts to plugin > > HI Richard, > > What do you want to do? If all you want is the compile dependencies: > > 1. Configure the plugin to require compile and runtime dependency > resolution: > > @Mojo( ... requiresDependencyResolution = > ResolutionScope.COMPILE_PLUS_RUNTIME) > > 2. Specify a parameter configured to receive project.compileClassElements > > /** > * Compile classpath of the maven project. > */ > @Parameter(defaultValue = "${project.compileClasspathElements}") > private List<String> projectCompileClasspathElements; > > On Jul 12, 2013, at 12:45 PM, Richard Sand <rs...@idfconnect.com> wrote: > >> Hi all - another hopefully simple question: >> >> Can I add a custom configuration property to my plugin which takes in >> the normal <dependencies><dependency>......</ schema used in the build? > E.g. >> instead of calling mavenProject.getArtifacts() to get a Set<Artifact> >> for the build, I'd have a @Property Set<Artifact> which maven will >> still resolve & manage but specifically for use by the plugin. >> >> As a sample, this is what I want to put into the pom.xml: >> >> <configuration> >> <includedArtifacts> >> <includedArtifact> >> <groupId>com.somegroup</groupId> >> <artifactId>someartifact</artifactId> >> <version>1.0.1</version> >> </includedArtifact> >> </includedArtifacts> >> ........ >> >> And in the plugin code: >> >> /** >> * Other artifacts to include in obfuscation >> */ >> @Property >> Set<Artifact> includedArtifacts >> >> This doesn't work of course - Artifact cannot be instantiated... can >> someone give me some hints for which portions of the API can help >> achieve what I'm trying to accomplish? >> >> Another option I have is to use a Set<String> and just enter the >> toString representation of an artifact, and then look through >> mavenProject.getArtifacts() to find a match. That just seems a hack to >> require two different formats for specifying artifacts, but if it's >> the only way, so be it. >> >> Thanks for any input! >> >> Richard Sand | CEO >> IDF Connect, Inc. >> 2207 Concord Ave, #359 >> Wilmington | Delaware 19803 | USA >> Office: +1 302 425 0516 | Fax: +1 856 866 1899 >> Mobile: +1 267 984 3651 >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > ----------------- > Come read my webnovel, Take a Lemon <http://www.takealemon.com>, and listen > to the Misfile radio play <http://www.gold-family.us/audio/misfile.html>! > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > ----------------- Come read my webnovel, Take a Lemon <http://www.takealemon.com>, and listen to the Misfile radio play <http://www.gold-family.us/audio/misfile.html>!
