Is there any reason that the 2.1 branch cannot require java
1.5 to compile and execute?
I am not a developer on Maven, so my vote would not count anyway. I am
an independent IT consultant and want to offer some background
information why this would be a bad decision.
During my work for the
I don't think this is surprising, however I think targeting JDK 1.4
but being able to run Java 5 is going to be common in this scenario
(consider most IDEs require JRE 5.0 now), and for those who can't even
do that, then they still have the option of using Maven 2.0.x, or
contributing
De Smet Ringo wrote:
Is there any reason that the 2.1 branch cannot require java
1.5 to compile and execute?
I am not a developer on Maven, so my vote would not count anyway. I am
an independent IT consultant and want to offer some background
information why this would be a bad
My target environment is Java 1.3, so I have a more critical requirement
than you as I simply can't run maven2 with the target env. This is not an
issue in any case as I have Java6 as a JDK and a JRE 1.3 for tests. I simply
set the source,target and bootclasspath options of the compiler plugin to
Please also consider Java 1.4 will start the end-of-life process in
october...
2008/8/18 Ralph Goers [EMAIL PROTECTED]
De Smet Ringo wrote:
Is there any reason that the 2.1 branch cannot require java 1.5 to compile
and execute?
I am not a developer on Maven, so my vote would not count
Brett Porter wrote:
I don't think this is surprising, however I think targeting JDK 1.4
but being able to run Java 5 is going to be common in this scenario
(consider most IDEs require JRE 5.0 now), and for those who can't even
do that, then they still have the option of using Maven 2.0.x,
clearly a (nonbinding)
+1
since it's really a pita to not have generics support.
This would also allow to use Shawn's Java native JGit Implementation for the
git provider.
LieGrü,
strub
--- Jason van Zyl [EMAIL PROTECTED] schrieb am So, 17.8.2008:
Von: Jason van Zyl [EMAIL PROTECTED]
Is there any reason that the 2.1 branch cannot require java 1.5 to
compile and execute?
Ralph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1
Arnaud HERITIER wrote:
+1
Arnaud
On Sun, Aug 17, 2008 at 11:33 PM, Brett Porter [EMAIL PROTECTED] wrote:
+1D
On 17/08/2008, at 6:27 PM, Ralph Goers wrote:
Is there any reason that the 2.1 branch cannot require java 1.5 to compile
and execute?
Ralph
Ping!
2008/8/14 Vincent Siveton [EMAIL PROTECTED]:
Hi,
This is mainly a bug fix release.
We solved around 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14442styleName=HtmlprojectId=11139
There are still a couple of issues left in JIRA:
Didn't see it. sorry
+1
Arnaud
On Mon, Aug 18, 2008 at 4:24 PM, Vincent Siveton [EMAIL PROTECTED]wrote:
Ping!
2008/8/14 Vincent Siveton [EMAIL PROTECTED]:
Hi,
This is mainly a bug fix release.
We solved around 10 issues:
Hi John,
no problems encountered so far on all projects tested. Thanks for
excellent work!
Cheers
John Casey wrote:
Hi,
As you've undoubtedly noticed, the RC7 distro didn't last very long
before a nasty bug showed up...actually two, but they were related.
At any rate, they're fixed,
Wendy Smoak wrote:
On Sat, Aug 16, 2008 at 1:09 AM, Benjamin Bentmann
[EMAIL PROTECTED] wrote:
do we have an agreed naming convention for plugin goals? E.g.
reactor:makeMyChanges
and
dependency:purge-local-repository
obviously follow different rules. Having one naming style would ease
At the suggestion of others I've renamed the makeMyChanges goal to
makeScmChanges. This clarifies the purpose of the goal a bit more.
What I'd like to do now, if folks are interested, is pursue this problem
along two tracks.
1) release maven-reactor-plugin: begin the process of getting it
Just for the record this discussion of naming has popped up on the
ruby and perl lists over the years.
Camel case naming which is what's generally used in Java is hard for
non-english speakers to grok.
this-is-easier-to-read then thisIsEasierToRead.
Just another data point.
On 18-Aug-08,
Brett Porter wrote:
I would say the first one. The first goal I could think of to have this
was testCompile, so it probably set the precedent.
While it might have been the first goal, it's apparently not today's
common case. Browsing through the Apache plugins, I found only
-
I've implemented the solution to the problem - please see Solution to
the above problem - Quality Range in the http://docs.codehaus.org/x/twDPBQ
The solution turned to be a very nice feature to also use in the
Repository, I am exploring that option, please keep an eye on
Hi Oleg,
This is great stuff. I've wanted quality ranges for a long time. What's the
best way to jump on to the thread here? Respond to the dev list or add a
comment to the codehaus discussion?
BTW, are you still at Linked In?
Thanks,
Gil
-Original Message-
From: Oleg Gusakov
Woops, sorry all. I meant to send this just to Oleg.
Still good work though.
-Original Message-
From: Clark, Gil W. [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 10:22 AM
To: Maven Developers List
Subject: RE: Mercury Version Ranges
Hi Oleg,
This is great stuff. I've
That's interesting, and makes me want to vote for dashes going forward.
(I'll admit that I was thinking of testCompile when I wrote my plugin, to
the extent that I was thinking of anything at all.)
For the record, the offending camelCase goals are:
compiler:testCompile
resources:testResources
Subclassing and calling the other mojo is the only way to alias. I did
this on dependency:list (alias to resolve).
I think the non-cameltoe is the more prolific defacto standard
-Original Message-
From: Dan Fabulich [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 11:15 AM
To:
Hi everyone,
I just wanted to point you to the message I sent to users@ telling
people they should go try 2.0.10-RC9. This release candidate
incorporates the fixes for the final two issues from RC8, and looks like
it's our best chance so far for getting the actual release done.
Please take
John,
The performance issue is back:
For CXF/tunk:
mvn install -Pdeploy,everything,nochecks
2.0.9:
Total time: 8 minutes 35 seconds
2.0.10-RC9:
Total time: 19 minutes
Dan
On Monday 18 August 2008 2:48:36 pm John Casey wrote:
Hi everyone,
As you're probably aware, we've been working for
What I'm starting to notice on this end is that it uses a bit more
memory - probably in the middle of the build - than 2.0.9. This is
evident in the max VM size at the end of the build, more than the final
memory consumption. It seems that leaving the maven build at the default
64M VM size, it
Ralph Goers wrote:
Ralph Goers wrote:
Shane Isbell wrote:
I've been refactoring more of the project builder code and
encountered a
rule that if a dependencyManagement/dependencies/dependency element has
type=pom and scope=import, the dependency management section of that
dependency
I'm seeing the same problem - the build is dying much earlier. For
Archiva, this is in archiva-database, while 2.0.9 died in archiva-
webapp.
RC6 was the last version to get the whole way through, so it looks
like a change in RC7.
Cheers,
Brett
On 19/08/2008, at 12:07 PM, John Casey
Just another quick note...
Our -Pfastinstall profile (to build/install as fast as possible)
2.0.9:
[INFO] Total time: 32 seconds
[INFO] Finished at: Mon Aug 18 21:51:07 EDT 2008
[INFO] Final Memory: 53M/94M
2.0.10-RC9:
[INFO] Total time: 4 minutes 39 seconds
[INFO] Finished at: Mon Aug 18
Hi,
At the suggestion of others I've renamed the makeMyChanges goal to
makeScmChanges. This clarifies the purpose of the goal a bit more.
First of all, thanks for your work on this plugin...it really eases the
pain ;) As far as i know, no other plugin uses camel-case goal names.
Wouldn't it
28 matches
Mail list logo
