Let your Mojo's be Groovy baby!

Hi folks, I've just finished up the first draft of support to use Groovy for Maven plugin development, including Javadoc-based Mojo descriptor extraction. I have yet to update the site docs to cover the Mojo impl bits, but I will get to that soon. Until then you can peek at this integratio

Re: dependency:purge-local-repository and includes?

And how do I configure the groupId to be used? --jason On Apr 4, 2007, at 8:12 PM, Brian E. Fox wrote: Use resolutionFuzziness=groupId http://maven.apache.org/plugins/maven-dependency-plugin/purge-local- repo sitory-mojo.html -Original Message- From: Jason Dillon [mailto:[EMAIL PRO

RE: dependency:purge-local-repository and includes?

Use resolutionFuzziness=groupId http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repo sitory-mojo.html -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Wednesday, April 04, 2007 9:41 PM To: Maven Developers List Subject: dep

[jira] Subscription: Outstanding Repository Maintenance: Uploads

Issue Subscription Filter: Outstanding Repository Maintenance: Uploads (24 issues) Subscriber: mavendevlist Key Summary MAVENUPLOAD-1454Upload of rmock 2.0.0. Group already exists. http://jira.codehaus.org/browse/MAVENUPLOAD-1454 MAVENUPLOAD-1455java exchange connector

[jira] Subscription: Outstanding Repository Maintenance: Evangelism

Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (40 issues) Subscriber: mavendevlist Key Summary MEV-513 Invalid POM: aspectwerkz/aspectwerkz-core http://jira.codehaus.org/browse/MEV-513 MEV-511 org.apache.struts:struts2-tiles-plugin:2.0.6 con

dependency:purge-local-repository and includes?

Would it be possible to get the dependency:purge-local-repository to specify a set of groupId, groupId:artifactId's that will be clobbered, leaving all others alone? I'd like to add something like this to my integration test profile to nuke all of the org.codehaus.mojo.groovy.it:* bits, but

Re: Update JavaMojoDescriptorExtractor to make it more re-use friendly

Thanks for looking at this. Hopefully someone can validate and merge the changes (if you use svk2 then its a painless merge) :-) --jason On Apr 4, 2007, at 5:06 PM, Brian E. Fox wrote: I took a look at the patch (http://jira.codehaus.org/browse/MNG-2930) and applied it to a branch here: ht

RE: Update JavaMojoDescriptorExtractor to make it more re-use friendly

I took a look at the patch (http://jira.codehaus.org/browse/MNG-2930) and applied it to a branch here: https://svn.apache.org/repos/asf/maven/shared/branches/maven-plugin-tool s-java-MNG-2930/ Everything seems good to me, the tests pass and everything builds ok. I'd like someone more familiar wit

Re: [VOTE] Release jxr 2.1

+1 On 4 Apr 07, at 6:23 PM 4 Apr 07, Dennis Lundberg wrote: Ping... Dennis Lundberg wrote: Hi, I'd like to release jxr 2.1. For this release the maven-jxr library and the maven-jxr-plugin has been put together in svn, similar to what has been done with release and surefire. They will be r

Re: [discuss] add validate/initialize to site lifecycle

I'd imagine that you would use something like 'site#initialize', unless you wanted to use the default lifecycle, in which case you'd just use 'initialize'. Then, I'm not sure whether you'd get into . You'd probably have to, particularly if you assume that 'initialize' == 'default#initialize'. BTW

Re: [VOTE] Release jxr 2.1

+1 Emmanuel Dennis Lundberg a écrit : Ping... Dennis Lundberg wrote: Hi, I'd like to release jxr 2.1. For this release the maven-jxr library and the maven-jxr-plugin has been put together in svn, similar to what has been done with release and surefire. They will be released simultaneously

Re: [discuss] add validate/initialize to site lifecycle

How would you know a specific lifecycle then? Something like default#initialize, versus site#initialize? I'm also not against it, just curious if people were open to changing the command line. I kind of like that idea, actually. On 4/4/07, John Casey <[EMAIL PROTECTED]> wrote: In any case, you'

Re: [VOTE] Release jxr 2.1

Ping... Dennis Lundberg wrote: Hi, I'd like to release jxr 2.1. For this release the maven-jxr library and the maven-jxr-plugin has been put together in svn, similar to what has been done with release and surefire. They will be released simultaneously. I have also merged the issues in JIRA

RE: [discuss] add validate/initialize to site lifecycle

Yes it seems that no quick fix is available at this point. How do we track these things for inclusion in a future release? -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 6:09 PM To: Maven Developers List Subject: Re: [discuss] add validate/in

Re: [discuss] add validate/initialize to site lifecycle

In any case, you're talking about new functionality...wouldn't it be better to redesign the lifecycle subsystem somehow so phase names don't have to be globally unique? (I'm not saying that would be simple, but I'm guessing it would be less complex for the user.) -john On 4/4/07, Brian E. Fox <[

RE: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and maven-enforcer-rule-api 1.0-alpha-1

Odd things happen at 1am? ;-) -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Wednesday, April 04, 2007 5:29 PM To: Maven Developers List Subject: Re: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and maven-enforcer-rule-api 1.0-alpha-1

Re: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and maven-enforcer-rule-api 1.0-alpha-1

Just currious, why does your example use "myCustomRule" instead of "MyCustomRule", the latter being the standard case for class names? --jason On Apr 4, 2007, at 12:22 PM, Brian E. Fox wrote: Joakim, You can create a custom rule and get access to nearly anything a plugin could. You either

Re: Other scms...

Ryan Daum a écrit : When I committed maven-scm-provider-hg it passed all unit tests. cool. When you say latest code of maven-scm-api, this is what is in the trunk of the SVN repository? If I can get it to build and pass tests there, can it graduate to being submitted to the trunk? If so

Re: Other scms...

When I committed maven-scm-provider-hg it passed all unit tests. When you say latest code of maven-scm-api, this is what is in the trunk of the SVN repository? If I can get it to build and pass tests there, can it graduate to being submitted to the trunk? If so, what Maven release will it come

Re: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and maven-enforcer-rule-api 1.0-alpha-1

On 4/4/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: Only 1? I figured you'd be +1000 at least by now ;-) then +1 << 4 from me J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Update JavaMojoDescriptorExtractor to make it more re-use friendly

Hi folks, I've been looking into getting Mojo descriptor generation working for the groovy-maven-plugin for the past few days... and I've finally got something that is working well. I went through a few iterations, and finally came to the conclusion that it would be simplest to parse the *.

RE: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and maven-enforcer-rule-api 1.0-alpha-1

Joakim, You can create a custom rule and get access to nearly anything a plugin could. You either return peacefully or throw an exception when the rule fails, what occurs inside there is completely open. In theory, you could fail the rule if you don't like the username ;-) http://maven.apache.org

Re: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and maven-enforcer-rule-api 1.0-alpha-1

+1 btw, what is the scope of this plugin? Does it exist to only check the environment of the user before executing the build? Can it also perform some multi-module sanity checks, or is that out of scope? (I've wanted to add 2 multi-module convergence checks, on dependencies and parent references)

Re: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and maven-enforcer-rule-api 1.0-alpha-1

+1 On 4/4/07, John Casey <[EMAIL PROTECTED]> wrote: +1 On 4/3/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > Only 1? I figured you'd be +1000 at least by now ;-) > > -Original Message- > From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason > Dillon > Sent: Tuesday, April 03,

RE: [discuss] add validate/initialize to site lifecycle

I think this phase couldn't be invoked from the cli because obviously it wouldn't know which to pick. An alternative solution to all this would be to allow @phase to accept multiples and allow a single execution to be bound to multpile phases. Then we could bind to validate,pre-site. -Origin

Javadoc-Plugin - enhancement to support different JDK

Dear Maven committers, there is an issue in JIRA to make the Javadoc-Plugin support running Javadoc from a JDK other than the one in JAVA_HOME. This is necessary if you e.g. run your build with JDK 1.4, because it's the default JDK in an organization, and want to build some JDK 1.5 projects on th

MRM-212 - work in progress ?

Arnaud Heritiercommented on 11 march about commiting the patch for issue MRM-212 (checksum policy) Is there any work in progress about it ? Nico.

Re: [discuss] add validate/initialize to site lifecycle

How would this phase work, in a practical manner? If someone runs the phase, which lifecycle gets executed? Or are you proposing a phase that cannot be explicitly called... like some sort of phase interface? Eric On 4/4/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: Right, so we're looking at a 2

RE: [discuss] add validate/initialize to site lifecycle

Right, so we're looking at a 2.1+ thing here. Adding them but changing the name defeats the whole purpose. Thanks for the info. -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 10:21 AM To: Maven Developers List Subject: Re: [discuss] add vali

Re: [discuss] add validate/initialize to site lifecycle

Max is right, if you add these phases to the site lifecycle (fine by me, I suppose), they'll have to have different names. This is really unfortunate, but that's the only way they can be incorporated into 2.0.x, or 2.1 (without some redesign). -john On 4/4/07, Max Bowsher <[EMAIL PROTECTED]> wro

Re: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and maven-enforcer-rule-api 1.0-alpha-1

+1 On 4/3/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: Only 1? I figured you'd be +1000 at least by now ;-) -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Tuesday, April 03, 2007 11:13 PM To: Maven Developers List Subject: Re: [VOTE] rele

Re: [VOTE] Release maven-skins pom 3

+1 On 4/4/07, Andrew Williams <[EMAIL PROTECTED]> wrote: +1 On 3 Apr 2007, at 21:36, Dennis Lundberg wrote: > Hi, > > I'd like to release maven-skins pom 3. > > This is in preparation of a patch release of maven-stylus-skin. > Since it is not possible to use the release-plugin to release a >

Re: [Vote] Move plugin site.xml up to Maven or Shared

+1 for moving to the Maven POM -john On 4/4/07, Andrew Williams <[EMAIL PROTECTED]> wrote: [X] Move to Maven Pom, with the note that extra site.xmls might be nice for breadcrumbs and extra links etc. Andy On 3 Apr 2007, at 03:39, Brian E. Fox wrote: > Currently only plugins get a nice looki

Re: [vote][m1] release modello plugin 1.0

+1 Thanks, john On 3/28/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: ping PMCs Thx Arnaud On 26/03/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > > Hi, > > I think that it is the time to release the modello plugin for maven 1.xin version > 1.0. > This plugin allows to use modello (

Re: [discuss] add validate/initialize to site lifecycle

Brian E. Fox wrote: > As Jerome pointed out earlier today on the enforcer thread, it would be > nice to be able to bind some plugins like the enforcer to a phase that > affects both default and site. After all, if you don't want to support > some Maven/Jdk/Os/other version, chances are that applies

Re: dojo.js breaks my archetype !!

Hi Nicolas, IIRC, there is a filtered attribute you can use in a resource (don't work with a source) Hope this helps and works Raphaël 2007/4/4, nicolas de loof <[EMAIL PROTECTED]>: dojo.js has the #include string in a comment. This makes my custom webapp archetype fail [ERROR] Parser Excep

dojo.js breaks my archetype !!

dojo.js has the #include string in a comment. This makes my custom webapp archetype fail [ERROR] Parser Exception: archetype-resources/webapp/src/main/webapp/scripts/dojo-0.4.2/dojo.js.uncompressed.js : org.ap ache.velocity.runtime.parser.ParseException: Encountered "command" at line 806, column

Re: [VOTE] Release maven-skins pom 3

+1 On 3 Apr 2007, at 21:36, Dennis Lundberg wrote: Hi, I'd like to release maven-skins pom 3. This is in preparation of a patch release of maven-stylus-skin. Since it is not possible to use the release-plugin to release a parent pom like this one, I'm offering you a diff between the last

Re: [Vote] Move plugin site.xml up to Maven or Shared

[X] Move to Maven Pom, with the note that extra site.xmls might be nice for breadcrumbs and extra links etc. Andy On 3 Apr 2007, at 03:39, Brian E. Fox wrote: Currently only plugins get a nice looking skin that matches the main maven.apache.org page because the site.xml exists in the plugin

Re: dependency:analyze needs target/ ?

On Apr 4, 2007, at 2:06 AM, Mark Hobson wrote: On 04/04/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Hey, I was using 2.0-alpha-3 before, but after changing to 2.0- alpha-4 I still get similar problems. Not every module that isn't type "pom" creates a target directory. The plugin should really

Re: dependency:analyze needs target/ ?

On 04/04/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Hey, I was using 2.0-alpha-3 before, but after changing to 2.0- alpha-4 I still get similar problems. Not every module that isn't type "pom" creates a target directory. The plugin should really skip any scanning of stuff under target if that

Re: dependency:analyze needs target/ ?

On Apr 4, 2007, at 1:34 AM, Mark Hobson wrote: On 04/04/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Why does dependency:analyze need target dirs? This barfs all over the place for modules of type pom... making this goal unusable. It requires target dirs because it processes the class files.

Re: dependency:analyze needs target/ ?

On 04/04/07, Jason Dillon <[EMAIL PROTECTED]> wrote: Why does dependency:analyze need target dirs? This barfs all over the place for modules of type pom... making this goal unusable. It requires target dirs because it processes the class files. Your problem looks like MDEP-73, try maven-depen

Re: [VOTE] Release maven-skins pom 3

+1 Emmanuel Dennis Lundberg a écrit : Hi, I'd like to release maven-skins pom 3. This is in preparation of a patch release of maven-stylus-skin. Since it is not possible to use the release-plugin to release a parent pom like this one, I'm offering you a diff between the last release and the

Re: PVCS integration

We have an issue in jira about it (SCM-34) with an implementation, but before to go in svn, I want someone clean the code that contain cvs provider code too and we need tests too. Emmanuel Tim Reilly a écrit : Can anyone tell me what the state of PVCS integration is. I recall some discussions

Re: [VOTE] Release maven-skins pom 3

+1 :) Dennis Lundberg wrote: Hi, I'd like to release maven-skins pom 3. This is in preparation of a patch release of maven-stylus-skin. Since it is not possible to use the release-plugin to release a parent pom like this one, I'm offering you a diff between the last release and the proposed