I'd like to gradually start migrating some of these to java 1.5. Doing
so will effectively prevent any java 1.4 clients from upgrading.
It's my opinion that this move will effectively be the end of java all
1.4 support. (The surefire fork is the only declared java 1.3/1.4 (!)
support left that I
no objections.
Onward !
2011/6/9 Kristian Rosenvold kristian.rosenv...@gmail.com:
I'd like to gradually start migrating some of these to java 1.5. Doing
so will effectively prevent any java 1.4 clients from upgrading.
It's my opinion that this move will effectively be the end of java all
1.4
Will this affect toolchains from using the older javac and running
tests with older jvms?
toolchains is the recommended way to compile with older java versions
and run tests with older java versions...
I see no reason, as long as toolchains based invoking of older java
versions is not affected,
+1 for dropping java 1.4 support.
Since these projects are technically not ASF ...
Actually I'd go further one step: plexus has been developed to 90% by ASF
committers. So I'd rather go and move plexus over to maven completely while
upgrading to java 1.5 and rewrite/drop parts with uncertain
Hi,
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139styleName=Htmlversion=17146
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11139status=1
Staging repo:
Actually I'd go further one step: plexus has been developed to 90% by ASF
committers. So I'd rather go and move plexus over to maven completely while
upgrading to java 1.5 and rewrite/drop parts with uncertain provenience.
I don't really see the point of all this moving stuff around, are we
Interesting question. I don't know the answer ;)
Are there any formalized test benches (IT's or similar) for the
toolchains stuff ? Easiest thing in the world to just try ;)
Kristian
to., 09.06.2011 kl. 10.41 +0100, skrev Stephen Connolly:
Will this affect toolchains from using the older
Hi there,
according to [1], the build of Indexer with latest changes went fine, but
the deployment to RAO failed with 401. Could someone take a peek and verify
the CI job's settings.xml? I don't have the needed karma it seems...
[1]
Um, rollback this below, next builds just deployed fine. O_o
https://builds.apache.org/view/M-R/view/Maven/job/maven-indexer/9/
Thanks,
~t~
2011/6/9 Tamás Cservenák ta...@cservenak.net
Hi there,
according to [1], the build of Indexer with latest changes went fine, but
the deployment
Hi,
Current 4.1.1 version is mostly bugfix release for latest 4.0.1
improving indexer robustness, lessen unnecessary IO burden and smaller
POM fixes regarding site publishing.
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=17410
There are still a
Sorry, I meant to say Current 4.1.1 version is mostly bugfix release
for latest 4.1.0, NOT 4.0.1.
2011/6/9 Tamás Cservenák ta...@cservenak.net:
Current 4.1.1 version is mostly bugfix release for latest 4.0.1
improving indexer robustness, lessen unnecessary IO burden and smaller
POM fixes
+1
Arnaud
On Thu, Jun 9, 2011 at 12:03 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Hi,
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139styleName=Htmlversion=17146
There are still a couple of issues left in JIRA:
CC'ing dev@: I hope the PMC doesn't mind.
We've been spending some time on-and-off talking about how we can open
up development in the Maven core, and see if we can attract some fresh
minds and ideas. I'd like to copy a list of some things we've been
talking about, and open it up to anyone
Totally agree, onward and upward!
On 6/9/11 5:30 AM, Kristian Rosenvold wrote:
I'd like to gradually start migrating some of these to java 1.5. Doing
so will effectively prevent any java 1.4 clients from upgrading.
It's my opinion that this move will effectively be the end of java all
1.4
On 6/9/11 6:09 AM, Kristian Rosenvold wrote:
It was like
that at codehaus, and it still works that way.
Sorry to display my ignorance, but I haven't done much with the plexus-*
code in awhile...
Other than the container, where is the plexus-compiler stuff now, if not
codehaus? Are we
Hello,
I've only been lurking on the dev@ list for a couple of months, so, some of
these may have already been asked, shot-down, stomped on like a cockroach, etc.
but I've used maven for a couple of years now and wondered I caveat my
requests/suggestions with: These could already be
Stephen Connolly wrote:
Will this affect toolchains from using the older javac and running
tests with older jvms?
toolchains is the recommended way to compile with older java versions
and run tests with older java versions...
I see no reason, as long as toolchains based invoking of older
Why not allow an expanded dialect for the pom files (if it's not already in
progress)? By that I mean open-up the format via some sort of plugin
mechanism or core support so pom files could be written in other languages
aside from XML. Perhaps something like JSON? I'm no JSON expert, but it
Looks interesting... I didn't want to work any more this afternoon anyway. ;)
On Jun 9, 2011, at 2:34 PM, Anders Hammar wrote:
Why not allow an expanded dialect for the pom files (if it's not already in
progress)? By that I mean open-up the format via some sort of plugin
mechanism or core
On Thu, Jun 9, 2011 at 6:32 PM, John Casey jdca...@commonjava.org wrote:
On 6/9/11 6:09 AM, Kristian Rosenvold wrote:
It was like
that at codehaus, and it still works that way.
Sorry to display my ignorance, but I haven't done much with the plexus-*
code in awhile...
Other than the
Yeah, I thought that's what we were talking about...so, if you clone the
git repo, the commit bit you're talking about is for pulling those
changes back to the sonatype clone, right?
Not to be a pain, but who's saying sonatype's the ultimate authority on
plexus?
On 6/9/11 2:57 PM, Arnaud
Pushing to master-git and pushing releases. All the license headers and
GAV's are still codehaus.
Kristian
to., 09.06.2011 kl. 15.15 -0400, skrev John Casey:
Yeah, I thought that's what we were talking about...so, if you clone the
git repo, the commit bit you're talking about is for
2011/6/9 John Casey jdca...@commonjava.org:
CC'ing dev@: I hope the PMC doesn't mind.
We've been spending some time on-and-off talking about how we can open up
development in the Maven core, and see if we can attract some fresh minds
and ideas. I'd like to copy a list of some things we've
+1
On Thu, Jun 9, 2011 at 12:03 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Hi,
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139styleName=Htmlversion=17146
There are still a couple of issues left in JIRA:
Hi guys,
I just accidentally and quickly had a look at the thread (got
interested because saw Olivier in :P) and since I'm interested on
contributing - and have been playing with @Inject Guice extensions
for a while[1][2][3][4][5] - I could provide my help.
My BIG issue is I don't know Maven core
FYI Simone, our sandbox is supposed to be open for all _APACHE_
committers, so if you want to work on stuff you can just fork what you
are working on into the sandbox to show us your skills of a hacker
rather than having to live in patch land
On 9 June 2011 22:17, Simone Tripodi
Thanks a lot Stephen!!!
As I previously wrote before, my main issue is that even I'm quiet
familiar with maven and basic APIs (I can develop plugins) I don't
know how internals work, if you have something to share I can read to
get more confident I would really appreciate it, then I'll request of
I'd like to offer a small suggestion.
One of the big barriers to maven happiness is the difficulty of
understanding, in some cases, why it does what it does.
This suggests to me three efforts that might offer an opportunity to
learn core code without drowning.
1: take up slf4j, and thus allow
Non-binding +1; no apparent problems in NetBeans integration during basic
interactive tests.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
+1
LieGrue,
strub
--- On Thu, 6/9/11, Kristian Rosenvold kristian.rosenv...@gmail.com wrote:
From: Kristian Rosenvold kristian.rosenv...@gmail.com
Subject: Re: [VOTE] Release Maven Plugin Tools Version 2.8
To: Maven Developers List dev@maven.apache.org
Date: Thursday, June 9, 2011, 9:02 PM
On Fri, Jun 10, 2011 at 6:56 AM, Simone Tripodi
simonetrip...@apache.org wrote:
I don't know how internals work, if you have something to share I can read to
get more confident I would really appreciate it
I think that's the nub of the problem for a lot of people.
We can hack a plugin but we
Simone, can you please do one favour for me...
Can you please try
svn mkdir https://svn.apache.org/repos/asf/maven/sandbox/trunk/simone-test
-m a test of sandbox access by a non-maven committer
and if that works then
svn rm https://svn.apache.org/repos/asf/maven/sandbox/trunk/simone-test
-m
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: Friday, 10 June 2011 10:12 AM
To: Maven Developers List
Subject: Re: Get thee to the Core...
Simone, can you please do one favour for me...
Can you please try
svn mkdir
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
On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote:
I'd like to offer a small suggestion.
One of the big barriers to maven happiness is the difficulty of
understanding, in some cases, why it does what it does.
This suggests to me three efforts that might offer an opportunity to
learn
35 matches
Mail list logo
