Introducing the configurability in the descriptor itself requires more
changes to the assembly code than I think we should tackle right now. I also
think we should strive to build a descriptor that works for all projects to
the extent possible. That said, I'll make a property in the plugin config t
After talking at length to Brian and Jason about this, it became obvious
that injecting this logic into the build process at some arbitrary point
in the lifecycle would probably only increase confusion, since binding a
given plugin before that point would produce different results than
binding
Hi,
We solved 14 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533&styleName=Html&version=14199
There are still several issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11533&status=1
Staging repo:
https://repository.apache.org/conte
2009/5/20 Paul Gier :
> This change [1] breaks the site generation for a lot of projects.
> Specifically, the checkstyle plugin config in the maven parent pom depends
> on the file maven_checks.xml in trunk of the checkstyle plugin. This should
> probably be changed in the parent pom to point to
This change [1] breaks the site generation for a lot of projects. Specifically,
the checkstyle plugin config in the maven parent pom depends on the file
maven_checks.xml in trunk of the checkstyle plugin. This should probably be
changed in the parent pom to point to a more stable location. It
I like the idea to have a new plugin normalize the POM before it gets
installed / deployed
This could be used also to translate the project POM from another XML schema
version / alternative language (groovy, json, or whatever) to 4.0.0
retro-compatible POM before beeing made public. This is not the
