You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Fabrizio Giustina <fg...@apache.org> on 2006/12/16 20:59:57 UTC
[vote] release maven-eclipse-plugin 2.3 (second try)
Dependencies used by the maven-eclipse-plugin have been released and a
stable revision for a vote has been set.
I'd like to restart a vote based on:
- svn rev. 487861
- snapshot deployed at
http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-eclipse-plugin/2.3-SNAPSHOT/maven-eclipse-plugin-2.3-20061216.195001-12.jar
- documentation already updated at
http://maven.apache.org/plugins/maven-eclipse-plugin/
- changelog available at
http://jira.codehaus.org/browse/MECLIPSE?report=com.atlassian.jira.plugin.system.project:roadmap-panel
this release contains several bugfixes and new features, especially
related to eclipse plugin development. Lots of issues/enhancement
requests are still open, but users need a release before going on.
Vote is open for 72h
My +1,
Fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] release maven-eclipse-plugin 2.3 (second try)
Posted by John Casey <ca...@gmail.com>.
+1
On 12/16/06, Fabrizio Giustina <fg...@apache.org> wrote:
>
> Dependencies used by the maven-eclipse-plugin have been released and a
> stable revision for a vote has been set.
>
> I'd like to restart a vote based on:
> - svn rev. 487861
> - snapshot deployed at
>
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-eclipse-plugin/2.3-SNAPSHOT/maven-eclipse-plugin-2.3-20061216.195001-12.jar
> - documentation already updated at
> http://maven.apache.org/plugins/maven-eclipse-plugin/
> - changelog available at
>
> http://jira.codehaus.org/browse/MECLIPSE?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>
> this release contains several bugfixes and new features, especially
> related to eclipse plugin development. Lots of issues/enhancement
> requests are still open, but users need a release before going on.
>
>
> Vote is open for 72h
>
> My +1,
> Fabrizio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote] release maven-eclipse-plugin 2.3 (second try)
Posted by Jason van Zyl <ja...@maven.org>.
+1
On 16 Dec 06, at 2:59 PM 16 Dec 06, Fabrizio Giustina wrote:
> Dependencies used by the maven-eclipse-plugin have been released and a
> stable revision for a vote has been set.
>
> I'd like to restart a vote based on:
> - svn rev. 487861
> - snapshot deployed at
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> maven/plugins/maven-eclipse-plugin/2.3-SNAPSHOT/maven-eclipse-
> plugin-2.3-20061216.195001-12.jar
> - documentation already updated at
> http://maven.apache.org/plugins/maven-eclipse-plugin/
> - changelog available at
> http://jira.codehaus.org/browse/MECLIPSE?
> report=com.atlassian.jira.plugin.system.project:roadmap-panel
>
> this release contains several bugfixes and new features, especially
> related to eclipse plugin development. Lots of issues/enhancement
> requests are still open, but users need a release before going on.
>
>
> Vote is open for 72h
>
> My +1,
> Fabrizio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by John Casey <ca...@gmail.com>.
OK, what I found was this:
1. the reason the eclipse plugin had this problem was that it was running
these test builds (including staging the plugin) during the unit-test phase,
before the plugin was packaged or the plugin-jar assigned to the project
artifact. Technically, this use case should be possible, though I'd
reiterate that test builds really belong in an integration-test phase.
2. the plugin-staging process was indeed wreaking havoc with the metadata,
etc. in the target directory; I remedied this by copying the plugin project
directory to a temporary location, and staged the plugin by building it from
there. This avoids the problems with metadata/etc. in the target directory.
I've verified that this is working in another plugin I'm working on at
present. It should also work for the eclipse plugin.
-john
On 12/20/06, John Casey <ca...@gmail.com> wrote:
>
> Hmm, that won't quite work, though, since it'll kill the test local
> repo...I'll work on it some more.
>
> -john
>
> On 12/20/06, John Casey < casey.john.d@gmail.com> wrote:
> >
> > Ah, right, ok...forgot about that point.
> >
> > I've added code to run a 'clean' build after the plugin is staged.
> >
> > On 12/20/06, Barrie Treloar <ba...@gmail.com> wrote:
> > >
> > > I've listed the problems in the JIRA entry and started a new thread
> > > for this discussion.
> > >
> > > The problem is that the ProjectTools end up invoking another maven
> > > with mangled information and that this causes target/classes to have a
> > > junk plugin.xml which is then used in the jar phase.
> > >
> > > On 12/21/06, John Casey <ca...@gmail.com> wrote:
> > > > are you sure it wasn't just a case of the IT-staging process somehow
> > > hitting
> > > > the deploy phase of the build? That would've done it.
> > > >
> > > > The ITs currently use the maven-invoker, which forks an entirely new
> > > Maven
> > > > process, both for building the test version of the plugin, and for
> > > running
> > > > each test build. So memory pollution isn't really an option. I
> > > suppose it's
> > > > possible that it's picking up the wrong jar from /target, but the
> > > deployment
> > > > process discards that filename anyway...
> > > >
> > > > I'll mod the code to delete that plugin jar from the target dir when
> > > it's
> > > > finished...
> > > >
> > > > -john
> > > >
> > > > On 12/20/06, Barrie Treloar <baerrach@gmail.com > wrote:
> > > > >
> > > > > > not sure what went wrong, but look at these:
> > > > > > http://www.nabble.com/Maven-eclipse-plugin-error-tf2692962.html#a7509615
> > >
> > > > > > http://jira.codehaus.org/browse/MECLIPSE-192
> > > > >
> > > > > I'm still investigating why this occurs.
> > > > >
> > > > > I think it is either the stuff in maven-plugin-testing-tools is
> > > > > mangling something it shouldn't or jar:jar is picking up the wrong
> > >
> > > > > information from somewhere.
> > > > >
> > > > > I'm still trying to work out where the code is for writing
> > > > > META-INF/maven/plugin.xml which should help resolve why the
> > > version is
> > > > > incorrectly set to test.
> > > > >
> > > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by John Casey <ca...@gmail.com>.
FWIW, I just added code to the maven-plugin-testing-tools that will override
the distributionManagement section in the test POM, making deployment of the
plugin using the altered version impossible.
On 12/20/06, John Casey <ca...@gmail.com> wrote:
>
> There are two things you need to test, right?
>
> 1. unit test functionality within the plugin, to make sure that
> subcomponents and classes within the implementation are functioning
> correctly
>
> 2. integration test functionality that depends on Maven (the runtime
> context) to produce results. This is what most of these tests currently do,
> in one way or other.
>
> I agree that we need to have a formalized integration-testing phase where
> the plugin can run in its container (maven), and output can be verified.
> This will involve allowing Maven to read the plugin from somewhere, which
> means it has to be packaged and installed somewhere...without polluting the
> main local repository. When I ran the tests after working on a couple of
> jiras, they would not pass without me first running 'mvn -
> Dmaven.test.skip=true install' and then trying...this to me means that
> it's polluting the local repository with an untested plugin.
>
> If you really think you can ensure that the local repository isn't
> polluted, and can make the build complete with tests executed in a single
> pass, then it should be pretty easy to revert the tests back to use the
> embedder or whatever...simply change the method in the abstract test case
> that actually runs the maven build, and that will get you very close.
>
> Aside from that discussion, it's also possible to run the integration
> tests using the real version of the plugin, though that seems much more
> fragile to me. In this case, you'd be reliant on the metadata to be
> installed in the testing local repository and take precedence over the
> metadata in the remote repository. Then, there is no separate testing-only
> plugin version to be concerned with. What those issues say to me is that
> there's some place where an integration test is running the deploy
> step...and that the staging process for the plugin needs to remove the
> distributionManagement section, or otherwise nullify it so deployment is not
> possible. That's an easy fix in the maven-plugin-testing-tools.
>
> -john
>
> On 12/20/06, Fabrizio Giustina <fg...@apache.org> wrote:
> >
> > On 12/20/06, Kenney Westerhof <ke...@apache.org> wrote:
> > > There was support in maven to run plugins from target/, but it was
> > broken:
> > > MNG-2677 (originally MNG-870).
> >
> > well, the eclipse plugin was using that till a few weeks ago and I can
> > assure it was working!
> > I was able to modify the plugin code from eclipse, to set breakpoints
> > and to run junit tests from the IDE without having to rerun maven at
> > all (it was only needed when adding new parameters, since the plugin
> > descriptor had to be generated by maven).
> > As said, the only problem was the inability to run reactor builds: for
> > that reason the only test that was needing it was implemented using a
> > command line call and never enabled in the surefire configuration
> > (only run manually).
> >
> > I could be wrong, but if you try to get a revision before John's
> > refactoring it should work this way.
> > I see that the tests didn't do anything special:
> > https://svn.apache.org/viewvc/maven/plugins/tags/maven-eclipse-plugin-2.2/src/test/java/org/apache/maven/plugin/eclipse/AbstractEclipsePluginTestCase.java?revision=393014&view=markup
> >
> >
> > > But would indeed be best if plugin integration tests are done in the
> > integration-test
> > > phase, using the packaged plugin from target/ (which is available from
> > the reactor).
> >
> > well, I'd love to see plugin tests working without having to package a
> > plugin at all. It's a lot better if you are also able to run tests
> > from an IDE. I was pretty happy on how tests were done previously
> > apart from the multiproject stuff and a better control over the test
> > repository...
> >
> > fabrizio
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by John Casey <ca...@gmail.com>.
There are two things you need to test, right?
1. unit test functionality within the plugin, to make sure that
subcomponents and classes within the implementation are functioning
correctly
2. integration test functionality that depends on Maven (the runtime
context) to produce results. This is what most of these tests currently do,
in one way or other.
I agree that we need to have a formalized integration-testing phase where
the plugin can run in its container (maven), and output can be verified.
This will involve allowing Maven to read the plugin from somewhere, which
means it has to be packaged and installed somewhere...without polluting the
main local repository. When I ran the tests after working on a couple of
jiras, they would not pass without me first running 'mvn -
Dmaven.test.skip=true install' and then trying...this to me means that it's
polluting the local repository with an untested plugin.
If you really think you can ensure that the local repository isn't polluted,
and can make the build complete with tests executed in a single pass, then
it should be pretty easy to revert the tests back to use the embedder or
whatever...simply change the method in the abstract test case that actually
runs the maven build, and that will get you very close.
Aside from that discussion, it's also possible to run the integration tests
using the real version of the plugin, though that seems much more fragile to
me. In this case, you'd be reliant on the metadata to be installed in the
testing local repository and take precedence over the metadata in the remote
repository. Then, there is no separate testing-only plugin version to be
concerned with. What those issues say to me is that there's some place where
an integration test is running the deploy step...and that the staging
process for the plugin needs to remove the distributionManagement section,
or otherwise nullify it so deployment is not possible. That's an easy fix in
the maven-plugin-testing-tools.
-john
On 12/20/06, Fabrizio Giustina <fg...@apache.org> wrote:
>
> On 12/20/06, Kenney Westerhof <ke...@apache.org> wrote:
> > There was support in maven to run plugins from target/, but it was
> broken:
> > MNG-2677 (originally MNG-870).
>
> well, the eclipse plugin was using that till a few weeks ago and I can
> assure it was working!
> I was able to modify the plugin code from eclipse, to set breakpoints
> and to run junit tests from the IDE without having to rerun maven at
> all (it was only needed when adding new parameters, since the plugin
> descriptor had to be generated by maven).
> As said, the only problem was the inability to run reactor builds: for
> that reason the only test that was needing it was implemented using a
> command line call and never enabled in the surefire configuration
> (only run manually).
>
> I could be wrong, but if you try to get a revision before John's
> refactoring it should work this way.
> I see that the tests didn't do anything special:
>
> https://svn.apache.org/viewvc/maven/plugins/tags/maven-eclipse-plugin-2.2/src/test/java/org/apache/maven/plugin/eclipse/AbstractEclipsePluginTestCase.java?revision=393014&view=markup
>
> > But would indeed be best if plugin integration tests are done in the
> integration-test
> > phase, using the packaged plugin from target/ (which is available from
> the reactor).
>
> well, I'd love to see plugin tests working without having to package a
> plugin at all. It's a lot better if you are also able to run tests
> from an IDE. I was pretty happy on how tests were done previously
> apart from the multiproject stuff and a better control over the test
> repository...
>
> fabrizio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by Fabrizio Giustina <fg...@apache.org>.
On 12/20/06, Kenney Westerhof <ke...@apache.org> wrote:
> There was support in maven to run plugins from target/, but it was broken:
> MNG-2677 (originally MNG-870).
well, the eclipse plugin was using that till a few weeks ago and I can
assure it was working!
I was able to modify the plugin code from eclipse, to set breakpoints
and to run junit tests from the IDE without having to rerun maven at
all (it was only needed when adding new parameters, since the plugin
descriptor had to be generated by maven).
As said, the only problem was the inability to run reactor builds: for
that reason the only test that was needing it was implemented using a
command line call and never enabled in the surefire configuration
(only run manually).
I could be wrong, but if you try to get a revision before John's
refactoring it should work this way.
I see that the tests didn't do anything special:
https://svn.apache.org/viewvc/maven/plugins/tags/maven-eclipse-plugin-2.2/src/test/java/org/apache/maven/plugin/eclipse/AbstractEclipsePluginTestCase.java?revision=393014&view=markup
> But would indeed be best if plugin integration tests are done in the integration-test
> phase, using the packaged plugin from target/ (which is available from the reactor).
well, I'd love to see plugin tests working without having to package a
plugin at all. It's a lot better if you are also able to run tests
from an IDE. I was pretty happy on how tests were done previously
apart from the multiproject stuff and a better control over the test
repository...
fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by Kenney Westerhof <ke...@apache.org>.
Fabrizio Giustina wrote:
> Hi John,
>
> On 12/20/06, John Casey <ca...@gmail.com> wrote:
>> I switched to using a testing version of the plugin (which BTW is only
>> resolvable ever in the repo created during the integration testing
>> phase) so
>> the ITs themselves wouldn't have to:
>>
>> a. adjust to new plugin versions in order to run
>> b. rely on metadata resolution for the plugin version, which can lead to
>> using an incorrect version of the plugin
>
> The previous tests that were done using the embedded didn't had to
> specify a plugin version at all, and they just loaded the current
> version directly from the target folder without using the installed
> jar... isn't that better? I am wrong or there is actually support to
> run unpacked plugins in embedder?
There was support in maven to run plugins from target/, but it was broken:
MNG-2677 (originally MNG-870).
I don't think it's possible to have the target/ version of the plugin integration
tested at all right now, not unless you install it in a local repository first.
So the tests were most likely testing a previously installed plugin in the local repository.
> The only drawback was that the version of the embedder I was using
> didn't support multiproject builds, but this should be fixed in the
> refactoring by jason-not sure if it can be used in a plugin that
> depends on maven 2.0)
I never knew an embedder that didn't support multiproject builds.. weird.
But would indeed be best if plugin integration tests are done in the integration-test
phase, using the packaged plugin from target/ (which is available from the reactor).
-- Kenney
>
>
>> I guess I don't understand why everyone's nervous about this?
>
> not sure what went wrong, but look at these:
> http://www.nabble.com/Maven-eclipse-plugin-error-tf2692962.html#a7509615
> http://jira.codehaus.org/browse/MECLIPSE-192
>
> (and btw, I also had problem in running the eclipse plugin on my
> enviroment after running tests once... looks like the -test version is
> not really circumvented to the test repo)
>
> fabrizio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by John Casey <ca...@gmail.com>.
Hmm, that won't quite work, though, since it'll kill the test local
repo...I'll work on it some more.
-john
On 12/20/06, John Casey <ca...@gmail.com> wrote:
>
> Ah, right, ok...forgot about that point.
>
> I've added code to run a 'clean' build after the plugin is staged.
>
> On 12/20/06, Barrie Treloar <ba...@gmail.com> wrote:
> >
> > I've listed the problems in the JIRA entry and started a new thread
> > for this discussion.
> >
> > The problem is that the ProjectTools end up invoking another maven
> > with mangled information and that this causes target/classes to have a
> > junk plugin.xml which is then used in the jar phase.
> >
> > On 12/21/06, John Casey <ca...@gmail.com> wrote:
> > > are you sure it wasn't just a case of the IT-staging process somehow
> > hitting
> > > the deploy phase of the build? That would've done it.
> > >
> > > The ITs currently use the maven-invoker, which forks an entirely new
> > Maven
> > > process, both for building the test version of the plugin, and for
> > running
> > > each test build. So memory pollution isn't really an option. I suppose
> > it's
> > > possible that it's picking up the wrong jar from /target, but the
> > deployment
> > > process discards that filename anyway...
> > >
> > > I'll mod the code to delete that plugin jar from the target dir when
> > it's
> > > finished...
> > >
> > > -john
> > >
> > > On 12/20/06, Barrie Treloar <ba...@gmail.com> wrote:
> > > >
> > > > > not sure what went wrong, but look at these:
> > > > >
> > http://www.nabble.com/Maven-eclipse-plugin-error-tf2692962.html#a7509615
> > > > > http://jira.codehaus.org/browse/MECLIPSE-192
> > > >
> > > > I'm still investigating why this occurs.
> > > >
> > > > I think it is either the stuff in maven-plugin-testing-tools is
> > > > mangling something it shouldn't or jar:jar is picking up the wrong
> > > > information from somewhere.
> > > >
> > > > I'm still trying to work out where the code is for writing
> > > > META-INF/maven/plugin.xml which should help resolve why the version
> > is
> > > > incorrectly set to test.
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by John Casey <ca...@gmail.com>.
Ah, right, ok...forgot about that point.
I've added code to run a 'clean' build after the plugin is staged.
On 12/20/06, Barrie Treloar <ba...@gmail.com> wrote:
>
> I've listed the problems in the JIRA entry and started a new thread
> for this discussion.
>
> The problem is that the ProjectTools end up invoking another maven
> with mangled information and that this causes target/classes to have a
> junk plugin.xml which is then used in the jar phase.
>
> On 12/21/06, John Casey <ca...@gmail.com> wrote:
> > are you sure it wasn't just a case of the IT-staging process somehow
> hitting
> > the deploy phase of the build? That would've done it.
> >
> > The ITs currently use the maven-invoker, which forks an entirely new
> Maven
> > process, both for building the test version of the plugin, and for
> running
> > each test build. So memory pollution isn't really an option. I suppose
> it's
> > possible that it's picking up the wrong jar from /target, but the
> deployment
> > process discards that filename anyway...
> >
> > I'll mod the code to delete that plugin jar from the target dir when
> it's
> > finished...
> >
> > -john
> >
> > On 12/20/06, Barrie Treloar <ba...@gmail.com> wrote:
> > >
> > > > not sure what went wrong, but look at these:
> > > >
> http://www.nabble.com/Maven-eclipse-plugin-error-tf2692962.html#a7509615
> > > > http://jira.codehaus.org/browse/MECLIPSE-192
> > >
> > > I'm still investigating why this occurs.
> > >
> > > I think it is either the stuff in maven-plugin-testing-tools is
> > > mangling something it shouldn't or jar:jar is picking up the wrong
> > > information from somewhere.
> > >
> > > I'm still trying to work out where the code is for writing
> > > META-INF/maven/plugin.xml which should help resolve why the version is
> > > incorrectly set to test.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by Barrie Treloar <ba...@gmail.com>.
I've listed the problems in the JIRA entry and started a new thread
for this discussion.
The problem is that the ProjectTools end up invoking another maven
with mangled information and that this causes target/classes to have a
junk plugin.xml which is then used in the jar phase.
On 12/21/06, John Casey <ca...@gmail.com> wrote:
> are you sure it wasn't just a case of the IT-staging process somehow hitting
> the deploy phase of the build? That would've done it.
>
> The ITs currently use the maven-invoker, which forks an entirely new Maven
> process, both for building the test version of the plugin, and for running
> each test build. So memory pollution isn't really an option. I suppose it's
> possible that it's picking up the wrong jar from /target, but the deployment
> process discards that filename anyway...
>
> I'll mod the code to delete that plugin jar from the target dir when it's
> finished...
>
> -john
>
> On 12/20/06, Barrie Treloar <ba...@gmail.com> wrote:
> >
> > > not sure what went wrong, but look at these:
> > > http://www.nabble.com/Maven-eclipse-plugin-error-tf2692962.html#a7509615
> > > http://jira.codehaus.org/browse/MECLIPSE-192
> >
> > I'm still investigating why this occurs.
> >
> > I think it is either the stuff in maven-plugin-testing-tools is
> > mangling something it shouldn't or jar:jar is picking up the wrong
> > information from somewhere.
> >
> > I'm still trying to work out where the code is for writing
> > META-INF/maven/plugin.xml which should help resolve why the version is
> > incorrectly set to test.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by John Casey <ca...@gmail.com>.
are you sure it wasn't just a case of the IT-staging process somehow hitting
the deploy phase of the build? That would've done it.
The ITs currently use the maven-invoker, which forks an entirely new Maven
process, both for building the test version of the plugin, and for running
each test build. So memory pollution isn't really an option. I suppose it's
possible that it's picking up the wrong jar from /target, but the deployment
process discards that filename anyway...
I'll mod the code to delete that plugin jar from the target dir when it's
finished...
-john
On 12/20/06, Barrie Treloar <ba...@gmail.com> wrote:
>
> > not sure what went wrong, but look at these:
> > http://www.nabble.com/Maven-eclipse-plugin-error-tf2692962.html#a7509615
> > http://jira.codehaus.org/browse/MECLIPSE-192
>
> I'm still investigating why this occurs.
>
> I think it is either the stuff in maven-plugin-testing-tools is
> mangling something it shouldn't or jar:jar is picking up the wrong
> information from somewhere.
>
> I'm still trying to work out where the code is for writing
> META-INF/maven/plugin.xml which should help resolve why the version is
> incorrectly set to test.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by Barrie Treloar <ba...@gmail.com>.
> not sure what went wrong, but look at these:
> http://www.nabble.com/Maven-eclipse-plugin-error-tf2692962.html#a7509615
> http://jira.codehaus.org/browse/MECLIPSE-192
I'm still investigating why this occurs.
I think it is either the stuff in maven-plugin-testing-tools is
mangling something it shouldn't or jar:jar is picking up the wrong
information from somewhere.
I'm still trying to work out where the code is for writing
META-INF/maven/plugin.xml which should help resolve why the version is
incorrectly set to test.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by Fabrizio Giustina <fg...@apache.org>.
Hi John,
On 12/20/06, John Casey <ca...@gmail.com> wrote:
> I switched to using a testing version of the plugin (which BTW is only
> resolvable ever in the repo created during the integration testing phase) so
> the ITs themselves wouldn't have to:
>
> a. adjust to new plugin versions in order to run
> b. rely on metadata resolution for the plugin version, which can lead to
> using an incorrect version of the plugin
The previous tests that were done using the embedded didn't had to
specify a plugin version at all, and they just loaded the current
version directly from the target folder without using the installed
jar... isn't that better? I am wrong or there is actually support to
run unpacked plugins in embedder?
The only drawback was that the version of the embedder I was using
didn't support multiproject builds, but this should be fixed in the
refactoring by jason-not sure if it can be used in a plugin that
depends on maven 2.0)
> I guess I don't understand why everyone's nervous about this?
not sure what went wrong, but look at these:
http://www.nabble.com/Maven-eclipse-plugin-error-tf2692962.html#a7509615
http://jira.codehaus.org/browse/MECLIPSE-192
(and btw, I also had problem in running the eclipse plugin on my
enviroment after running tests once... looks like the -test version is
not really circumvented to the test repo)
fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by John Casey <ca...@gmail.com>.
I switched to using a testing version of the plugin (which BTW is only
resolvable ever in the repo created during the integration testing phase) so
the ITs themselves wouldn't have to:
a. adjust to new plugin versions in order to run
b. rely on metadata resolution for the plugin version, which can lead to
using an incorrect version of the plugin
This way, it is absolutely invariant which plugin version they will test.
The "testing" version doesn't exist anywhere else, and the modded POM that
is used to build the testing version is marked as deleteOnExit().
I guess I don't understand why everyone's nervous about this?
-john
On 12/20/06, Jason van Zyl <ja...@maven.org> wrote:
>
>
> On 20 Dec 06, at 6:32 AM 20 Dec 06, Fabrizio Giustina wrote:
>
> > The vote has ended, with 5 positive votes from PMC members. The maven
> > eclipse plugin will be released with version 2.3.
> >
> > Jason, I will leave the actual release to you as discussed, you can
> > now proceed.
> >
>
> Great I can take care of this.
>
> >
> > (about the way the plugin is tested: I totally agree that installing a
> > test version into the local repository is something that should be
> > absolutely avoided. Till recently plugin tests used the embedder, but
> > if I'm not wrong such tests have been refactored by John using this
> > "new way", probably to overcome the limitation that the embedder was
> > not able to run multiproject builds.
>
> The embedder runs multiple projects. At any rate, I've briefly talked
> with John and we will align everything to one set of tools and
> improve them.
>
> > This is not a problem for users
> > but I'll try to refactor again tests after this release.)
> >
> > fabrizio
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by Jason van Zyl <ja...@maven.org>.
On 20 Dec 06, at 6:32 AM 20 Dec 06, Fabrizio Giustina wrote:
> The vote has ended, with 5 positive votes from PMC members. The maven
> eclipse plugin will be released with version 2.3.
>
> Jason, I will leave the actual release to you as discussed, you can
> now proceed.
>
Great I can take care of this.
>
> (about the way the plugin is tested: I totally agree that installing a
> test version into the local repository is something that should be
> absolutely avoided. Till recently plugin tests used the embedder, but
> if I'm not wrong such tests have been refactored by John using this
> "new way", probably to overcome the limitation that the embedder was
> not able to run multiproject builds.
The embedder runs multiple projects. At any rate, I've briefly talked
with John and we will align everything to one set of tools and
improve them.
> This is not a problem for users
> but I'll try to refactor again tests after this release.)
>
> fabrizio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[vote result] release maven-eclipse-plugin 2.3 (second try)
Posted by Fabrizio Giustina <fg...@apache.org>.
The vote has ended, with 5 positive votes from PMC members. The maven
eclipse plugin will be released with version 2.3.
Jason, I will leave the actual release to you as discussed, you can now proceed.
(about the way the plugin is tested: I totally agree that installing a
test version into the local repository is something that should be
absolutely avoided. Till recently plugin tests used the embedder, but
if I'm not wrong such tests have been refactored by John using this
"new way", probably to overcome the limitation that the embedder was
not able to run multiproject builds. This is not a problem for users
but I'll try to refactor again tests after this release.)
fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] release maven-eclipse-plugin 2.3 (second try)
Posted by Jason van Zyl <ja...@maven.org>.
On 17 Dec 06, at 1:58 PM 17 Dec 06, Fabrizio Giustina wrote:
> On 12/17/06, Jason van Zyl <ja...@maven.org> wrote:
>> Fabrizio,
>>
>> When the release is ready to be made can I actually perform the
>> release?
>
> Sure, no problem for me. Btw I already used the new remote-resources
> and gpg stuff to deploy 4 releases in maven shared and everything
> worked well. The only note is that I actually ran the gpg:sign goal
> manually without including it into the pom, so that I was able to test
> it before committing a modified (released) pom. I also manually
> deleted the unnecessary sha and md5 for signatures.
>
> IMHO it should be better to include everything we use for releases
> (javadoc and sources generation, gpg signing) in the default build
> process, using everything also for snapshots: it may look overkilling
> to sign snapshots too but I think it's better to keep snapshot/release
> deploys as aligned as possible...
Absolutely, that's the plan. It's all in a profile now for testing.
> the deploy of snapshots also helps
> in testing that everything is ok, and for new developers could be a
> little bit scary to have something that you can properly only use for
> releases.
What I plan on doing for voting is an actual release to a staging
repository. If it's crap then we do it again, and when it's good we
merge the stage with the real repository. I'm am trying this for the
first time with a Geronimo release and I will do it with the maven-
eclipse-plugin as well.
>
> Another note about the eclipse plugin: at the moment the plugin
> installs a test version to the local repository during tests and I saw
> such version also deployed to the remote snapshot repo once. Please
> check that this doesn't happen when doing a release, I was planning to
> do a release:prepare and then deploy the release building it from the
> tag with tests disabled to be sure that it doesn't happen in the worst
> moment...
That's not good, that shouldn't be in tests. What is doing that
because that's really bad.
No real repository whether local or remote can be tampered with for
testing that is just an extremely bad practice.
Jason.
>
> fabrizio
>
>
>> I would like to keep testing the new tools and move toward
>> having the release be made by one machine. The more releases I can do
>> to test this the better. I will document everything (Joakim and I
>> have started) and then it should be no problem for anyone to do it
>> for future releases.
>>
>> jason.
>>
>> On 16 Dec 06, at 2:59 PM 16 Dec 06, Fabrizio Giustina wrote:
>>
>> > Dependencies used by the maven-eclipse-plugin have been released
>> and a
>> > stable revision for a vote has been set.
>> >
>> > I'd like to restart a vote based on:
>> > - svn rev. 487861
>> > - snapshot deployed at
>> > http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> > maven/plugins/maven-eclipse-plugin/2.3-SNAPSHOT/maven-eclipse-
>> > plugin-2.3-20061216.195001-12.jar
>> > - documentation already updated at
>> > http://maven.apache.org/plugins/maven-eclipse-plugin/
>> > - changelog available at
>> > http://jira.codehaus.org/browse/MECLIPSE?
>> > report=com.atlassian.jira.plugin.system.project:roadmap-panel
>> >
>> > this release contains several bugfixes and new features, especially
>> > related to eclipse plugin development. Lots of issues/enhancement
>> > requests are still open, but users need a release before going on.
>> >
>> >
>> > Vote is open for 72h
>> >
>> > My +1,
>> > Fabrizio
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] release maven-eclipse-plugin 2.3 (second try)
Posted by Fabrizio Giustina <fg...@apache.org>.
On 12/17/06, Jason van Zyl <ja...@maven.org> wrote:
> Fabrizio,
>
> When the release is ready to be made can I actually perform the
> release?
Sure, no problem for me. Btw I already used the new remote-resources
and gpg stuff to deploy 4 releases in maven shared and everything
worked well. The only note is that I actually ran the gpg:sign goal
manually without including it into the pom, so that I was able to test
it before committing a modified (released) pom. I also manually
deleted the unnecessary sha and md5 for signatures.
IMHO it should be better to include everything we use for releases
(javadoc and sources generation, gpg signing) in the default build
process, using everything also for snapshots: it may look overkilling
to sign snapshots too but I think it's better to keep snapshot/release
deploys as aligned as possible... the deploy of snapshots also helps
in testing that everything is ok, and for new developers could be a
little bit scary to have something that you can properly only use for
releases.
Another note about the eclipse plugin: at the moment the plugin
installs a test version to the local repository during tests and I saw
such version also deployed to the remote snapshot repo once. Please
check that this doesn't happen when doing a release, I was planning to
do a release:prepare and then deploy the release building it from the
tag with tests disabled to be sure that it doesn't happen in the worst
moment...
fabrizio
> I would like to keep testing the new tools and move toward
> having the release be made by one machine. The more releases I can do
> to test this the better. I will document everything (Joakim and I
> have started) and then it should be no problem for anyone to do it
> for future releases.
>
> jason.
>
> On 16 Dec 06, at 2:59 PM 16 Dec 06, Fabrizio Giustina wrote:
>
> > Dependencies used by the maven-eclipse-plugin have been released and a
> > stable revision for a vote has been set.
> >
> > I'd like to restart a vote based on:
> > - svn rev. 487861
> > - snapshot deployed at
> > http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> > maven/plugins/maven-eclipse-plugin/2.3-SNAPSHOT/maven-eclipse-
> > plugin-2.3-20061216.195001-12.jar
> > - documentation already updated at
> > http://maven.apache.org/plugins/maven-eclipse-plugin/
> > - changelog available at
> > http://jira.codehaus.org/browse/MECLIPSE?
> > report=com.atlassian.jira.plugin.system.project:roadmap-panel
> >
> > this release contains several bugfixes and new features, especially
> > related to eclipse plugin development. Lots of issues/enhancement
> > requests are still open, but users need a release before going on.
> >
> >
> > Vote is open for 72h
> >
> > My +1,
> > Fabrizio
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] release maven-eclipse-plugin 2.3 (second try)
Posted by Jason van Zyl <ja...@maven.org>.
Fabrizio,
When the release is ready to be made can I actually perform the
release? I would like to keep testing the new tools and move toward
having the release be made by one machine. The more releases I can do
to test this the better. I will document everything (Joakim and I
have started) and then it should be no problem for anyone to do it
for future releases.
jason.
On 16 Dec 06, at 2:59 PM 16 Dec 06, Fabrizio Giustina wrote:
> Dependencies used by the maven-eclipse-plugin have been released and a
> stable revision for a vote has been set.
>
> I'd like to restart a vote based on:
> - svn rev. 487861
> - snapshot deployed at
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> maven/plugins/maven-eclipse-plugin/2.3-SNAPSHOT/maven-eclipse-
> plugin-2.3-20061216.195001-12.jar
> - documentation already updated at
> http://maven.apache.org/plugins/maven-eclipse-plugin/
> - changelog available at
> http://jira.codehaus.org/browse/MECLIPSE?
> report=com.atlassian.jira.plugin.system.project:roadmap-panel
>
> this release contains several bugfixes and new features, especially
> related to eclipse plugin development. Lots of issues/enhancement
> requests are still open, but users need a release before going on.
>
>
> Vote is open for 72h
>
> My +1,
> Fabrizio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] release maven-eclipse-plugin 2.3 (second try)
Posted by Kenney Westerhof <ke...@apache.org>.
+1
Stephane Nicoll wrote:
> +1
>
> Stéphane
>
> On 12/16/06, Fabrizio Giustina <fg...@apache.org> wrote:
>> Dependencies used by the maven-eclipse-plugin have been released and a
>> stable revision for a vote has been set.
>>
>> I'd like to restart a vote based on:
>> - svn rev. 487861
>> - snapshot deployed at
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-eclipse-plugin/2.3-SNAPSHOT/maven-eclipse-plugin-2.3-20061216.195001-12.jar
>>
>> - documentation already updated at
>> http://maven.apache.org/plugins/maven-eclipse-plugin/
>> - changelog available at
>> http://jira.codehaus.org/browse/MECLIPSE?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>>
>>
>> this release contains several bugfixes and new features, especially
>> related to eclipse plugin development. Lots of issues/enhancement
>> requests are still open, but users need a release before going on.
>>
>>
>> Vote is open for 72h
>>
>> My +1,
>> Fabrizio
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] release maven-eclipse-plugin 2.3 (second try)
Posted by Stephane Nicoll <st...@gmail.com>.
+1
Stéphane
On 12/16/06, Fabrizio Giustina <fg...@apache.org> wrote:
> Dependencies used by the maven-eclipse-plugin have been released and a
> stable revision for a vote has been set.
>
> I'd like to restart a vote based on:
> - svn rev. 487861
> - snapshot deployed at
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-eclipse-plugin/2.3-SNAPSHOT/maven-eclipse-plugin-2.3-20061216.195001-12.jar
> - documentation already updated at
> http://maven.apache.org/plugins/maven-eclipse-plugin/
> - changelog available at
> http://jira.codehaus.org/browse/MECLIPSE?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>
> this release contains several bugfixes and new features, especially
> related to eclipse plugin development. Lots of issues/enhancement
> requests are still open, but users need a release before going on.
>
>
> Vote is open for 72h
>
> My +1,
> Fabrizio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [vote] release maven-eclipse-plugin 2.3 (second try)
Posted by Carlos Sanchez <ca...@apache.org>.
+1
On 12/16/06, Fabrizio Giustina <fg...@apache.org> wrote:
> Dependencies used by the maven-eclipse-plugin have been released and a
> stable revision for a vote has been set.
>
> I'd like to restart a vote based on:
> - svn rev. 487861
> - snapshot deployed at
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-eclipse-plugin/2.3-SNAPSHOT/maven-eclipse-plugin-2.3-20061216.195001-12.jar
> - documentation already updated at
> http://maven.apache.org/plugins/maven-eclipse-plugin/
> - changelog available at
> http://jira.codehaus.org/browse/MECLIPSE?report=com.atlassian.jira.plugin.system.project:roadmap-panel
>
> this release contains several bugfixes and new features, especially
> related to eclipse plugin development. Lots of issues/enhancement
> requests are still open, but users need a release before going on.
>
>
> Vote is open for 72h
>
> My +1,
> Fabrizio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org