Hello,
I'm Moritz from the Spring Boot team.
I tried Maven 4.0.0-RC1 with a project which is a library for Spring Boot.
For this, I have to import the spring-boot-dependencies BOM with a scope
import in the dependency management section to align to the versions used
in Spring Boot.
W
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/155
@Tibor17 I'll have a look at the state of the junit5 branch next week.
Thank you!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as we
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/155
@britter
#155 and #154 are done. Pls let me know if I should continue with #153.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/155
@Tibor17 I'd say this order:
- #155: revert stuff from rc1 branch
- #154: Add the stuff to junit5 branch
#153 I have to rework, since we have to target it at j
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/155
@britter
In what order should this PR and
https://github.com/apache/maven-surefire/pull/153 be pushed?
Is https://github.com/apache/maven-surefire/pull/154 independent?
---
If your
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/155
@britter
We have finished feature SUREFIRE 1302 and I am going get back to JUnit5.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>>>>>> at
>>>>>>
>>>>>>
>>>>>>
>>>>>> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory
.1-SNAPSHOT
[1]
https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies
--
Cheers
Tibor
--
If you reply to this email, your message will be added to the
discussion
below:
http://maven.40175.n5.nabble.com/migrating-Surefire-t
pat contains classes which Maven2 classes which have been replaced
>>>>> by
>>>>> Maven3 or are not used anymore.
>>>>> Only plugins which need to stay compatible with Maven2 should include
>>>>> this
>>>>> dependency.
&g
Hi Robert,
I fixed the transitive artifact resolution. See the branch 3.0-rc1.
The only remaining to fix is Java packages relocation of *-shared artifacts
in maven-surefire-common.
Cheers
Tibor
On Sun, Jan 17, 2016 at 8:09 PM, Tibor Digana
wrote:
> I used transformer
>
>
>im
>>>>>>
>>>>>>
>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>> at
>>>>>>
>>>>>>
>>>>>>
>>>>>> sun.reflect.DelegatingM
gration+to+Maven3+dependencies
--
Cheers
Tibor
--
If you reply to this email, your message will be added to the
discussion
below:
http://maven.40175.n5.nabble.com/migrating-Surefire-to-3-0-RC1-tp5858124.html
To start a new topic under Maven Developers, email
ml-node+
or are not used anymore.
>>>>> Only plugins which need to stay compatible with Maven2 should include
>>>>> this
>>>>> dependency.
>>>>>
>>>>> I'll update the page, because we've decided to change the version to
&g
Hi Robert and devs,
I fixed artifact resolution issues we spoke about last time, see the branch
3.0-rc1, you may now have a look in surefire project.
but there is the last issue. I should exclude org
.apache.maven.shared.artifact.resolve.ArtifactResolverException
from reallocation in maven-shade
the
discussion
below:
http://maven.40175.n5.nabble.com/migrating-Surefire-to-3-0-RC1-tp5858124.html
To start a new topic under Maven Developers, email
ml-node+s40175n142166...@n5.nabble.com
To unsubscribe from Maven Developers, click here
<
http://maven.40175.n5.nabble.c
; >
> > > >
> > >
> >
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> >
> > > > > >> at
> > > > > >>
> > > > > >>
> > > > >
gt; > > > >> at
> > java.util.Collections$EmptyIterator.next(Collections.java:4189)
> > > > >> at
> > > > >>
> > > > >>
> > > >
> > >
> >
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:249)
>
> &
gt; On Thu, Jan 7, 2016 at 6:10 PM, Robert Scholte <
> rfscho...@apache.org>
> > > >> wrote:
> > > >>
> > > >> Hi Tibor,
> > > >>>
> > > >>> so this is not how it should be done.
> > > >>> C
ld include
> > >>> this
> > >>> dependency.
> > >>>
> > >>> I'll update the page, because we've decided to change the version to
> > >>> 3.0-SNAPSHOT
> > >>>
> > >>> And regarding y
t; > >>> this
> > >>> dependency.
> > >>>
> > >>> I'll update the page, because we've decided to change the version to
> > >>> 3.0-SNAPSHOT
> > >>>
> > >>> And regarding your other message: see the third bullet when
gt;>> migration issues :)
> >>>
> >>> thanks,
> >>> Robert
> >>>
> >>> Op Thu, 07 Jan 2016 00:50:10 +0100 schreef Tibor Digana <
> >>> tibordig...@apache.org>:
> >>>
> >>> P=NP
> >>
t;>>
>>>>
>>>>
>>>>
>>>> On Thu, Jan 7, 2016 at 12:09 AM, Tibor Digana-2 [via Maven] <
>>>> ml-node+s40175n5858124...@n5.nabble.com> wrote:
>>>>
>>>> I missing this import in MOJO after migrating
discussion
below:
http://maven.40175.n5.nabble.com/migrating-Surefire-to-3-0-RC1-tp5858124.html
To start a new topic under Maven Developers, email
ml-node+s40175n142166...@n5.nabble.com
To unsubscribe from Maven Developers, click here
<
http://maven.40175.n5.nabble.com/template/NamlSer
HOT
[1]
https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies
--
Cheers
Tibor
--
If you reply to this email, your message will be added to the discussion
below:
http://maven.40175.n5.nabble.com/migrating-Surefire-to-3-0-RC1-tp58581
i.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies
>
> --
> Cheers
> Tibor
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://maven.40175.n5.nabble.com/migrati
I missing this import in MOJO after migrating plugin to 3.0
import org.apache.maven.shared.artifact.resolve.ArtifactResolver;
The doc [1] says that maven-artifact-transfer should be used but it does
not have yet a release version, or?
org.apache.maven.shared
maven-artifact-transfer
0.0.1
Wed, Mar 28, 2012 at 11:51 AM, Emmanuel Venisse
wrote:
> +1
>
> Emmanuel
>
> On Tue, Mar 27, 2012 at 10:01 AM, Simone Tripodi
> wrote:
>
>> Hi all guys,
>> I'm opening a thread vote today for releasing Apache Maven Fluido Skin
>> 1.2.1, based
+1
Emmanuel
On Tue, Mar 27, 2012 at 10:01 AM, Simone Tripodi
wrote:
> Hi all guys,
> I'm opening a thread vote today for releasing Apache Maven Fluido Skin
> 1.2.1, based on RC1
>
> We solved 3 issues:
>
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11
ue is really too much, but annoying
>
> Regards,
>
> Hervé
>
> Le mardi 27 mars 2012 10:01:16 Simone Tripodi a écrit :
>> Hi all guys,
>> I'm opening a thread vote today for releasing Apache Maven Fluido Skin
>> 1.2.1, based on RC1
>>
>> We solved
pache Maven Fluido Skin
> 1.2.1, based on RC1
>
> We solved 3 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=
> Html&version=18380
>
> where [MSKINS-38] is the major issue that drove the new RC
>
> There are thre
Hi Jesse!!
Breadcrumbs usually are defined inside the element in
site.xml: in the case of the fluido skin site, they are defined in the
skin parent site descriptor[1] that are merged with the ones of maven
parent and then inherited via . A little complex
chain.
Anyway, if you need to define brea
Maven Fluido Skin
1.2.1, based on RC1
oh yeah :)
+1 non binding
thanks,
tony.
We solved 3 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&version=18380
where [MSKINS-38] is the major issue that drove the new RC
There are three new issues in JI
Greetings,
On Tue, Mar 27, 2012 at 4:01 AM, Simone Tripodi
wrote:
> Staging repo:
> https://repository.apache.org/content/repositories/maven-118/
I'm using topbar and sidebar basic menus, but I'm not seeing any bread
crumbs being created in the little area underneath the left and right
nav areas
On Tue, 27 Mar 2012 10:01:16 +0200
Simone Tripodi wrote:
> Hi all guys,
> I'm opening a thread vote today for releasing Apache Maven Fluido Skin
> 1.2.1, based on RC1
oh yeah :)
+1 non binding
thanks,
tony.
>
> We solved 3 issues:
> https://jira.codehaus.org/
+1
2012/3/27 Simone Tripodi :
> Hi all guys,
> I'm opening a thread vote today for releasing Apache Maven Fluido Skin
> 1.2.1, based on RC1
>
> We solved 3 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&version=18380
>
Hi all guys,
I'm opening a thread vote today for releasing Apache Maven Fluido Skin
1.2.1, based on RC1
We solved 3 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&version=18380
where [MSKINS-38] is the major issue that drove the new RC
Th
t;Maven Developers List"
> Objet : [VOTE] Release Apache Maven Fluido Skin 1.2 based on RC1
> Date : lun., mars 19, 2012 11:18
>
>
> Hi all guys,
> I'm opening a thread vote today for releasing Apache Maven Fluido Skin
> 1.2, based on RC1
>
> We solved 7 issues:
>
+1
Envoyé depuis mon mobile
- Reply message -
De : "Simone Tripodi"
Pour : "Maven Developers List"
Objet : [VOTE] Release Apache Maven Fluido Skin 1.2 based on RC1
Date : lun., mars 19, 2012 11:18
Hi all guys,
I'm opening a thread vote today for releasing Apa
+1
2012/3/19 Simone Tripodi :
> Hi all guys,
> I'm opening a thread vote today for releasing Apache Maven Fluido Skin
> 1.2, based on RC1
>
> We solved 7 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&version=18296
>
&g
+1
On 19 March 2012 10:18, Simone Tripodi wrote:
> Hi all guys,
> I'm opening a thread vote today for releasing Apache Maven Fluido Skin
> 1.2, based on RC1
>
> We solved 7 issues:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&
On Mon, 19 Mar 2012 11:18:57 +0100
Simone Tripodi wrote:
> Hi all guys,
> I'm opening a thread vote today for releasing Apache Maven Fluido Skin
> 1.2, based on RC1
+1 (non binding)
Thanks ,
Tony
-
To unsub
+1
-Robert
Op Mon, 19 Mar 2012 11:48:43 +0100 schreef Emmanuel Venisse
:
+1
Emmanuel
On Mon, Mar 19, 2012 at 11:18 AM, Simone Tripodi
wrote:
Hi all guys,
I'm opening a thread vote today for releasing Apache Maven Fluido Skin
1.2, based on RC1
We solved 7 issues:
+1
Emmanuel
On Mon, Mar 19, 2012 at 11:18 AM, Simone Tripodi
wrote:
> Hi all guys,
> I'm opening a thread vote today for releasing Apache Maven Fluido Skin
> 1.2, based on RC1
>
> We solved 7 issues:
>
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11
Hi all guys,
I'm opening a thread vote today for releasing Apache Maven Fluido Skin
1.2, based on RC1
We solved 7 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&version=18296
There are still a couple of issues left in JIRA:
http://jira
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
tory/stax/stax-api/1.0.1/stax-api-1.0.1.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import from realm
> ClassRealm[project>se.dennislundberg:dennislundberg-beansprout:3.1-SNAPSHOT,
> parent: ClassRealm[maven.api, parent: null]]]
>
>>
>>
-
Thanks, Stuart
>
> > For the duration of the RC testing, sources and binaries are staged at:
> >
> https://repository.apache.org/content/repositories/maven-049/org/apache/maven/apache-maven/3.0.3-RC1/
> >
undberg-beansprout:3.1-SNAPSHOT,
parent: ClassRealm[maven.api, parent: null]]]
>
> For the duration of the RC testing, sources and binaries are staged at:
> https://repository.apache.org/content/repositories/maven-049/org/apache/maven/apache-maven/3.0.3-RC1/
>
>
> As usual,
er 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, sources and binaries are staged at:
> https://repository.apache.org/content/repositories/maven-049/org/apache/maven/apache-maven/3.0.3-RC1/
>
&
you could try
> swapping
> > it around
> > (sisu-guice, sisu-inject-bean, and sisu-inject-plexus) to see if it makes
> > any difference...
> >
> >
> > > All plugin versions are pinned and this is a clean build. I tested it
> > > several times, and the
ject-plexus) to see if it makes
> any difference...
>
>
> > All plugin versions are pinned and this is a clean build. I tested it
> > several times, and the same result.
> >
> > With Maven 3.0.2: 79M/265M
> > With Maven 3.0.3-RC1: Final Memory: 60M/265M
> &g
e some improvements to the IoC container - you could try swapping
it around
(sisu-guice, sisu-inject-bean, and sisu-inject-plexus) to see if it makes
any difference...
> All plugin versions are pinned and this is a clean build. I tested it
> several times, and the same result.
>
> With Ma
s, and the same result.
With Maven 3.0.2: 79M/265M
With Maven 3.0.3-RC1: Final Memory: 60M/265M
The build time seems to be slightly longer though. Not that much, just a few
(5-10) secs on a 5+ min build.
mvn -v:
Apache Maven 3.0.3-RC1 (r1074308; 2011-02-24 22:41:17+0100)
Maven home: /usr/local/mav
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
sting, sources and binaries are staged at:
https://repository.apache.org/content/repositories/maven-049/org/apache/maven/apache-maven/3.0.3-RC1/
As usual, the changes since the previous release are listed in JIRA:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=17061
Thank
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.1 before the actual release of 3.0.2.
Work
So... about the double slashes issue SCM-581...
I've opened a MNG-issue that contains a simplistic patch and a fix for the
relevant test case too. The fix might be a bit invasive as it affects all
url:s, not only the scm connection url. The alternative is perhaps to have a
separate UrlNormalizer s
In <6245a072-ee21-4b6a-87cf-1ce84ea4e...@apache.org> Brett Porter wrote:
> > http://jira.codehaus.org/browse/SCM-581
> It isn't clear from the issue whether this is in the SCM provider (which is
> independent of Maven releases), or in Maven (in which case this is filed in
> the wrong place).
R
/2011, at 1:06 AM, Fredrik Jonson wrote:
> Hello,
>
> I understand if this is strictly not a concern or blocker for a release of
> maven itself, but SCM-581 is still blocking a upgrade from 2.2.1 to 3.x
> including 3.0.2-RC1 for anyone using mercurial (hg) as SCM and absolute paths
Fredrik Jonson wrote:
Any chance to get a fix for that included in 3.0.2?
Unlikely.
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Hello,
I understand if this is strictly not a concern or blocker for a release of
maven itself, but SCM-581 is still blocking a upgrade from 2.2.1 to 3.x
including 3.0.2-RC1 for anyone using mercurial (hg) as SCM and absolute paths
on a remote server with the maven release plugin.
http
Hi,
Works fine for all Sonar projects, including builds with Tycho.
On Fri, Jan 7, 2011 at 01:32, John Casey wrote:
> I should mention that this is a problem I have verified is still present in
> 3.0.2-RC1, but it's also happening in all the 3.x releases.
>
> Maven 2.2.1 works
I should mention that this is a problem I have verified is still present
in 3.0.2-RC1, but it's also happening in all the 3.x releases.
Maven 2.2.1 works fine.
On 1/6/11 5:30 PM, John Casey wrote:
I'm having a problem with the release plugin, BOMs in the reactor, and
Maven 3
and fix potential regressions since
version 3.0.1 before the actual release of 3.0.2.
For the duration of the RC testing, sources and binaries are staged at:
https://repository.apache.org/content/repositories/maven-006/org/apache/maven/apache-maven/3.0.2-RC1/
As usual, the changes since the previo
est drive in
> order to detect and fix potential regressions since version 3.0.1 before the
> actual release of 3.0.2.
>
> For the duration of the RC testing, sources and binaries are staged at:
>
> https://repository.apache.org/content/repositories/maven-006/org/apache/maven/apache-m
Hi,
I test m3 3.0.2-RC1 and maybe it's regression :
[WARNING] The metadata
/Users/carpentierxqvier/.m2/repository/com/greenivory/redmole/client/commons/com.greenivory.redmole.client.commons/2.3.0-SNAPSHOT/maven-metadata-local.xml
is invalid: Snapshot information corrupted with r
er to detect and fix potential regressions since
> version 3.0.1 before the actual release of 3.0.2.
>
> For the duration of the RC testing, sources and binaries are staged at:
> https://repository.apache.org/content/repositories/maven-006/org/apache/maven/apache-maven/3.0.2-RC1/
>
&
testing, sources and binaries are staged at:
> https://repository.apache.org/content/repositories/maven-006/org/apache/maven/apache-maven/3.0.2-RC1/
>
> As usual, the changes since the previous release are listed in JIRA:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&a
Hi Benjamin,
which matches the observation that your POM locks down
maven-surefire-report-plugin to 2.4.3 but not maven-surefire-plugin.
Yes you're right...Mea culpa...
Fixed that in my project...
Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405
Hi,
outch...i've found the problem...as i expected it was my pom which was
the problem...not the release...
Sorry for that noise...
Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 13594902
Karl Heinz Marbaise wrote:
I have observed that behaviour with maven-surefire 2.7.1 (in
relationship with Maven 3.0.1) but i use maven-surefire plugin
2.4.3...(see http://jira.codehaus.org/browse/SUREFIRE-680)
From your build's log:
[INFO] --- maven-surefire-plugin:2.7.1:test (default-test)
Hi,
may be i have observed a little issue...
I have checked the following project
https://github.com/khmarbaise/Maven-Licenses-Verifier-Plugin
and did an
mvn clean package
on it.
The result was that twice times the line
"Running TestSuite"
occured with with MVN 3.0.2-RC1 but no
sting, sources and binaries are staged at:
https://repository.apache.org/content/repositories/maven-006/org/apache/maven/apache-maven/3.0.2-RC1/
As usual, the changes since the previous release are listed in JIRA:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=1695
Baptiste MATHUS wrote:
I just created a test project from
archetype, and tried -T option. And surefire shows up as being locked onto
the 2.5 version, should/couldn't 3.0.1 be locked onto 2.6 one
I didn't feel comfortable making Surefire 2.6 the default in light of
SUREFIRE-615 but that's just
>>
>> For the duration of the RC testing, sources and binaries are staged at:
>>
>> https://repository.apache.org/content/repositories/maven-008/org/apache/maven/apache-maven/3.0.1-RC1/
>>
>> As usual, the changes since the previous release are listed in JIRA:
>>
&g
0.1.
>
> For the duration of the RC testing, sources and binaries are staged at:
>
> https://repository.apache.org/content/repositories/maven-008/org/apache/maven/apache-maven/3.0.1-RC1/
>
> As usual, the changes since the previous release are listed in JIRA:
>
> http://jira.
Works fine for all Sonar projects, including based on Tycho.
On Fri, Nov 19, 2010 at 20:38, Manfred Moser wrote:
> Works fine on a multi module Android project with plain library, Android
> application and instrumentation test modules.
>
> manfred
>
>
>
>
Works fine on a multi module Android project with plain library, Android
application and instrumentation test modules.
manfred
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...
> test drive in order to detect and fix potential regressions since
> version 3.0 before the actual release of 3.0.1.
>
> For the duration of the RC testing, sources and binaries are staged
> at:
> https://repository.apache.org/content/repositories/maven-008/org/apache/maven/ap
est drive in
> order to detect and fix potential regressions since version 3.0 before the
> actual release of 3.0.1.
>
> For the duration of the RC testing, sources and binaries are staged at:
>
> https://repository.apache.org/content/repositories/maven-008/org/apache/maven/apache-m
sting, sources and binaries are staged at:
https://repository.apache.org/content/repositories/maven-008/org/apache/maven/apache-maven/3.0.1-RC1/
As usual, the changes since the previous release are listed in JIRA:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=16331
Thank
Jesse Glick wrote:
So is this really a "candidate" for release as 3.0 or do you expect to
continue making fixes?
I would like to roll at least one other RC this week.
Will you keep on publishing "RC1" over and over
(distinguishing the different builds with timestamps?
On 09/16/2010 05:21 AM, Benjamin Bentmann wrote:
This is an attempt to collect feedback from a broad audience before we start
the vote for 3.0, similar to what was done in the past.
I'm a bit confused over the labeling "RC1", perhaps you could clarify.
1. Nothing is pu
Justin Edelson wrote:
What MAVEN_OPTS are you using?
What I was told by the build:
[echo] ** WARNING (SLING-443)
**
[echo] On most platforms, you'll get OutOfMemoryErrors when building unless you
set
[echo] MAVEN_OPTS="-Xmx256M -XX:MaxPerm
wrote:
> Justin Edelson wrote:
>
>> To reproduce:
>> $ svn co http://svn.apache.org/repos/asf/sling/trunk
>> $ mvn clean install
>
> After a couple of builds of r999284 of Slink trunk with 3.0-RC1, the only
> failures I ever managed to produce were in org.apache.slin
Justin Edelson wrote:
To reproduce:
$ svn co http://svn.apache.org/repos/asf/sling/trunk
$ mvn clean install
After a couple of builds of r999284 of Slink trunk with 3.0-RC1, the
only failures I ever managed to produce were in
org.apache.sling.launchpad.testing due to the HTTP server
ng
> your help to discover regressions since Maven 2.x. Everybody interested in
> taking a preview of the upcoming release for a test drive can get source and
> binary bundles from this URL:
>
> https://repository.apache.org/content/repositories/maven-030/org/apache/maven/apache
gt; on the nexus users list some days ago.
>
> /Anders (mobile)
>
> Den 2010 9 18 10:28 skrev "stug23" :
>>
>> We see the problem reported in
> https://issues.sonatype.org/browse/NEXUS-3776
>>
>> This would need to be resolved before we can use Maven 3.0
stug23 wrote:
We see the problem reported in https://issues.sonatype.org/browse/NEXUS-3776
This would need to be resolved before we can use Maven 3.0-RC1.
https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes
be resolved before we can use Maven 3.0-RC1.
>
> I am not sure whether this requires a fix in Nexus or in Maven?
> --
> View this message in context:
http://maven.40175.n5.nabble.com/PLEASE-TEST-Apache-Maven-3-0-RC1-tp2841338p2844349.html
> Sent from the Maven Develope
1 - 100 of 367 matches
Mail list logo
