I think Benjamin already commented on this, but you need to write to
keep this on a branch and write a lot of ITs and make sure it all
works on the grid before putting this in trunk. It is super, super
stable at the moment and we rely on trunk for everything in M2Eclipse
so you kill us
You simply have to realize that your priorities are not our priorities
and though you have a patch we might all be busy which is generally
the case.
There are patches available for lots of things, it's still very time
consuming to test and I don't see any tests associated with that patch
Is there any way to override the clean lifecycle
I have overridden the default lifecycle and it would be useful to add a goal to
the pre-clean phase. The pom would be cleaner if I add that in components.xml.
thanks
Dan,
Also curious if you just did this because it was on trunk, or you find
working with trunk code easier.
On 2009-11-06, at 10:49 PM, Dan Fabulich wrote:
In revision 833566, I checked in experimental support for
multithreaded builds in Maven 3.0 trunk.
This works on my machine:
mvn
Hi All,
Maybe this has been discussed (although Google didn't find anything in
the archives).
What about... a Repository Delegation mechanism, like zone delegation in
DNS? IE. the central repo could delegate the com.mycompany group (and
all children) to my hosted repo, and I manage whats
Hi,
OK, here we go, another alpha release of Maven, for all those brave guys
that want to take it for a test drive ;-)
We solved many issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=14719
There are still a couple of issues left in JIRA:
+1 from me
2009/11/9 Benjamin Bentmann benjamin.bentm...@udo.edu:
Hi,
OK, here we go, another alpha release of Maven, for all those brave guys
that want to take it for a test drive ;-)
We solved many issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=14719
+1
Tested with success on several projects
It becomes to be interesting :-)
Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net
On Mon, Nov 9, 2009 at 5:44 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
+1 from me
Benjamin Bentmann schrieb:
So I wouldn't like to see such experiments on trunk, given we are trying
to stabilize it. Hence I created a branch with your changes and reverted
them on trunk.
In talking with Dan and Wendy on IRC I realized that my immediate
reaction of reverting Dan's commit
Benjamin Bentmann wrote:
Benjamin Bentmann schrieb:
So I wouldn't like to see such experiments on trunk, given we are trying to
stabilize it. Hence I created a branch with your changes and reverted them
on trunk.
In talking with Dan and Wendy on IRC I realized that my immediate reaction of
+0 (non binding)
I'm using m2eclipse from the trunk, using the embedded maven 3 from
the trunk, to build several in-house projects.
No problems for now
2009/11/9 Arnaud HERITIER aherit...@gmail.com:
+1
Tested with success on several projects
It becomes to be interesting :-)
Arnaud Héritier
While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed
up with a quick conversation with Brett about a problem that is soon going to
hit CXF/Axis2/Geronimo.
Basically, we're going to need a mechanism to easily endorse a few api jars
when we call javac and when surefire
2009/11/9 Daniel Kulp dk...@apache.org:
While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed
up with a quick conversation with Brett about a problem that is soon going to
hit CXF/Axis2/Geronimo.
I've already hit some interesting poms towards that end of the
projects
9) use a new plugin (let's call it maven-java-plugin) to give us
namespacing in the pom. you'd add the plugin to the API pom and its
configuration section would annotate the pom with information about
what jdk versions the dependency is provided in, what versions it shod
be endorsed in,
On Friday I was playing cowboy with my experimental thread support, but
here's a more formal proposal around parallel project support in Maven
3.0.
OUTSTANDING ISSUES
In my earlier revision 833566, I attempted to fix MNG-3004:
Allow build lifecycle to execute projects in parallel
I just posted a proposal that the code I checked in before this
announcement should make it in to alpha-3.
I think if I vote -1 that will veto the release. I don't think that's
professional (I did just break the build three days before the release
vote, and I'm still quite ashamed by it),
On 10/11/2009, at 2:05 PM, Dan Fabulich wrote:
I just posted a proposal that the code I checked in before this
announcement should make it in to alpha-3.
I think if I vote -1 that will veto the release. I don't think
that's professional (I did just break the build three days before
I haven't tested alpha-3 yet, but I don't want to see anything derail that,
since it's been a long time coming. I think it would be better for issues
found after the last 11 months of changes to be separate from anything
introduced by a multi-threaded build.
Agreed. Unless you can attach the
It's not done yet.
On Sat, Nov 7, 2009 at 5:38 AM, Gilles Scokart gscok...@gmail.com wrote:
2009/11/6 Stephen Connolly stephen.alan.conno...@gmail.com
I suspect that the plug-ability being introduced in 3.0 will mean that
we are able to provide a hook for m3 to discover how to handle newer
On Mon, Nov 9, 2009 at 8:02 PM, Dan Fabulich d...@fabulich.com wrote:
I attempted to check in the code in time for 3.0-alpha-3 a few days ago.
That code was rolled back over the weekend and now lives in the MNG-3004
branch, because it broke integration tests. All integration tests now pass
on
I've done something for the javaee6 archetypes at mojo. I suppose you are
talking the same problem. Only compilation now, not surefire. It's a
solution within current constraints only. When leaving these behind, I would
go for endorsed scope.
21 matches
Mail list logo
