I am still running RC8, but a very weird discovery occurred to my
project. I checked out a full project from SVN and ran eclipse:eclipse
on a subfolder at the command line. I got a folder named
"${project.basedir}". Is it an interpolation bug? Can someone try to
reproduce?
This isn't a one time th
I recommended #1 a couple weeks back, and also asked if any of this
could be caused by StringBuffer's synchronization? I didn't get any
reply. My theory was that if alot of String ops we're going on, you
might want to figure out how to cut those out... even figure out how
to end up using StringBuil
Honestly I half feel like flushing the fixes for all of this to 2.1 and
leaving it as is in 2.0.x.
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2008 10:06 PM
To: dev@maven.apache.org
Subject: Re: 2.0.10 performance.
Well, ideally to me,
Well, ideally to me, we'd just pursue option #2 and push that through. The
problem is that doing so would delay 2.0.10 even further as that would
require another plugin-tools release (which was just released today), etc
Thus, the question is, what to do to get 2.0.10 out? The command l
I like both of those ideas.
My concern since we saw the performance issues was that it was affecting
everyone to fix just a few cases. If it could be off by default it would
be better, but setting a cli flag for this isn't a great use case...then
there's no way to specify it for people who wouldn't
The latest stuff on John's branch is "better", but it's still about 4x - 5x
slower for some of the actions I do several times a day. I'd estimate that
I'd end up wasting 20-30 minutes a day waiting for it compared to 2.0.9. I
find that unacceptable and wouldn't be able to recommend it get ro
Hi everyone.
Is maven-xcode-plugin being worked on? Traffic about it seem to tail
off after the 'it's in sandbox' announcement.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Michael McCallum wrote:
On Thu, 21 Aug 2008 10:47:04 Oleg Gusakov wrote:
I'm confused... you are distriguishing between local and remote repositories
when you've just abstracted the concept into a virtual reader... why?
This is more implementation details, for user it's hidden by virtual
Reverted back and implemented as Jason indicated in his reply. Changes
reflected in documentation.
LATEST was intended to refer to the latest regardless of whether it
was a snapshot or release. RELEASE is the latest non-snapshot.
Michael McCallum wrote:
On Thu, 21 Aug 2008 10:47:04 Oleg Gusak
On Thu, 21 Aug 2008 10:47:04 Oleg Gusakov wrote:
> I cannot find use cases where asking for g:a:LATEST is different from
> g:a:RELEASE, so I merge these two in Mercury.
>
Doesn't this just make people lazy and not think about what they are doing...
if they want an open range [1,) then let them spe
The use case was for plugins (to have snapshots so you grab the ones
you are developing).
We're way better off requiring you ask for that somewhere, so I think
LATEST can go. I'd consider if RELEASE is even needed if you can use
ranges for it effectively.
- Brett
On 21/08/2008, at 9:13 A
On Thu, 21 Aug 2008 10:47:04 Oleg Gusakov wrote:
> I cannot find use cases where asking for g:a:LATEST is different from
> g:a:RELEASE, so I merge these two in Mercury.
>
> Please comment in
> http://docs.codehaus.org/display/MAVEN/Mercury+Repository+Abstraction#Mercu
>ryRepositoryAbstraction-Artif
The requested changes documented on the same page.
Please feel free to comment there if there are any other special
versions we'd like to see.
Jason van Zyl wrote:
LATEST was intended to refer to the latest regardless of whether it
was a snapshot or release. RELEASE is the latest non-snapshot
I did not find RELEASE.
Thanks for the clarification, I will document implement the meanings
described.
Oleg
Jason van Zyl wrote:
LATEST was intended to refer to the latest regardless of whether it
was a snapshot or release. RELEASE is the latest non-snapshot.
You found no evidence of that
LATEST was intended to refer to the latest regardless of whether it
was a snapshot or release. RELEASE is the latest non-snapshot.
You found no evidence of that being used?
On 20-Aug-08, at 3:47 PM, Oleg Gusakov wrote:
I cannot find use cases where asking for g:a:LATEST is different
from g:
I cannot find use cases where asking for g:a:LATEST is different from
g:a:RELEASE, so I merge these two in Mercury.
Please comment in
http://docs.codehaus.org/display/MAVEN/Mercury+Repository+Abstraction#MercuryRepositoryAbstraction-ArtifactVersionsspecialtreatment
---
To kick off a glorious new era of core features, I've checked in a first
attempt at adding a "make-like" mode to Maven. Basically it's just an
attempt to port maven-reactor-plugin into the core, described in more
detail here:
http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode
Ne
I got the speed issue reduced to where it's adding something less than a
minute on the site build for maven (that's including clean; since we
can't reliably tell which plugins are smart enough to avoid
re-execution, I considered it simpler to start clean each time). I was
able to do this by writin
On Mon, 18 Aug 2008, John Casey wrote:
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
Barrie Treloar wrote:
My machine crashes and reboots.
Have you already tried different JDKs? It looks very odd to me that a
*virtual* machine crashes the entire host box.
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTE
The vote has passed with the following votes:
+1 Arnaud, Olivier, Lukas, Vincent
I'll move the artifacts over.
Cheers,
Vincent
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
Hi Sebastian,
I will restart the release process this week since UTF-8 is now the
default encoding and MJAVADOC-212 was fixed.
Cheers,
Vincent
2008/8/20 Sebastian Annies <[EMAIL PROTECTED]>:
> Hi,
>
> what is the current problem that prevents releasing the
> maven-javadoc-plugin 2.5?
> Is there
Hi,
what is the current problem that prevents releasing the
maven-javadoc-plugin 2.5?
Is there anything I can do?
Is it more than some SNAPSHOT dependencies?
Is there still a feature discussion going on?
Best Regards,
Sebastian
--
Hi Jason,
To have gmaven archetypes in the internal catalog, please add the
archetypes to the list (on mavenuser's confluence)
It will be taken into account on the next release, as i take care of
generating the internal catalog from this list before any release.
Meanwhile, you can create a catalo
24 matches
Mail list logo