ok, i'll back it out
On 5 August 2010 13:20, Benjamin Bentmann benjamin.bentm...@udo.edu wrote:
Stephen Connolly wrote:
I can roll it back out just wanted to ensure that because I was
specifying the requirements that they would be stated on the site
Well, the maven-plugin-plugin
Toolchains dude toolchains
Maven inself requires 1.4 to run for the 2.0 line AFAIK and 1.5 for the
2.2.1+ line so those plugins require 1.4 to run
But the toolchains support would allow running tests using forking on JDK
1.3
-Stephen
On 5 August 2010 14:12, Kristian Rosenvold
Yes, you fixed the issue. Cool !
;)
K
Den 5. aug. 2010 kl. 15:35 skrev Stephen Connolly
stephen.alan.conno...@gmail.com:
I'm fine with us dropping support for 1.3... people can still use surefire
2.2 if they need to run with jdk 1.3... or we can revisit surefire booter
but perhaps a vote.
To my point earlier, perhaps beta-2 could be tagged/cut/released before the
merges take place. Once the merges take place, you could spin beta-3 with
these new additions rather quickly. I would consider that to be good plan --
at one time, Jason did posted that wanted betas to be released every 2
Is it blocker for something for you ? (I mean in the sonar stuff ).
If yes, I can certainly cancel the vote and restart the process.
Let me know.
2010/8/5 Evgeny Mandrikov mandri...@gmail.com:
Hi Olivier,
Looks like patch for SCM-532 was incomplete in case of CVS providers,
so I've created
Le Wed, 04 Aug 2010 23:53:49 +0200,
Dennis Lundberg denn...@apache.org a écrit :
The Maven team is pleased to announce the release of the Maven Doxia
Tools, version 1.1
Doxia Tools is a set of tools for working with Doxia documents. It
contains a Converter and a Linkchecker.
Yes, clearly a copy-paste error from another release Dennis is doing right
now. The artifactId should be 'doxia-tools'.
/Anders
On Thu, Aug 5, 2010 at 09:51, Tony Chemit che...@codelutin.com wrote:
Le Wed, 04 Aug 2010 23:53:49 +0200,
Dennis Lundberg denn...@apache.org a écrit :
The Maven
Mark Derricutt wrote:
Can the guice stuff be merged in cleanly independent of aether?
Yes, see patch at http://jira.codehaus.org/browse/MNG-4749.
There are no interdependencies between Aether and the
Plexus-Guice-Bridge. The Git branch I mentioned earlier aggregates them
for the sole
Hi there,
As for Guice, I think that what JVZ said does stands: a very few people does
understand how big and complex that work was (and is, since it is ongoing).
Stuart did a real magic, with just a drop in replacement for
Plexus-components backed by Guice. But don't stop there. With his
OK, I am going to round off my view on the topic.
Guice integration: +1
Aether integration: +0.99 _for now_... let's suck it and see... if it
works well and the interaction between the two code bases works well, then
all is good.
There is a generic issue when we have volunteers and paid for
Dennis Lundberg wrote:
Staging repo:
https://repository.apache.org/content/repositories/maven-066/
Staging site:
http://maven.apache.org/plugins/maven-linkcheck-plugin-1.0/
+1
Benjamin
-
To unsubscribe, e-mail:
Yes - it's blocker.
On Thu, Aug 5, 2010 at 10:46, Olivier Lamy ol...@apache.org wrote:
Is it blocker for something for you ? (I mean in the sonar stuff ).
If yes, I can certainly cancel the vote and restart the process.
Let me know.
2010/8/5 Evgeny Mandrikov mandri...@gmail.com:
Hi Olivier,
+1
-Lukas
Dennis Lundberg wrote:
Hi,
This is the first release of this plugin. There are no issues in JIRA.
If you want to see it in action, it has been configured in a profile
called linkcheck in the POM for the Maven site.
Staging repo:
+1
Emmanuel
On Thu, Aug 5, 2010 at 12:41 AM, Dennis Lundberg denn...@apache.org wrote:
Hi,
This is the first release of this plugin. There are no issues in JIRA.
If you want to see it in action, it has been configured in a profile
called linkcheck in the POM for the Maven site.
Staging
+1
2010/8/5 Dennis Lundberg denn...@apache.org:
Hi,
This is the first release of this plugin. There are no issues in JIRA.
If you want to see it in action, it has been configured in a profile
called linkcheck in the POM for the Maven site.
Staging repo:
So vote cancelled I will restart a new process.
arf cvs pain of my life :-)
2010/8/5 Evgeny Mandrikov mandri...@gmail.com:
Yes - it's blocker.
On Thu, Aug 5, 2010 at 10:46, Olivier Lamy ol...@apache.org wrote:
Is it blocker for something for you ? (I mean in the sonar stuff ).
If yes, I can
Sorry for that and yes - cvs is a pain.
On Thu, Aug 5, 2010 at 16:03, Olivier Lamy ol...@apache.org wrote:
So vote cancelled I will restart a new process.
arf cvs pain of my life :-)
2010/8/5 Evgeny Mandrikov mandri...@gmail.com:
Yes - it's blocker.
On Thu, Aug 5, 2010 at 10:46, Olivier
A thing I forgot to add yesterday :
For me Maven is a success because of its fundamentals (rules/guidelines) which
allowed to created a large large variety of services with plugins.
The value of Maven is many many more in its plugins than in its core (I don't
want to reduce the work done on
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
Benjamin
Hi,
In preparation of the Release Plugin release, I'd like to release Maven Scm 1.4.
Change since first try : fix for SCM-568
We solved 23 issues :
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527version=16128
Staging repo:
2010/8/5 Olivier Lamy ol...@apache.org:
Hi,
In preparation of the Release Plugin release, I'd like to release Maven Scm
1.4.
Change since first try : fix for SCM-568
We solved 23 issues :
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527version=16128
Staging repo:
Where is maven-toolchain... the last one I can find in SVN:
https://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x/maven-toolchain
repo1, shows that there was a 3.0-alpha-1 and 3.0-alpha-2 release but no
3.0-beta-1 release...
OK, I can see:
r789006 | bentmann | 2009-06-27 19:18:46 +0100 (Sat, 27 Jun 2009) | 1 line
Changed paths:
M /maven/components/trunk/apache-maven/pom.xml
M /maven/components/trunk/maven-core/pom.xml
M
Having worked with Aether yesterday in some test code, and after
sleeping on it last night, I'll withdraw my objections for now.
This looks like a good way forward in terms of code. I'm still concerned
about volatility in terms of writing plugins that need to resolve X or Y
artifact at
https://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/toolchain/
On Aug 5, 2010, at 10:21 AM, Stephen Connolly wrote:
Where is maven-toolchain... the last one I can find in SVN:
Stephen Connolly wrote:
Where is maven-toolchain...
maven-core
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
H
So if I want to add more core toolchains I now have to push the changes to
core, or will the classloader always take from core and not from a newer
maven-toolchains dep of a plugin?
-Stephen
On 5 August 2010 15:25, Jason van Zyl ja...@sonatype.com wrote:
Maybe just decouple it completely from the core if you think it's going to vary
that much.
I would be for completely extracting it.
On Aug 5, 2010, at 10:27 AM, Stephen Connolly wrote:
H
So if I want to add more core toolchains I now have to push the changes to
core, or will the
Or should I just create a new component for to hold toolchains and their
factories... that way if multiple plugins need the same non-core toolchains,
at least there is only one dependency that is needed.
I'm looking at MINVOKER-100 and the supplied patch does not smell good to
me, so I'm thinking
Stephen Connolly wrote:
So if I want to add more core toolchains I now have to push the changes to
core, or will the classloader always take from core and not from a newer
maven-toolchains dep of a plugin?
Not sure what you mean with core toolchain here, at least in M3 you
should be free to
I'll think about that overnight... and perhaps discuss with Benjamin the
implications on IRC tomorrow. If I feel it's better out I'll call a vote
first.
If we are taking it out I'd rather see it removed before 3.0-beta-2.
My thinking is that we remove the org.apache.maven.toolchain.java package
I don't think org.apache.maven.toolchain.java should ever have been in
maven-toolchain, it should have lived in its own artifact.
maven-toolchain was tied to core, and AFAIK the core classloader will always
win in such cases, so the net result is it is not possible to add the extra
methods that
+1
On 8/5/10 10:15 AM, Olivier Lamy wrote:
2010/8/5 Olivier Lamyol...@apache.org:
Hi,
In preparation of the Release Plugin release, I'd like to release Maven Scm 1.4.
Change since first try : fix for SCM-568
We solved 23 issues :
+1
On Thu, Aug 5, 2010 at 19:09, John Casey jdca...@commonjava.org wrote:
+1
On 8/5/10 10:15 AM, Olivier Lamy wrote:
2010/8/5 Olivier Lamyol...@apache.org:
Hi,
In preparation of the Release Plugin release, I'd like to release Maven
Scm 1.4.
Change since first try : fix for SCM-568
We
BTW, Olivier, do you have plans to release maven-scm-provider-svnjava
1.11 after release of Maven SCM 1.4 ?
On Thu, Aug 5, 2010 at 20:03, Evgeny Mandrikov mandri...@gmail.com wrote:
+1
On Thu, Aug 5, 2010 at 19:09, John Casey jdca...@commonjava.org wrote:
+1
On 8/5/10 10:15 AM, Olivier Lamy
Actually it's not an error, but I should have explained it more.
The artifact doxia-tools is just a parent with pom packaging. In the
multi module build there are two artifacts with jar packaging. The first
is doxia-linkcheck and the other is doxia-converter. I should have
included POM snippets
yes sure.
2010/8/5 Evgeny Mandrikov mandri...@gmail.com:
BTW, Olivier, do you have plans to release maven-scm-provider-svnjava
1.11 after release of Maven SCM 1.4 ?
On Thu, Aug 5, 2010 at 20:03, Evgeny Mandrikov mandri...@gmail.com wrote:
+1
On Thu, Aug 5, 2010 at 19:09, John Casey
Hi all
Some very important questions have been asked regarding Jason's
proposal. I usually let my first impressions sink in a bit before I
reply. That often help to make my comments more about the facts and less
about the feelings, and we've seen a lot of feelings in this thread.
The first thing
The first thing I would like to happen is that we release 3.0-beta-2
*without* merging the proposed code. There are two reasons for this.
Lets stage them both, I don't see any harm in having them back to
back, it certainly could help isolate any regressions.
Ok,
Thus talking is good but doing is better ( I know I'm talking more than I'm
doing :-) )
Could we have a consensus if we :
- release now the trunk as a beta 2 without Guice and Aether. With that we'll
have a solid base to compare future changes with. We know it is stable and it
is
+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
yes the goal will be to do more communications on beta-3 than beta-2 to let a
maximum number of users trying it.
If they have any issues due to Ather or Guice we'll be able to ask them to come
back to beta 2 the time we fix issues and deploy the beta-4
On Aug 6, 2010, at 2:09 AM, Mark Derricutt
Arnaud,
I think your plan is sensible. I agree with what you and Dennis have said.
It allows the Maven community to move forward but also doesn't stop
development of the integration.
Paul
2010/8/5 Arnaud Héritier aherit...@gmail.com
Ok,
Thus talking is good but doing is better ( I know I'm
+1
Regards,
Hervé
Le vendredi 06 août 2010, Arnaud Héritier a écrit :
Ok,
Thus talking is good but doing is better ( I know I'm talking more than
I'm doing :-) )
Could we have a consensus if we :
- release now the trunk as a beta 2 without Guice and Aether. With that
we'll have
+1
On 8/5/10 8:04 PM, Arnaud Héritier wrote:
Ok,
Thus talking is good but doing is better ( I know I'm talking more than I'm
doing :-) )
Could we have a consensus if we :
- release now the trunk as a beta 2 without Guice and Aether. With that
we'll have a solid base to compare
Issue Subscription
Filter: Design Best Practices (24 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
+1
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
47 matches
Mail list logo
