+1 nice. Would be good to see Leiningen ( clojure ) and sbt ( scala )
mentioned as well to complete the set.
Mark
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Sun, Nov 27, 2011 at 6:33 AM, Simone Tripodi simonetrip...@apache.orgwrote:
Hi
+1 non binding.
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Fri, Nov 25, 2011 at 10:17 PM, Olivier Lamy ol...@apache.org wrote:
Hello,
I'd like to release Apache Maven 3.0.4.
We fixed 31 issues.
See release notes:
True this didn't really belong on the vote thread. My bad. The question
was more related to the actual Maven 3.0.4 release than just using
Aether/Sisu.
Not all plugins get mentioned in your poms, for example the archetype
plugin, or the dependency plugin, they're versions (afaik) are specified
Will Maven be updated to use recent versions of release plugins as part of
this 3.0.4 release?
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Fri, Nov 11, 2011 at 2:51 PM, Jeff Jensen
jeffjen...@upstairstechnology.com wrote:
+1 (non-binding)
+1 Non Binding. Just hopeful :)
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Fri, Nov 11, 2011 at 4:53 AM, Olivier Lamy ol...@apache.org wrote:
Since last vote things have changed:
* aether is in incubation process @eclipse
* sisu is in
If its stuck at the bottom of the pile for an unknown amount of time - I'd
REALLY love to see 3.0.4. ship out with the current non-eclipse Aether.
Leaving a broken Maven out in the wild for what appears to be politics more
than anything just continues to hurt the Maven name.
I was under the
+3
( why does every only +1 on these things - this aint Google folks! ).
Love the last example with multiple @Goal annotations on methods.
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Fri, Nov 4, 2011 at 11:49 PM, Simone Tripodi
On 30 September 2011 11:48, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
When I last checked, the code import is still waiting for PMC
approval... I
suspect that until the code has been imported there cannot be a release
;-)
On 30 September 2011 10:05, Mark Derricutt
Jason - is there any further news on the Aether/Sisu front? Really starting
to get an itch for a 3.0.4 release - my manager this morning was having
strange resolution issues that I traced to same issues I've been seeing with
the currently shipped aether.
Would be good to get a 3.0.4 release out
Would a compromise to something using the baseDir of the project ( or root
project ) and not an arbitrary relative path?
I can see a benefit to this, but I can also see not wanting to allow the user
to reach outside their SCM controlled project.
On 18/09/2011, at 3:42 AM, Benson Margulies
History I suspect. There was a discussion awhile ago about moving the projects
over, but that wasn't looking like a simple job.
Never saw any further threads about that...
On 30/08/2011, at 6:23 AM, Jason Pyeron wrote:
Why is the jira for maven at codehaus.org and not apache.org?
+1 Would vote again ;-)
Glad to see things can once again move on.
I look forward to seeing this release go out.
Maveno!
Mark
On 29/08/2011, at 12:10 AM, Arnaud Héritier wrote:
Thus with Olivier and Stéphane votes we have the majority (12/22) of PMCs
voting in favor to use as Maven core
You may be right, however after a quick investigation it looks like these javac
changes on JDK7 have been around for a long time ( and evolving ), as far back
as 2008:
http://blogs.oracle.com/mcimadamore/entry/improving_javac_diagnostics
Such is the joy of the only LONG release that Java7 was.
Hi all,
We noticed the other day that Java 7 has a modified/changed javac output for
error messages which trips up the maven-compiler-plugin so that it doesn't
properly parse the output.
I then found that someone else had already raised a ticket for this:
+1 Non Binding.
On 18/08/2011, at 9:23 PM, Arnaud Héritier wrote:
[+1] I'm in favor to use as Maven core dependencies SISU and AETHER libraries
published under EPL 1.0 License and released under eclipse.org governance
Please - for the love of ANY Maven user - please do NOT roll a 3.0.4 with any
Aether thats NOT 1.12.
1.11 that ships with the current Maven 3.0.3 has fundamental issues with your
local repository has artifacts from both mirrors and non-mirrors. I'm finding
more and more users getting hit with
Only that the majority of users will get just get unable to resolve artifact
errors, and probably never know that they can update aether - which, whilst it
isn't a difficult thing to do is just a bit fiddly - instead they'll just get
frustrated that once again maven black magic sucks.
If
+1 NON BINDING. Current maven remains fundamentally broken WITHOUT the newer
Aether libs, forking/rewriting would just cause delays, and/or even more bugs.
On 18/08/2011, at 2:19 AM, Arnaud HERITIER wrote:
[+1] I'm in favor to use as Maven core dependencies SISU and AETHER
libraries
The use case that we originally came with in our discussions revolved around
version ranges, and the fact that a version reference of 2.5.4 doesn't
actually mean give me 2.5.4 but rather I would like 2.5.4, but meh, use
something higher if you need to.
In the case were you have artifacts
Not from any of my use cases no.
Mark
On 31/07/2011, at 10:18 PM, Hervé BOUTEMY wrote:
This lets the question of pluggable version comparison need: is there a real
world example of unwanted version order?
Potentially not. I suppose if there was a way to say [2.0.0,3.0.0) *excluding
SNAPSHOTS* then that would certainly be in my favor.
From memory there was a discussion some time ago regarding range resolution
excluding -SNAPSHOTs unless the artifacts were also in the current reactor
build, from
I've been meaning to check out the clirr-plugin - I'll add that to my TODO
reading list for the morning.
On 1/08/2011, at 12:15 AM, Mark Struberg wrote:
PS: you can at least check the backward compat of your own lib with the
maven-clirr-plugin.
This sounds VERY much like the problem Richard Vowles reported awhile back
which is solved by ungrading Maven to use Aether 1.12.
The problem lies in having some artifcts downloaded directly, some from a
mirror. Maven generates a metadata file which includes a references to the
upstream
I replied to the other thread saying it sounded similar to MNG-5084 [1] - if
that sounds like it to you add your votes to the ticket.
[1] http://jira.codehaus.org/browse/MNG-5084
On 30/07/2011, at 8:31 PM, Dennis Lundberg wrote:
I haven't reported it in JIRA yet because I don't have anything
Hi all,
I wanted to start this discussion completely separate from any of the other,
rather heated ASL vs EPL discussions around Aether to try and keep this more on
topic.
For awhile we ( members of the Illegal Argument podcast ) have often discussed
a desire to have a pluggable dependency
On 31/07/2011, at 11:14 AM, Mark Derricutt wrote:
I imagine a difficulty in that this would have to occur early in the
bootstrap process of maven, but if this were the case, would we not be able
to work a solution to not only the Aether inclusion issues, but also Kasun's
Gentoo resolution
+1 Non Binding
On 29/07/2011, at 2:56 AM, Stephen Connolly wrote:
Hi,
This is a patch release to fix a particularly nasty regression:
http://jira.codehaus.org/browse/MRELEASE-697
-
To unsubscribe, e-mail:
As long as 1.12+ of Aether makes it into the 3.0.4 release:
+1 NON Binding
Without it Maven quite easily gets seriously broken :(
On 28/07/2011, at 6:45 AM, Benson Margulies wrote:
As per the approved policy, this message opens a vote to allow Maven
releases to depend on EPL (and thus
And was just as broken in 2.2.x with the exact same problem from what I've been
told by Richard who diagnosed and raised the JIRA ticket.
On 28/07/2011, at 8:46 AM, Mark Struberg wrote:
Remember: all this used to be just a part of maven-core in v2...
Just reading this thread and was surprised as I wasn't aware Aether had
gone EPL only.
I was about to start a thread around getting a Maven 3.0.4 release
pushed out using Aether 1.12 which solves a, IMHO -MAJOR- bug in Maven
that prevents artifacts from being resolved properly when they come
I think I died a little reading this. Maven itself already has subtle
strange issues and problems working with dependency ranges, having a gentoo
specific version of maven that does even more different things with artifact
resolution would be a nightmare to deal with. Esp. if you have developers
After having to disable my maven mirror for one reason or another awhile ago
I now seem to be getting hit with this rather annoying bug on quite a few
projects now that my ~/.m2/repository has a mix of artifacts downloaded via
a mirror, and others direct.
rm'ing the _maven.repositories file from
Wow - that seems like a hell of a lot of releases having to be made...
This post is probably drifting off topic but the thing that strikes me here
is that this is the exact reason why maven supports version ranges - so that
you don't have to make a plethora of rolling releases just because one
Derricutt m...@talios.com wrote:
From: Mark Derricutt m...@talios.com
Subject: Re: [VOTE]: release maven-changes-plugin 2.6
To: Maven Developers List dev@maven.apache.org
Date: Monday, June 20, 2011, 8:27 PM
Wow - that seems like a hell of a lot
of releases having to be made
I'd rather see a release with 3 bug fixes if they code base is idle than see
not see a release for weeks/months whilst someone waits for N more issues to
be resolved.
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Sun, Jun 19, 2011 at 8:34 PM,
Has there been any movement on this at all?Beyond the few messages here
and only Richards comments on the JIRA ticket it doesn't look like anyways
had a chance to look further into this.
From memory there's less than a handful of folk who know how the dependency
resolution works, more so now
Great to see this being discussed.
Initial thoughts that come to mind reading that you've got here ( which for
the most part all looks good ).
You mentioned the possibility of having the templates inline, rather than
templateSpecs I was wondering if using templateManagement to be
consistent
Hi all,
Another question about injecting resources into a maven mojo :) I'm trying
to lookup an instance of the ScmManager component in my mojo and all
evidence points to just needing to include:
/** @component */
private ScmManager scmManager;
in my mojo class ( which is what I see the
:
On 20/04/2011, at 7:52 PM, Benjamin Bentmann wrote:
Mark Derricutt wrote:
Does anyone have any pointers to what one needs to do to work
with/support
securitySettings.xml from within a custom mojo?
The comments and links in http://jira.codehaus.org/browse/MNG-4384should
provide some
Hey all,
I see they maven nightly/ci build no longer seems to be on
https://grid.sonatype.org/ci - has it moved somewhere?
Mark
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
,
Porcupine Tree
On Tue, Apr 26, 2011 at 12:21 PM, Jason Dillon ja...@planet57.com wrote:
There are running up here no?
https://builds.apache.org/hudson/view/M-R/view/Maven/
--jason
On Apr 25, 2011, at 5:16 PM, Mark Derricutt wrote:
Hey all,
I see they maven nightly/ci build no longer
Hey all,
Does anyone have any pointers to what one needs to do to work with/support
securitySettings.xml from within a custom mojo?
In my mojo I'm looking up a server with:
final Server mavenServer = session.getSettings().getServer(server);
but only see the encrypted strings and don't seem
'lo all,
I was just pointed at http://jira.codehaus.org/browse/MNG-2742 by a friend
and was wondering if anyone knew what the state of it was?
The problem is around version ranges not working for plugin dependencies.
Looking at the comments in the original ticket I see Mathew Adams was using
https://gist.github.com/082ac46dcbe0160e9ae4 is the debug output of
release:prepare that gets an NPE under 3.0.3
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Tue, Mar 1, 2011 at 8:40 PM, Mark Derricutt m...@talios.com wrote:
-1 non binding - I
Wilson,
Porcupine Tree
On Tue, Mar 1, 2011 at 1:23 PM, Mark Derricutt m...@talios.com wrote:
Yep - now that I have my release out ( well, deployment awaiting ) I'll
switch back and grab a log.
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
Raised this as http://jira.codehaus.org/browse/MNG-5031.
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Tue, Mar 1, 2011 at 9:48 PM, Mark Derricutt m...@talios.com wrote:
I posted a debug output of release:prepare with the current nightly
( 2.2.1
).
Please close.
+1 on this release.
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Tue, Mar 1, 2011 at 9:54 PM, Mark Derricutt m...@talios.com wrote:
Raised this as http://jira.codehaus.org/browse/MNG-5031.
--
Great artists are extremely
, Feb 27, 2011 at 9:53 PM, Mark Derricutt m...@talios.com wrote:
Have not tested the RC directly but have been using the nightlies from
Hudson/Jenkins on our OSGi/Felix project - no problems, releases all gold as
well.
Yep - now that I have my release out ( well, deployment awaiting ) I'll
switch back and grab a log.
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Tue, Mar 1, 2011 at 11:41 AM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
A test case or
-1 non binding - I had that null version issue earlier. Now home and will
try to reproduce it with a currently nightly.
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
2011/3/1 Tamás Cservenák ta...@cservenak.net
+1
On Feb 28, 2011 6:59 PM,
Have not tested the RC directly but have been using the nightlies from
Hudson/Jenkins on our OSGi/Felix project - no problems, releases all gold as
well.
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
2011/2/27 Arnaud Héritier
+1 from me - everything seems to be looking good.
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Sun, Jan 9, 2011 at 2:20 PM, Benjamin Bentmann benjamin.bentm...@udo.edu
wrote:
Hi,
We solved 25 issues since 3.0.1:
+1 from me - solves my mockito issue fine!
--
Mark Derricutt
Sent with Sparrow
On Thursday, 23 December 2010 at 12:39 PM, Kristian Rosenvold wrote:
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=17014
There are still a couple
Looks like I had a rogue debugger process left around, the mockito
issue is still haunting me tho.
This is on a line doing:
doReturn(something).when(spiedObject).doSomething();
I'll create an example project and see if I can that to break.
--
Great artists are extremely selfish and arrogant
Hrm,
I'm seeing some tests fail under 2.7 that use Mockito that pass fine
when using 2.6. This is only in one of our modules and not uniform
across other things that use mockito. Will investigate further.
--
Great artists are extremely selfish and arrogant things — Steven
Wilson, Porcupine
are extremely selfish and arrogant things — Steven
Wilson, Porcupine Tree
On Mon, Dec 20, 2010 at 4:17 PM, Mark Derricutt m...@talios.com wrote:
Hrm,
I'm seeing some tests fail under 2.7 that use Mockito that pass fine
when using 2.6. This is only in one of our modules and not uniform
across other
Kristian,
Where can I read about writing a pluggable provider? If it's what I
assume then gimme gimme gimme! :-)
Mark
--
Great artists are extremely selfish and arrogant things — Steven
Wilson, Porcupine Tree
On Wed, Dec 15, 2010 at 12:21 PM, Kristian Rosenvold
kristian.rosenv...@gmail.com
16.12.2010 11:05, skrev Mark Derricutt:
Kristian,
Where can I read about writing a pluggable provider? If it's what I
assume then gimme gimme gimme! :-)
Mark
--
Great artists are extremely selfish and arrogant things — Steven
Wilson, Porcupine Tree
On Wed, Dec 15, 2010 at 12:21 PM, Kristian
w00t - congrats to all developers and testers alike.
Time to go add an enforcer rule to all of $works projects for a 3.0 minimum
:)
--
Pull me down under...
On Fri, Oct 8, 2010 at 9:52 PM, Benjamin Bentmann benjamin.bentm...@udo.edu
wrote:
I will promote the artifacts to the central
+1 Bring on the 3.0!
--
Pull me down under...
On Wed, Oct 6, 2010 at 6:32 PM, Brett Porter br...@apache.org wrote:
+1
+1
--
Pull me down under...
On Tue, Oct 5, 2010 at 1:01 AM, Brett Porter br...@apache.org wrote:
Hi,
We solved 17 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=12571
Staging repo:
+1
Thinking about it - I like the idea of a (for lack of a better name)
~/.m2/resolutions.xml that provides control over the resolver.
First thoughts that come to mind:
- missing or empty file - existing 2.x behaviour, -SNAPSHOTS resolved
across the board.
- profile based (optional?)
Maybe
An odd thing I'm noticing trying to release some multi-module projects with
M3 nightlies:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on
project smx3.core: Execution default-cli of goal
Both options would be nice, but I think I'm leaning more in against
including sub groups in the default set.
A different group is after all, a different group ( and probably a different
group for a reason ).
Mark
--
Pull me down under...
On Tue, Sep 14, 2010 at 10:18 PM, Benjamin Bentmann
Hey guys,
I was wondering what was happening with the new release of the
maven-release-plugin? Things seemed to go quiet on that front this past
week or so...
I see that the SCM plugin got released tho, would be good to get the release
plugin to come along for the ride as well...
mark
--
Having read this a few times I think it sounds solid. I like the default
inclusion of snapshot groups in the build as a default, this will help
existing users move along without really seeing any changes in their
behavior.
Would it be good to also log a warning note to the console to report the
I'd had a similar thought initially, but I've not really looked at the
internals of maven yet to know if there is such a distinct thing, or a
pluggable resolver ( I did see that the resolution was on the VersionRange
class so I suspect maybe there isn't ).
Mark
--
Pull me down under...
On Fri,
Personally I'd still like to see some resolution to the problems introduced
by the version range resolution change ( no more -SNAPSHOT resolution except
for on the bounds ).
On one hand I applaud the change from a release standpoint, but it currently
causes issues for our integration build
Any pointers to where in the code base I should start looking/hacking if I
wanted to try and write such a patch?
As I'm the main one arguing for this improvement, I'm willing to at least
try and solve it :)
--
Pull me down under...
On Fri, Sep 3, 2010 at 1:27 PM, Brian Fox bri...@infinity.nu
+1 The artifacts I was getting the NPEs on during release no longer NPE with
current SNAPSHOTs and this build.
--
Pull me down under...
On Tue, Aug 31, 2010 at 1:09 AM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Hi,
what's a better start for a week than a new fresh release :-) ?
as our repo manager
mark
--
Pull me down under...
On Thu, Aug 26, 2010 at 11:00 PM, Benjamin Bentmann bentm...@apache.orgwrote:
Mark Derricutt wrote:
-1 - I'm getting NullPointerExceptions with the aether in todays current
nightly build when doing releases.
https://gist.github.com
Hey all,
Just doing a bunch of artifact releases today and noticed that I'm getting
NPEs. I guess this is related to the Guice/aether merge.
The log/error can be seen at https://gist.github.com/8ac6e71ad49cf8928549
Where do we raise issues for this now?
Mark
--
Pull me down under...
-1 - I'm getting NullPointerExceptions with the aether in todays current
nightly build when doing releases.
https://gist.github.com/8ac6e71ad49cf8928549
Raised as http://jira.codehaus.org/browse/MNG-4779
--
Pull me down under...
On Thu, Aug 26, 2010 at 2:59 PM, Oleg Gusakov
I'd love to offer more feedback on beta-2, but since it totally breaks our
builds it's a non-starter. Without reworking our entire build setup ( which
we're going to do anyway when we move to git ) M3 is effectively unusable
for my main $work project.
Which is a shame as all the new things look
Bentmann
benjamin.bentm...@udo.edu wrote:
Mark Derricutt wrote:
Ideally, what I'd love to see is a way of allowing -SNAPSHOT resolution in
ranges as an option, so that for those particular artifacts that need it,
still get them.
Thoughts?
Vote on http://jira.codehaus.org/browse/MNG-4751
+100 - works on one of my OSGi artifacts where beta-1 ( and last SNAPSHOTs
from a week or so ago ) failed.
My only issue left is the lack of -SNAPSHOTs in version ranges ( an ongoing
M3 gripe that hopefully some mid-way resolution can be discovered ).
--
Pull me down under...
On Wed, Aug 11,
Don't we need to have guice/aether merged in -before- we can talk about the
release?
Or has the great merge already happened?
--
Pull me down under...
On Tue, Aug 10, 2010 at 10:28 AM, Ed Staub esta...@comcast.net wrote:
In the discussion over the weekend, it seemed like a high value was
Wouldn't this have the same problem with Apache based code? Doesn't the
Apache Contributor agreements say you assigned copyright over to Apache?
As you say - out of scope for the list. I'll take my answer off-list (mmm,
sounds like a talk back radio caller!).
--
Pull me down under...
On Mon,
+1 on releasing beta-2 followed -very quickly- with beta-3 inc guice/aether
(like days apart). Tho I wonder if it might confuse people - but then, if
you're playing with beta's you're probably following these threads anyway ).
Mark
--
Pull me down under...
2010/8/6 Arnaud Héritier
+1 from me - I assume us joe-shmoe users can vote?
--
Pull me down under...
On Wed, Aug 4, 2010 at 10:11 PM, Olivier Lamy ol...@apache.org wrote:
Hi,
In preparation of the Release Plugin release, I'd like to release Maven Scm
1.4.
We solved 22 issues :
Out of curiository - are the guice/aether changes available in separate
branches at all?
Can the guice stuff be merged in cleanly independent of aether? If so - I'd
like to see the guice code merged in, and deal with aether as a separate
thing.
--
Pull me down under...
On Wed, Aug 4, 2010
While not release plugin specific, there's a few Maven SCM issues which
effect the release process when using git.
One of the mains ones being http://jira.codehaus.org/browse/SCM-444 - which
provides functionality to disable a git push during release:prepare.
If we're doing a release of the
Hey all,
A while I posted on a change in version range behaviour under Maven 3
(MNG-3092 [1]) but didn't really get much response ( which may have
unfortunately been related to my tone at the time ).
Any way, the change in question is that version ranges no longer resolve a
-SNAPSHOT version
be bumping major/minors
quite often...
Look forward to hearing some comments from you all.
--
Pull me down under...
On Tue, Jun 29, 2010 at 12:10 AM, Mark Derricutt m...@talios.com wrote:
Can someone comment on MNG-3092 please, and tell me that this is some
form of joke? Or that I'm missing
Can someone comment on MNG-3092 please, and tell me that this is some
form of joke? Or that I'm missing something.
If Maven 3 is supposed to backwards compatible and non-breaking with
Maven 2 then such a change to make version ranges no longer resolve to
available SNAPSHOTs seems like a major
JUnit 4 apparently runs JUnit 3 tests out of the box, so one could feasibly
change the dependencies to JUnit 4 at least. I understand the reasons for
not physically changing old tests for the sake of change tho.
Mark
--
Pull me down under...
On Tue, Jun 8, 2010 at 6:29 AM, Jason Chaffee
301 - 386 of 386 matches
Mail list logo
