Re: What will replace the @aggregator MOJO configuration?

being able to bind to the front and back of a lifecycle would be absolutely splendid Brian E Fox wrote: > > Yes it's binding the aggregator with @execute to a lifecycle that is the > problem. There's nothing wrong with aggregators that are meant to perform > some action from the CLI. The troubl

Plugin dependencies and suspected cyclic references

Dear devs, I would like confirmation that what I am doing is wrong, stupid and foolish and potentially should be detected and prevented by mvn. I have a corp pom that binds checkstyle and pmd to validate phase. Both these plugins have an extra config jar artifact added as a plugin dependency tha

Re: Comments / Ideas for MNG-3244

Don't forget what I learnt from Lukas Theussl regarding DOXIASITETOOLS-9, specifically the fact that URLs *should* have trailing slashes when referring to a 'directory':- lukas theussl wrote: > > > This behavior is correct according to the rfc specs: > http://www.ietf.org/rfc/rfc2396.txt (se

Re: Removing plugins from a lifecycle, programmatically or otherwise

dig, no one? jallen wrote: > > Dear all, > > The existing clover plugin forks off its own lifecycle so it can run its > instrumentInternal mojo in a new lifecycle and so it can try and prevent > any test failures from breaking the forked build: >

Removing plugins from a lifecycle, programmatically or otherwise

Dear all, The existing clover plugin forks off its own lifecycle so it can run its instrumentInternal mojo in a new lifecycle and so it can try and prevent any test failures from breaking the forked build: clover validate

Re: Atlassian to bring Maven Clover plugin development in-house

retired is good for me too. So now i can pester the Cenqua guys about features for both the Eclipse plugin AND the maven plugin. wonderful ;) John Allen Jochen Wiedmann wrote: > > On 8/30/07, Brett Porter <[EMAIL PROTECTED]> wrote: > >> Yeah, we should do the same with the recently departed a

Running reactor builds with MavenProjectStub?

It's been a while since i coded up some worth while Junit Mojo tests but after reading the wiki pages and mucking about with the maven-javadoc-plugin/src/test/java source I'm all excited over what I can now do without having to go the fork an external maven instance to test my plugins. However, d

MRELEASE-261 - review from dev's

Those in the know re the release manager and plugin: Could i get a quick peer review of the solution proposed in http://jira.codehaus.org/browse/MRELEASE-261 to confirm I havent missed anything fundamental before I go try and implement with my release-3 based manager and plugin? Thanks! John

Re: Publishing plugin docs

Found original JIRA ticket http://jira.codehaus.org/browse/MNG-2679 John jallen wrote: > > > -snip- > > So here's another appeal from me, please consider an artifact's site part > of its state and thus unique in terms of group, artifact and version by > defau

Re: Publishing plugin docs

(Sorry if this results in a re-send, dodgy connection) I have contributed to a number of threads in the past regarding the fact that maven site's are just another set of meta-data or, if you will, a view upon an artifact and therefore the site for a specific version of an artifact must remain val

2.0.6: Install fails but compile works. 2.0.5: Install works, compile works:

Weird, With 2.0.6 my multi-module simple J2EE app fails in the compile phase of my servlets child module during an install run of the reactor. However, it all builds if the reactor build is simply ‘compile’. Also, If I cd into the servlets module after the failed install build and just run insta

Re: Remove auto-resolution of plugin versions from Maven 2.1

I couldnt agree more with the sentiments that code in *all its guises* must be explcitly managed. you don't compile arbitrary code, don't use arbitrary compilers, don't link against arbitrary libraries... arbitrary bad. Build scripts are code, christ even my shell is a dependency to be managed (mi

RE: Remove auto-resolution of plugin versions from Maven 2.1

This pretty much describes our world too. And I couldnt agree more with the sentiments that code in *all its guises* must be explcitly managed. you don't compile arbitrary code, don't use arbitrary compilers, don't link against arbitrary libraries... arbitrary bad. Build scripts are code, christ

Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1

+1 John Casey wrote: > > So maybe we should publish far and wide the best practice of pegging the > plugin version, and require it in 2.1...then write a plugin to list the > available versions for a plugin, so users can check periodically. That > would > make life a little easier for users. >

Re: Maven central reporting API

Arnaud Bailly-3 wrote: > > Hi, > A couple of weeks ago I posted a proposal about a centralized > reporting feature for maven that would allow easy aggregation of > information at whatever level is needed. This proposal is centered > around the idea of creating and maintaining a RDF database that