My bad - you can close this. Call it late night blindness after a long day.
I hadn't noticed that the Hudson build server/maven builds had already
moved to generating 3.0.4-SNAPSHOTs so my update script failed to download,
then made a bogus symlink making OSX fall back on the system version ( 2.2
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 wrote:
> I posted a debug output of release:prepare with the current nightly:
>
> https://gist.g
I posted a debug output of release:prepare with the current nightly:
https://gist.github.com/082ac46dcbe0160e9ae4
This release:prepare works fine un 2.0.2, looks like something regressed
recently in version range resolution.
--
"Great artists are extremely selfish and arrogant things" — Steven
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
Mark Derricutt wrote:
I note today's nightly breaks in the release plugin with a "null" version
reference in upstream artifacts which seems like a regression to a problem I
had back before 3.0 first came out.
A test case or even the actual log would be highly appreciated.
Is there a release
I note today's nightly breaks in the release plugin with a "null" version
reference in upstream artifacts which seems like a regression to a problem I
had back before 3.0 first came out.
Is there a release branch or are releases being made from trunk?
For reference, I'm downloading:
wget --no-ch
Jesse Glick wrote:
Cleaner would have been to introduce ArtifactRepositoryLayout3 (?) with
the getId() method; then a simple instanceof check would suffice.
No, I want any plugin moving forward to compile against mvn 3.x libs to
get a compile error and eventually implement the method themselv
On 02/28/2011 07:09 AM, Benjamin Bentmann wrote:
Fixed in trunk by now.
Rev 1075309, which seems to be included in 3.0.3 final. Suggestion for
tightening up RepositoryUtils.getLayout a bit:
1. Call repo.getLayout() outside the try block, since that is not expected to
give an error. It is use
Brett Porter wrote:
Same problem building Archiva trunk (in archiva-jetty) if you want a test
project to look at.
Thanks, that did the trick. Fixed in trunk by now.
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.
On 27 February 2011 23:12, Brett Porter wrote:
> wifi is flaky so I won't make it through JIRA, but here's the trace from
> Archiva if it helps. It looks due to an API change, as the appassembler
> plugin declares it's own repository type.
>
ah, looks like http://jira.codehaus.org/browse/MNG-496
wifi is flaky so I won't make it through JIRA, but here's the trace from
Archiva if it helps. It looks due to an API change, as the appassembler plugin
declares it's own repository type.
[INFO] --- appassembler-maven-plugin:1.0:create-repository (default) @
archiva-jetty ---
[DEBUG] Configurin
Same problem building Archiva trunk (in archiva-jetty) if you want a test
project to look at. I don't have a checkout of appassembler with me to check if
it has an integration test that might exhibit this for you as well.
Cheers,
Brett
On 28/02/2011, at 9:02 AM, Dennis Lundberg wrote:
> On 201
On 27 February 2011 22:02, Dennis Lundberg wrote:
> On 2011-02-24 22:57, Benjamin Bentmann wrote:
> > Hi,
> >
> > we're aiming at a bugfix release of Maven 3 in the next week and
> > following tradition we invite interested users in taking the RC for a
> > test drive in order to detect and fix po
On 2011-02-24 22:57, Benjamin Bentmann wrote:
> Hi,
>
> we're aiming at a bugfix release of Maven 3 in the next week and
> following tradition we invite interested users in taking the RC for a
> test drive in order to detect and fix potential regressions since
> version 3.0.2 before the actual rel
There seems to be a regression in the jboss as build [1]. Not sure what
the cause is, but the new Maven RC seems to have a problem during
execution of our custom surefire impl. I created a jira issue [2] to
track this and attached the relevant part of the build log.
[1]https://github.com/jbossas
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
> Tested without pr
Tested without problem on a large set of ours projects.
cheers
Arnaud
On Sat, Feb 26, 2011 at 4:04 PM, Stuart McCulloch wrote:
> On 26 February 2011 15:56, Anders Hammar wrote:
>
> > I'm noticing a lower memory usage (compared to v3.0.2) when building the
> > Cargo project (trunk), but can't
On 26 February 2011 15:56, Anders Hammar wrote:
> I'm noticing a lower memory usage (compared to v3.0.2) when building the
> Cargo project (trunk), but can't find a jira ticket that would explain
> this.
> Is this expected (not that I'm complaining)?
>
There were some improvements to the IoC con
I'm noticing a lower memory usage (compared to v3.0.2) when building the
Cargo project (trunk), but can't find a jira ticket that would explain this.
Is this expected (not that I'm complaining)?
All plugin versions are pinned and this is a clean build. I tested it
several times, and the same result
Hi,
tested my projects (https://github.com/khmarbaise/supose,
https://github.com/khmarbaise/sapm etc.) with 3.0.3-RC1 and no problems
found.
mac:target km$ mvn --version
Apache Maven 3.0.3-RC1 (r1074308; 2011-02-24 22:41:17+0100)
Maven home: /usr/share/maven
Java version: 1.6.0_22, vendor: App
Hi,
we're aiming at a bugfix release of Maven 3 in the next week and
following tradition we invite interested users in taking the RC for a
test drive in order to detect and fix potential regressions since
version 3.0.2 before the actual release of 3.0.3.
For the duration of the RC testing, sourc
21 matches
Mail list logo
