Since ${project.version} contains dots and CVS tags don't allow that, I
can't just drop the version into the tag like that.But this is just one aspect of the problem I'm describing. Here's another: when doing a release, there are other things I would like to verify are correct before running the release plugin. I'd like to have the developers run only a single plugin (that I wrote) which does those verifications and then executing Mojos in the release plugin. Can I do that much using the mini-lifecycle thing (which I haven't learned much about to this point)? In that case I wouldn't need my plugin to supply the configuration properties for the release plugin, but there are other situations where I need to do this sort of thing. ..David.. -----Original Message----- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 16, 2005 7:16 PM To: Maven Users List Subject: Re: [m2] Wrapping an existing Mojo with a proxy Mojo Eric: yes, we have an open bug to allow this to be in settings.xml David: can you put the template in the parent pom though? <tag>my-${project.artifactId}-custom-${project.version}-tag</tag> - Brett On 11/16/05, Eric Redmond <[EMAIL PROTECTED]> wrote: > archetype is for creating projects... there is not yet a POM to > inherity from. ;) > > On 11/15/05, David Jackman <[EMAIL PROTECTED]> wrote: > > > > Well, since it's the same value for all projects, you can just > > specify it in the parent POM (assuming you have one), then all child > > projects will inherit that value if they don't override it with > > their own groupId. > > > > In my case, this trick won't work, because each project needs a > > different value (with a standard naming convention). > > > > ..David.. > > > > -----Original Message----- > > From: Eric Redmond [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 15, 2005 9:32 PM > > To: Maven Users List > > Subject: Re: [m2] Wrapping an existing Mojo with a proxy Mojo > > > > I've actually had a similar issue. In my case, > > maven-archetype-plugin requires a groupId, although it will always > > be the same for our projects. > > I'd love to be able to specify the groupId by default for all cases. > > > > Eric > > > > On 11/15/05, David Jackman <[EMAIL PROTECTED]> wrote: > > > > > > I don't want to modify the existing plugins. I just want to run > > > the existing plugins as-is in a special way (e.g. with a > > > standardized property value or after some pre-processing has > > > occurred). However, the "standard property values" I'd like to > > > give the plugins aren't the > > > > > same for every project, so I can't just put them into the parent POM. > > > For example, the standard tag name for a release is predictable, > > > but different for every version number. I'd like my plugin to take > > > the version number and generate the correct standard tag name for > > > that release. (And that's just one example of this sort of thing > > > that I'd like to do.) > > > > > > ..David.. > > > > > > -----Original Message----- > > > From: Brett Porter [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, November 15, 2005 5:01 PM > > > To: Maven Users List > > > Subject: Re: [m2] Wrapping an existing Mojo with a proxy Mojo > > > > > > We're planning a way to template configuration in Maven 2.1 which > > > sounds like a better solution to this. You can have a common > > > parent POM that specifies these values to some extent at the moment. > > > > > > I'd be concerned about modifying the existing plugins to change > > > the defaults or behaviour, however as someone unfamiliar with the > > > changes looking at the build will then get a surprise. > > > > > > - Brett > > > > > > On 11/16/05, David Jackman <[EMAIL PROTECTED]> wrote: > > > > Just wondering if anyone has done this successfully and can > > > > recommend some best practices. In an effort to make our build > > > > process around M2 > > > > > > > as automatic as possible with regards to our internal standards, > > > > I'd > > > > > > like to create some custom plugins that effectively wrap > > > > existing plugins for either or both of these purposes: > > > > > > > > * To provide configuration properties in a standard way (e.g. > > > > using our tag naming standard when doing releases) > > > > * To perform some action before or after calling into the > > > wrapped > > > > Mojo > > > > > > > > I would expect this sort of thing has come up before for others. > > > > How > > > > > > did you accomplish it? Is there a recommendation for doing this? > > > > > > > > ..David.. > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > --- To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > ------------------------------------------------------------------ > > > --- To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
