I tried with my current checkout, an update (with the new invoker config)
and with a fresh checkout (directory removed and svn co). All three worked
on my Mac (15.0.4)
Can you try with a fresh checkout maybe?
Thanks,
Stéphane
On Wed, Aug 6, 2008 at 10:27 PM, Arnaud HERITIER [EMAIL
Same thing with a fresh checkout.
My env (if you find something strange ...) :
octo-ahe:maven-ear-plugin arnaud$ set
Apple_PubSub_Socket_Render=/tmp/launch-l6EBjN/Render
BASH=/bin/bash
BASH_ARGC=()
BASH_ARGV=()
BASH_LINENO=()
BASH_SOURCE=()
BASH_VERSINFO=([0]=3 [1]=2 [2]=17 [3]=1 [4]=release
Hi Brian --
Sorry. I got the impression from Brett that it was a maven project decision.
Having said that I am not in the ASF and you guys are . so you attend
meetings/are on the right email lists etc. So if you want to (or not) pass
this on to others go ahead
anyhow enough on this
There's also this from John:
http://docs.codehaus.org/display/MAVEN/Conflict+Resolution
It'd also be worth reviewing the requirements for 2.0.x to see if
anything carries over:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
How does Mercury handle the
Some comments/questions on the doc Jason mentioned. Skipping entirely
the question of when since that's a very different discussion.
There are several plugins that are using the current artifact
resolution code that will not be supported (please see the Mercury
section below).
If the old
anyone else?
On 05/08/2008, at 9:04 AM, John Casey wrote:
I can be there, I think.
Brett Porter wrote:
Hi,
As I shift back to looking at 2.1-alpha-1 regressions in JIRA and
the changes on trunk so far, I was hoping we could have a once off
meeting in IRC to gather up who's working on
Not at 11am (dinner time in france)
Perhaps later in the night
Arnaud
On Thu, Aug 7, 2008 at 10:45 AM, Brett Porter [EMAIL PROTECTED] wrote:
anyone else?
On 05/08/2008, at 9:04 AM, John Casey wrote:
I can be there, I think.
Brett Porter wrote:
Hi,
As I shift back to looking at
Ok, I found.
Thanks Benjamin.
The problem was in my user's settings that the verifier wasn't able to read
(maven is able).
I have to see if I can create a testcase to fix the verifier
It seems I had in a coment a character with an accent (é, è ...)
Arnaud
On Thu, Aug 7, 2008 at 9:01 AM, Arnaud
On 07/08/2008, at 6:58 PM, Arnaud HERITIER wrote:
Not at 11am (dinner time in france)
Perhaps later in the night
Right, of course... that works for me, I'll be happy to get up later :)
What's a better time?
I'll see who is around maybe an hour or two after that.
Cheers,
Brett
Arnaud
+1
--
Olivier
2008/8/6 Arnaud HERITIER [EMAIL PROTECTED]:
+1
Tested on our others plugins
Arnaud
On Wed, Aug 6, 2008 at 11:08 PM, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hi,
We solved 7 issues:
I'd love to but I have conflicting meetings.
Ralph
Brett Porter wrote:
anyone else?
On 05/08/2008, at 9:04 AM, John Casey wrote:
I can be there, I think.
Brett Porter wrote:
Hi,
As I shift back to looking at 2.1-alpha-1 regressions in JIRA and
the changes on trunk so far, I was hoping we
We should be focusing on the release candidate in the short term.
As far as 2.1 discussions so productive discussion will happen 1)
unless people have the necessary background, and 2) are given enough
time to prepare.
I have no time until next week for a couple hour discussion, and
I think that to be clear moving forward, the information (and, I
suppose, background) should probably focus on creating a formal,
*written* spec for every major piece - separate ones for lifecycle
management, project building, artifact resolution, etc...*not*
describing what we're currently in
On 08/08/2008, at 1:04 AM, Jason van Zyl wrote:
We should be focusing on the release candidate in the short term.
Of course.
As far as 2.1 discussions so productive discussion will happen 1)
unless people have the necessary background, and 2) are given enough
time to prepare.
That's
On 7-Aug-08, at 9:07 AM, John Casey wrote:
I think that to be clear moving forward, the information (and, I
suppose, background) should probably focus on creating a formal,
*written* spec for every major piece - separate ones for lifecycle
management, project building, artifact
On 7-Aug-08, at 9:21 AM, Brett Porter wrote:
On 08/08/2008, at 1:04 AM, Jason van Zyl wrote:
We should be focusing on the release candidate in the short term.
Of course.
As far as 2.1 discussions so productive discussion will happen 1)
unless people have the necessary background, and
Jason van Zyl wrote:
I've asked Oleg do document the architecture in Mercury
Doing. May take several days as there is a lot to cover and I have to
joggle this activity with the rest.
Thanks,
Oleg
-
To unsubscribe,
Yah, it doesn't need to be complete to talk about it. It's just highly
useful for people to understand the motivation, and to dig in if they
see fit and to do that they need to understand the mechanics of the
system.
On 7-Aug-08, at 10:06 AM, Oleg Gusakov wrote:
Jason van Zyl wrote:
On Thu, Aug 7, 2008 at 9:27 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
We can call it whatever version. At this point I don't think it much
matters.
I'd like to see the current trunk moved to a code-named branch, so
that we can make incremental improvements in 2.1, 2.2, 2.3, etc.
In the
If anyone wants to know anything about Mercury. Greg/Jan/Jesse are in
town and Oleg and I are going to hang out with them tonight but we can
try to address any concerns people might have. We'll all be together
so we can chat about anything as being together will make that easy.
Hopefully
If you are actually helping to develop the core code then I'm sure
that's definitely one of the approaches we could take.
On 7-Aug-08, at 10:18 AM, Wendy Smoak wrote:
On Thu, Aug 7, 2008 at 9:27 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
We can call it whatever version. At this point I
One thing that we could also do is to have a meeting together one time per
year.
I know that some dev teams are doing it (groovy for example) just before or
after an event like JavaOne.
They work together during 2 or 3 days to analyze their project and to
prepare the future.
They share their
fair warning if we see batman there might end up being the
JokerException and HissyFitException cropping up in Mercury :)
jesse
On Thu, Aug 7, 2008 at 12:23 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
If anyone wants to know anything about Mercury. Greg/Jan/Jesse are in town
and Oleg and I are
Benjamin,
Which job in Hudson are you using to run all the ITs?
This one:
http://ci.sonatype.org/view/Plugins/job/Maven-Plugins-ITs/
If so I will clone it, make a 2.1-SNAPSHOT installation (that feeds
off the CI build for 2.1) and then use that version of Maven in the
plugin IT job.
On
Hi Benjamin,
2008/8/7 [EMAIL PROTECTED]:
Author: bentmann
Date: Thu Aug 7 10:41:00 2008
New Revision: 683661
URL: http://svn.apache.org/viewvc?rev=683661view=rev
Log:
o Synced id and activation of integration-tests with core ITs
Modified:
Hi Jason,
Which job in Hudson are you using to run all the ITs?
This one:
http://ci.sonatype.org/view/Plugins/job/Maven-Plugins-ITs/
Arnaud has been maintaining the Hudson jobs but as far as I know the one
you mentioned should be running the ITs (and has due to the expected
long running
Hi Vincent,
Removing this activation check, ITs will never be been called by
default. Is it really the wanted behaviour?
IMHO I think unit testing implies IT testing. Does I missed something?
Well, it appears to be a personal taste: I am just like you in favor of
running tests (whatever
Author: bentmann
Date: Thu Aug 7 11:08:15 2008
New Revision: 683667
URL: http://svn.apache.org/viewvc?rev=683667view=rev
Log:
o Added stub IT profile to highlight plugins during CI
I fear I need to revert this, a reactor invocation in combinatin with
the run-its profile is now failing due to
2008/8/7 Benjamin Bentmann [EMAIL PROTECTED]:
Hi Vincent,
Removing this activation check, ITs will never be been called by
default. Is it really the wanted behaviour?
IMHO I think unit testing implies IT testing. Does I missed something?
Well, it appears to be a personal taste: I am just
Hi,
Agree with Vincent, they must be activated by default (for me it tests
are similar to a junit tests).
And as we have documented in the surefire mojo : skip ... Its use is
NOT RECOMMENDED ..
By the way I can add some extra parameters during my build.
But I can forget and maybe commit
Wendy Smoak wrote:
On Thu, Aug 7, 2008 at 9:27 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
We can call it whatever version. At this point I don't think it much
matters.
I'd like to see the current trunk moved to a code-named branch, so
that we can make incremental improvements in 2.1, 2.2,
Why Hudson doesn't retreive the new modello plugin ?
https://ci.sonatype.org/view/Plugins/job/Maven-Plugins-ITs/187/console
Arnaud
On Wed, Aug 6, 2008 at 9:16 PM, Hudson [EMAIL PROTECTED] wrote:
See
So, where are we collecting all of this information? I'm digging up some
of the proposals that I wrote up in the past couple years, some of which
I've already implemented on trunk (and IIRC all of which have been
floated on this list).
A lot of these things already exist, they just need to be
IMO, this is also relevant, though is hasn't been implemented:
http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C+and+Replacement+of+Plugins+and+Mojos+Bindings
Jason van Zyl wrote:
On 7-Aug-08, at 9:21 AM, Brett Porter wrote:
On 08/08/2008, at 1:04 AM, Jason van Zyl wrote:
I just setup maven 2.0 and 2.1 builds for plugins :
https://ci.sonatype.org/view/Plugins/
I also updated their configurations to have integration-tests launched in IT
builds
Arnaud
On Thu, Aug 7, 2008 at 8:40 PM, Benjamin Bentmann [EMAIL PROTECTED]
wrote:
Hi Jason,
Which job in Hudson are
All,
after the entirely underwhelming response to the versions-maven-plugin
(MOJO-1178) I have had some ideas for making it even better...
The ideas may result in completely refactoring the thing apart... bits to go
in the enforcer plugin... bits to go in the release plugin... bits to maybe
stay
Anything should be visible on the proposals page. I will put my
gathering document in the wiki tonight.
But I'll link in what you've high lighted so far. So just mentioning
it is good enough, I'll integrate it.
On 7-Aug-08, at 12:51 PM, John Casey wrote:
So, where are we collecting all of
As I said in another thread, we just ended 3.
We named the profile integration-tests but to have the same name as in the
core we'll rename it run-its
It seems that there is 2 point of view about ITs activation :
-1) ITs are part of the build and always launched
-2) ITs are launched on demand
This is exactly why I'd like to put the current trunk code on the path of
being released as 3.0. We have tons of things that could reasonably be
improved in 2.0.x, but aren't really appropriate in such a minor release as
2.0.11. We could move toward larger feature introductions like import
You're right, we have to activate them in the release process.
CI will launch them automatically every 4 hours.
IT's are often very long.
The problem we have actually (see my other thread) is that we develop too
many ITs and not enough UTs.
That's why I would prefer to have a good code coverage
not a bad idea john...
the major concern I would have is that 3.0 in this case is already the
basis of all the embedder work (ie IDE development) while the
2.0.x-2.1 releases would in essence have to be forward compatible
with 3.0 because of that...the build in the IDE _ought_ to work the
same as
The survey has been open for a week now and has now been closed. Thanks
to the 47 people who took the survey!
Here are the top 5 five most wanted plugin releases:
Plugin Response Percent
war 12.8%
release 12.8%
enforcer10.6%
Hi,
Some of this improvements are in the invoker-plugin ;-).
You can configure it to run faster [1]. All plugins have been
configured as it and IMHO it's very faster. (I have to admit I don't
know shitty and don't fi it has a such feature).
My question is : why do prefer shitty (the name ? :- ) .
I also think they should be activated by default.
Olivier Lamy wrote:
Hi,
Agree with Vincent, they must be activated by default (for me it tests
are similar to a junit tests).
And as we have documented in the surefire mojo : skip ... Its use is
NOT RECOMMENDED ..
By the way I can add some
It's faster than before and it is good, but it is always longer than in
memory tests.
I used shitty for the grails plugin and it just work fine.
I'm interested t have groovy or another langage than bsh but it isn't
important.
Brett's wiki page sumarizes very fine what I would like to have for ITs
Hi all,
You noticed that we changed in plugins the behavior of ITs.
We would like to have your advice :
Do you want to have ITs activated by default in the plugin build ?
Why ?
--
..
Arnaud HERITIER
No. The Its should be on demand + defaulted to On in a profile set by
CI.
Why? Its should be exhaustive enough that they take too long to run on
every build while doing development. Just like the maven it's they
should be run at the end of development to verify + by each ci run.
-Original
2008/8/7 Arnaud HERITIER [EMAIL PROTECTED]:
Hi all,
You noticed that we changed in plugins the behavior of ITs.
We would like to have your advice :
Do you want to have ITs activated by default in the plugin build ?
+1 : yes they should be activated by default.
Why ?
John Casey wrote:
This is exactly why I'd like to put the current trunk code on the path
of being released as 3.0. We have tons of things that could reasonably
be improved in 2.0.x, but aren't really appropriate in such a minor
release as 2.0.11. We could move toward larger feature
Stephen Connolly wrote:
Questions:
Is there any way to modify the pom at run time to alter the versions of
dependencies *before* the dependencies have been resolved? It would be for
that invokation of maven only... it would avoid modifying the pom on disk
and forking another build.
Thanks,
First preference: disabled by default, but easily enabled.
Second preference: enabled by default, but with a separate property to
disable (so you can run UTs and skip ITs).
The purist in me wants to enable by default in the integration-test
phase, and just run up to test or package. But
Go see Batman, it's good fun :)
On 08/08/2008, at 3:23 AM, Jason van Zyl wrote:
If anyone wants to know anything about Mercury. Greg/Jan/Jesse are
in town and Oleg and I are going to hang out with them tonight but
we can try to address any concerns people might have. We'll all be
together
Does that just mean some plugins need to be locked down to their non-
latest equivalent in the reactor build, so you aren't using what you
are building?
- Brett
On 08/08/2008, at 4:53 AM, Benjamin Bentmann wrote:
Author: bentmann
Date: Thu Aug 7 11:08:15 2008
New Revision: 683667
URL:
On 08/08/2008, at 5:45 AM, John Casey wrote:
This is exactly why I'd like to put the current trunk code on the
path of being released as 3.0. We have tons of things that could
reasonably be improved in 2.0.x, but aren't really appropriate in
such a minor release as 2.0.11. We could move
Is TRUNK really 3.0? Hmm.. Maybe not. I think it is only appropriate
to bump the first number when you make a major architecture change. It
was totally appropriate between 1.x and 2.x because the code bases are
absolutely incompatible. Why I should believe the same for TRUNK now?
It still looks
Issue Subscription
Filter: Design Best Practices (28 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
On 08/08/2008, at 12:24 PM, Paul Benedict wrote:
Is TRUNK really 3.0? Hmm.. Maybe not. I think it is only appropriate
to bump the first number when you make a major architecture change. It
was totally appropriate between 1.x and 2.x because the code bases are
absolutely incompatible. Why I
I was poking back through the archives for a couple of things related
to Maven core and was having trouble since it was drowned out in
plugin development discussion and votes.
Considering plugin dev occurs on more on the stable basis of previous
versions of Maven it seemed to make some
I put together a high-level, descriptive overview of the project builder:
http://docs.codehaus.org/display/MAVENUSER/Project+Builder. The nitty gritty
is located here: http://docs.codehaus.org/display/MAVENUSER/Maven+Project
Thanks,
Shane
On 08/08/2008, at 8:33 AM, [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Thu Aug 7 15:33:15 2008
New Revision: 683740
URL: http://svn.apache.org/viewvc?rev=683740view=rev
Log:
[MNG-3698] Moved concrete/dynamic transitions out to the lifecycle
executor to make them happen less often, and
I am still getting a failure from
MavenITmng3694ReactorProjectsDynamismTest though - is that known?
Cheers,
Brett
On 08/08/2008, at 2:08 PM, Brett Porter wrote:
On 08/08/2008, at 8:33 AM, [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Thu Aug 7 15:33:15 2008
New Revision: 683740
URL:
It sounds like a good idea, but I don't think it's that easy to split
apart. It seems like a lot of plugin issues still require fixes to the
core. That's been more evident since 2.0.8 when regressions became a
serious topic to tackle. I suggest the timing is not yet right to
split the list. Maybe
We need one more vote for this one...
Any IDEA users out there?
Dennis Lundberg wrote:
Hi,
Second try, this time with a license header in the POM.
Note: there is one error in the Clirr report. It was necessary to make
that change to solve the testing for IDEA-102, so it's by design.
We
No. That's no good. I want to be able to do this without people having to
modify their poms to work with this scheme.
The rewrite poms version would scan through the reactor projects, and
wherever a reactor project depends on a (different version) of another
reactor project, it would force the
+1 (reviewed the code changes, checked licenses, generated a multi-
module project and opened then converted it in 7.0.3)
On 08/08/2008, at 3:17 PM, Dennis Lundberg wrote:
We need one more vote for this one...
Any IDEA users out there?
Dennis Lundberg wrote:
Hi,
Second try, this time with
65 matches
Mail list logo
