Re: How to extend the release phases of the DefaultReleaseManager?
Thanks for help Stephen.
I implemented a prototype which follows the approach to override the default
release manager:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.3.2/version
dependencies
dependency
groupIdorg.sourcepit.b2/groupId
artifactIdb2-release-manager/artifactId
version0.1.0-SNAPSHOT/version
/dependency
/dependencies
/plugin
Actually, I'm just overrideing the default plexus component configuration to
add some additional release phases to the release preparation lifecycle. The
additional phases are responsible to adjust the OSGi manifest files. Works
great!
Another problem was the commit phase. Therefore that the pom.xml file are
generated by b2, I don't want to check them into the SCM. The solution was to
override/replace the ScmCommitPreparationPhase with another one that commits
the modified manifest files instead of the maven pom files.
So in summary the following features would have made my day:
* Customizeable release lifecycle (add/remove release phases)
* Hook to customize/set the set of files that should be commited
Nevertheless, the release plugin is a realy nice pice of code :)
Kind regards,
Bernd
-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Gesendet: Dienstag, 26. Juni 2012 12:00
An: Maven Developers List
Betreff: Re: How to extend the release phases of the DefaultReleaseManager?
of course you could just do
mvn b2:prep-release release:prepare release:perform
and have your plugin do the dancing games... but IIRC the pom checks
take place on the loaded MavenProject and not on the on-disk pom
On 26 June 2012 10:58, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Ahh, yes... I remember now, I had some theoretical use cases for a
transformationGoals (or prePreparationGoals) but no concrete use
cases... until now.
I think you just about have a valid use case for extending the
lifecycle to have an optional set of goals which runs between updating
the pom versions and before checking for snapshot dependencies and
running the preparationGoals...
The reason why I did not implement this is that at the time I did not
have a concrete use case, and IIRC, more importantly I think the code
does the pom validation BEFORE updating the pom with the new versions.
for transformationGoals to be of any real utility, I think it needs to
take place before the validation... and after the SCM check... which
may involve splitting out the validation code.
On 26 June 2012 10:17, bernd.v...@bosch-si.com wrote:
Actually, I'm not sure...
I have a very special use case, let me try to explain it:
* We implemented a maven core extension (see ${maven.home}/lib/ext/),
called b2.
* b2 is able to generate pom.xml files from plain eclipse plugin projects
with all the necessary
configuration to build it with Maven/Tycho
* Works well for snapshot builds
* For release builds we have to adjust the eclipse plugins versions
(specified in the OSGi
MANIFEST.MF) manually, whitch prevents the usage of the maven release plugin
So, my idea is to add a prepare phase to the release manager that adjusts
these version numbers
like the RewritePomsForReleasePhase does for poms.
I'm glad for each proposal :)
-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Gesendet: Dienstag, 26. Juni 2012 10:48
An: Maven Developers List
Betreff: Re: How to extend the release phases of the
DefaultReleaseManager?
95% of use cases that I have seen can be reached by using
preparationGoals to invoke an additional plugin or mix in an
additional profile
99.9% of use cases that I have seen can be reached by using
preparationGoals and completionGoals to tidy up afterwards.
Of the remaining 0.1% of use cases that I have seen, they should not
be doing it that way!
Are you sure you need an additional prepare phase?
On 26 June 2012 09:24, bernd.v...@bosch-si.com wrote:
Hi,
is there a way to extend the release phases of the
DefaultReleaseManager?
I'd like to add a custom release phase to the list of the release
managers prepare phases. The
implementation of the custom phase should update some project specific
files during the release
preparation.
Kind regards,
Bernd
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
plugin annotations retention policy
Hello, I'm in the process of rewriting the nbm-maven-plugin at mojo to use the new annotations instead of javadoc tags. It appears to be working fine, but I'm wondering why the retention policy is CLASS. Since it's only used to generate the xml file, it could be turned into SOURCE and the annotation dependency could be made provided. Am I missing something? Regards Milos Kleint - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: plugin annotations retention policy
Hi, We use asm to collect annotations from compiled classes (so scope compile ) Makes sense ? 2012/6/28 Milos Kleint mkle...@gmail.com: Hello, I'm in the process of rewriting the nbm-maven-plugin at mojo to use the new annotations instead of javadoc tags. It appears to be working fine, but I'm wondering why the retention policy is CLASS. Since it's only used to generate the xml file, it could be turned into SOURCE and the annotation dependency could be made provided. Am I missing something? Regards Milos Kleint - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: plugin annotations retention policy
why not use jdk's own annotation processors (which get compiled by javac are we save ourselves an extra mojo execution)? Milos On Thu, Jun 28, 2012 at 11:50 AM, Olivier Lamy ol...@apache.org wrote: Hi, We use asm to collect annotations from compiled classes (so scope compile ) Makes sense ? 2012/6/28 Milos Kleint mkle...@gmail.com: Hello, I'm in the process of rewriting the nbm-maven-plugin at mojo to use the new annotations instead of javadoc tags. It appears to be working fine, but I'm wondering why the retention policy is CLASS. Since it's only used to generate the xml file, it could be turned into SOURCE and the annotation dependency could be made provided. Am I missing something? Regards Milos Kleint - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: plugin annotations retention policy
could be better maybe. But means 1.6 required. Do you want to work on a branch with this change ? 2012/6/28 Milos Kleint mkle...@gmail.com: why not use jdk's own annotation processors (which get compiled by javac are we save ourselves an extra mojo execution)? Milos On Thu, Jun 28, 2012 at 11:50 AM, Olivier Lamy ol...@apache.org wrote: Hi, We use asm to collect annotations from compiled classes (so scope compile ) Makes sense ? 2012/6/28 Milos Kleint mkle...@gmail.com: Hello, I'm in the process of rewriting the nbm-maven-plugin at mojo to use the new annotations instead of javadoc tags. It appears to be working fine, but I'm wondering why the retention policy is CLASS. Since it's only used to generate the xml file, it could be turned into SOURCE and the annotation dependency could be made provided. Am I missing something? Regards Milos Kleint - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: plugin annotations retention policy
What about inheritance? Other tools that may want to do something with the annotations? -- Regards, Igor On 12-06-28 6:06 AM, Olivier Lamy wrote: could be better maybe. But means 1.6 required. Do you want to work on a branch with this change ? 2012/6/28 Milos Kleint mkle...@gmail.com: why not use jdk's own annotation processors (which get compiled by javac are we save ourselves an extra mojo execution)? Milos On Thu, Jun 28, 2012 at 11:50 AM, Olivier Lamy ol...@apache.org wrote: Hi, We use asm to collect annotations from compiled classes (so scope compile ) Makes sense ? 2012/6/28 Milos Kleint mkle...@gmail.com: Hello, I'm in the process of rewriting the nbm-maven-plugin at mojo to use the new annotations instead of javadoc tags. It appears to be working fine, but I'm wondering why the retention policy is CLASS. Since it's only used to generate the xml file, it could be turned into SOURCE and the annotation dependency could be made provided. Am I missing something? Regards Milos Kleint - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: plugin annotations retention policy
On 28 June 2012 11:33, Igor Fedorenko i...@ifedorenko.com wrote: What about inheritance? +1000 inheritance is one of the reasons we moved to annotations from javadoc tags (though I agree that plugin.xml merging could solve that somewhat, it's messy and ties us back rather than forward Other tools that may want to do something with the annotations? -- Regards, Igor On 12-06-28 6:06 AM, Olivier Lamy wrote: could be better maybe. But means 1.6 required. Do you want to work on a branch with this change ? 2012/6/28 Milos Kleint mkle...@gmail.com: why not use jdk's own annotation processors (which get compiled by javac are we save ourselves an extra mojo execution)? Milos On Thu, Jun 28, 2012 at 11:50 AM, Olivier Lamy ol...@apache.org wrote: Hi, We use asm to collect annotations from compiled classes (so scope compile ) Makes sense ? 2012/6/28 Milos Kleint mkle...@gmail.com: Hello, I'm in the process of rewriting the nbm-maven-plugin at mojo to use the new annotations instead of javadoc tags. It appears to be working fine, but I'm wondering why the retention policy is CLASS. Since it's only used to generate the xml file, it could be turned into SOURCE and the annotation dependency could be made provided. Am I missing something? Regards Milos Kleint - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-surefire pull request: SUREFIRE-879 maven-surefire-report-plugin fail...
Github user anistor closed the pull request at: https://github.com/apache/maven-surefire/pull/5 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: plugin annotations retention policy
Oh yes good point I missed that. I essentially work on the anno mode to be able to inherits annotations from reactors modules and/or dependencies. 2012/6/28 Igor Fedorenko i...@ifedorenko.com: What about inheritance? Other tools that may want to do something with the annotations? -- Regards, Igor On 12-06-28 6:06 AM, Olivier Lamy wrote: could be better maybe. But means 1.6 required. Do you want to work on a branch with this change ? 2012/6/28 Milos Kleint mkle...@gmail.com: why not use jdk's own annotation processors (which get compiled by javac are we save ourselves an extra mojo execution)? Milos On Thu, Jun 28, 2012 at 11:50 AM, Olivier Lamy ol...@apache.org wrote: Hi, We use asm to collect annotations from compiled classes (so scope compile ) Makes sense ? 2012/6/28 Milos Kleint mkle...@gmail.com: Hello, I'm in the process of rewriting the nbm-maven-plugin at mojo to use the new annotations instead of javadoc tags. It appears to be working fine, but I'm wondering why the retention policy is CLASS. Since it's only used to generate the xml file, it could be turned into SOURCE and the annotation dependency could be made provided. Am I missing something? Regards Milos Kleint - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Tips to build maven-plugin-tools
Hi,
Yes please create an issue.
Which os are you using ?
Currently jenkins build are ok. I will add one with jdk1.7
2012/6/28 Tony Chemit che...@codelutin.com:
Hy,
I try to build the project from the root maven project but I faced some
compilation problems :
in maven-plugin-tools-javadoc
-
The profile toobtain tools.jar is not activate (so so xdoc and build failed),
this profile is activated by property java.vendor :
valueSun Microsystems Inc./value
But I use a jdk 7 from oracle so I had to change it to Oracle Corporation
Is this normal ? Perharps I need a jdk 1.4.2to build the project, but it
sound a bit not possible since we used then
annotations in others modules so require a jdk 5.0 ?
If not should I open a jira issue for this ?
A simple solution is to add a second profile activated by Oracle Corporation
(or perharps also openJdk vendor ?)
in maven-plugin-plugin
--
As the project use itself now annotation to describe fields and components,
it must have this compile dependency:
dependency
groupIdorg.apache.maven.plugin-tools/groupId
artifactIdmaven-plugin-annotations/artifactId
version${project.version}/version
/dependency
Perharps there is some reason to this, but I can't find it out why (no
READEME file to help).
Thanks for responses, I am ready if required to open jira issues and submit
some patches.
kind regards,
tony.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-shade-plugin 1.7.1
+1 2012/6/27 Benson Margulies bimargul...@gmail.com: Hi, We solved 1 issues: ** Bug * [MSHADE-123] - 1.7 Causes failures in other plugins make basedir point to the build dir There are still plenty of issues left in JIRA. Staging repo: https://repository.apache.org/content/repositories/maven-282/ https://repository.apache.org/content/repositories/maven-282/maven-shade-plugin-1.7.1-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-shade-plugin 1.7.1
+1 Dan On Wednesday, June 27, 2012 07:53:44 AM Benson Margulies wrote: Hi, We solved 1 issues: ** Bug * [MSHADE-123] - 1.7 Causes failures in other plugins make basedir point to the build dir There are still plenty of issues left in JIRA. Staging repo: https://repository.apache.org/content/repositories/maven-282/ https://repository.apache.org/content/repositories/maven-282/maven-shade-p lugin-1.7.1-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-shade-plugin 1.7.1
+1 Hervé Le mercredi 27 juin 2012 07:53:44 Benson Margulies a écrit : Hi, We solved 1 issues: ** Bug * [MSHADE-123] - 1.7 Causes failures in other plugins make basedir point to the build dir There are still plenty of issues left in JIRA. Staging repo: https://repository.apache.org/content/repositories/maven-282/ https://repository.apache.org/content/repositories/maven-282/maven-shade-plu gin-1.7.1-source-release.zip Staging site: http://maven.apache.org/plugins/maven-shade-plugin-1.7.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
