IMO publishing to central/acrhiva would involve publishing the "richest"
format available. Based on use-agent identification (or lack of a given
request param indicating old-style client) the repository should be able to
down-transform a v5 pom to a v4 pom "on the fly" ? We're not going to be
losin
reading your stack trace.
No that's not part of maven core.
Maven core define a version you can override.
So as Core 2.2.1 is a bit old it comes with old surefire version
Except if you override that in your pom.
On 25 November 2013 16:32, Sergey Bondarenko wrote:
> I use Surefire 2.16, and the
I use Surefire 2.16, and the problem is reproducible with that version. Why
do you think it is Surefire? Isn't that package part of Maven Core?
Thanks,
Sergey
2013/11/24 Olivier Lamy
> sounds more an issue in surefire plugin.
> Try use last version of this plugin. (2.16)
>
>
>
> On 25 November
sounds more an issue in surefire plugin.
Try use last version of this plugin. (2.16)
On 25 November 2013 15:29, Sergey Bondarenko wrote:
> Hi Olivier,
>
> The package is part of apache-maven-2.2.1/lib/maven-2.2.1-uber.jar.
> It looks like it is a part of Maven Core (at least it is a part of sta
Hi Olivier,
The package is part of apache-maven-2.2.1/lib/maven-2.2.1-uber.jar.
It looks like it is a part of Maven Core (at least it is a part of standard
distribution).
I do not know why the attached thread dump did not work for you, so I am
sending it as a pastebin: http://pastebin.com/T1MAkwL
> On Sunday, 24 November 2013, Manfred Moser wrote:
>
>>
>> > By separating "consumption" and "production" metadata formats, we'll
>> be
>> > able to evolve production format more aggressively. For example, it
>> > would be nice to have Tycho-specific configuration markup inside
>>
>> > section. T
Hi,
I'd like to release Apache Maven Shade plugin 2.2
We fixed 1 issue:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11540&version=18768
Staging repository:
https://repository.apache.org/content/repositories/maven-002/
Source release:
https://repository.apache.org/content/repositor
Within Maven core or a plugin? I'm not sure Maven core use that..
BTW Hard to know without any logs and/or stack trace or/and the Maven
version you are using.
On 22 November 2013 06:16, Sergey Bondarenko wrote:
> Good afternoon,
>
> I have caught a deadlock in Maven several times, when it was
Good afternoon,
I have caught a deadlock in Maven several times, when it was executing
TestNG tests (see the thread dump attached).
It was happening in
hidden.edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.
Do you think it is a defect in this concurrency back-port?
Is there a
Tool chains don't help at runtime... But for system scope you likely need a
level above to inject the deps into the ext folder (or use a system
property for the JVM startup options)... But point us these are deps
required but required outside of the scope that is reasonably managed by
maven. They f
That's why I say parent poms are deployed in three formats: 4.0.0, 5.0.0+
and build. And you specify that your parent Pom must be <= modelVersion of
child pom so that it can evolve as needed
On Sunday, 24 November 2013, Hervé BOUTEMY wrote:
> Le dimanche 24 novembre 2013 16:58:33 Stephen Connolly
On 25 November 2013 03:28, Stephen Connolly
wrote:
[del]
> Given that we have decided that the reporting stuff possibly was a
> mistake... Well let's drop that
>
> Given that profiles do not make sense in deployed poms... Drop them too
>
> We think is evil... Let's drop that... We've dropped buil
Le dimanche 24 novembre 2013 16:58:33 Stephen Connolly a écrit :
> Given that deployed poms can be generated by Gradle, Buildr, etc... It
> makes no sense to include build information in the pom (unless it is a
> parent pom)
if you think at it, a parent pom is a pure build configuration for sharing
[...]
> I think this sounds nice in theory but losing the information about how an
> artifact is produced is not a good idea.
for consumers, plugins information is really bloat
> I also don't think having a bunch
> of different tools to read one format or another is manageable.
we can have multipl
ah ok, I better understand your intend with provides: it's not a way to find
implementers (like expected by Igor and I), but a way to avoid collisions
I didn't think at such an approach for the moment: need to thk=ink more at it
but at a first glance, I find your idea better than what I feared p
don't we have toolchains for such a case?
Regards,
Hervé
Le dimanche 24 novembre 2013 20:13:38 Stephen Connolly a écrit :
> On 24 November 2013 19:42, Robert Patrick wrote:
> > > Additionally, I think we should refine scopes... there are some that are
> >
> > likely missing and some, such as `
Le dimanche 24 novembre 2013 10:26:13 Jason van Zyl a écrit :
> On Nov 24, 2013, at 12:19 AM, Manfred Moser wrote:
> >> By separating "consumption" and "production" metadata formats, we'll be
> >> able to evolve production format more aggressively. For example, it
> >> would be nice to have Tycho-
On 24 November 2013 19:42, Robert Patrick wrote:
> > Additionally, I think we should refine scopes... there are some that are
> likely missing and some, such as `system` that should be removed.
>
> Pardon my ignorance but while I understand the negative implications of
> using system-scoped depen
Hmm, maybe I cheered too early. A second run gave me 6 errors.
Still unsure what is keeping a lock of the files.
Both 'mvn clean' and 'rmdir /S target' fail.
F:\java-workspace\apache-maven-scm\maven-scm\maven-scm-providers\maven-scm-provi
ders-git\maven-scm-provider-jgit>rmdir /S target
target. W
> Additionally, I think we should refine scopes... there are some that are
> likely missing and some, such as `system` that should be removed.
Pardon my ignorance but while I understand the negative implications of using
system-scoped dependencies, I believe there are cases at least a few use ca
We're getting closer, only one error left:
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.926 sec
<<< FA
ILURE! - in
org.apache.maven.scm.provider.git.jgit.command.tag.JGitTagCommandTck
Test
testTagCommandTest(org.apache.maven.scm.provider.git.jgit.command.tag.JGitTagCom
m
On 24 November 2013 17:44, Jason van Zyl wrote:
>
> On Nov 24, 2013, at 10:28 AM, Benson Margulies
> wrote:
>
> > It seems to me that this thread is mixing two topics.
> >
> > Topic #1: How to we move to pom 5.0, given a giant ecosystem of crappy
> > XML-parsing POM consumers?
> >
> > Topic #2:
Hi everyone,
I think I solved all the issues we had on windows with the jgit-provider
@Robert can you have another try now?
The build https://builds.apache.org/job/maven-scm/ currently fails, but this is
related to an issue with the upload to the snapshot repository at
https://repository.apache.o
I think I fixed it, just by avoiding confusing verifier version detection =
parsing of content between parenthesis
Regards,
Hervé
Le dimanche 24 novembre 2013 11:24:42 Robert Scholte a écrit :
> Does it contain a fix for testing the log4j branch of Maven?
>
> See for example
> https://builds.a
On Nov 24, 2013, at 10:28 AM, Benson Margulies wrote:
> It seems to me that this thread is mixing two topics.
>
> Topic #1: How to we move to pom 5.0, given a giant ecosystem of crappy
> XML-parsing POM consumers?
>
> Topic #2: To what extent does the pom mix a 'description of contract'
> (dep
On Sunday, 24 November 2013, Jason van Zyl wrote:
>
> On Nov 24, 2013, at 3:59 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com > wrote:
>
> > On Sunday, 24 November 2013, Jason van Zyl wrote:
> >
> >>
> >> On Nov 23, 2013, at 5:44 PM, Stephen Connolly <
> >> stephen.alan.conno...@gmail.co
On Sunday, 24 November 2013, Igor Fedorenko wrote:
> How do you find all artifacts that provide gav="javax:servlet-api:3.0"?
You don't need to.
You just need to treat it as a global excludes on javax:servlet-api
The difference is that it also excludes any other poms that get pulled in
transiti
I have one more remark to contribute to this.
In my view, the first step should be to make a 4.0-beta version of
Maven that has a '5.0.0' pom that is _identical_ to the 4.0.0 pom. The
difference is that we will document, after the fashion of HTML5, our
intent to change it over time. We can then ad
How do you find all artifacts that provide gav="javax:servlet-api:3.0"?
One option is to download entire repository index to the client, but
Central index will likely be in 100x of megabytes, which makes this
approach impractical. The only other option is to keep the index on the
server and have s
On Nov 24, 2013, at 3:59 AM, Stephen Connolly
wrote:
> On Sunday, 24 November 2013, Jason van Zyl wrote:
>
>>
>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com > wrote:
>>
>>> Before I forget, here are some of my thoughts on moving towards Model
>>> Versio
On Sunday, 24 November 2013, Igor Fedorenko wrote:
> I think we are saying the same thing -- we evolve project model used
> during the build but deploy both the new and backwards compatible models.
>
> One quick note on representing dependencies as provided/required
> capabilities.
I think it ne
It seems to me that this thread is mixing two topics.
Topic #1: How to we move to pom 5.0, given a giant ecosystem of crappy
XML-parsing POM consumers?
Topic #2: To what extent does the pom mix a 'description of contract'
(dependencies, etc) with a 'specification of build'?
On the first topic, t
On Nov 24, 2013, at 12:19 AM, Manfred Moser wrote:
>
>> By separating "consumption" and "production" metadata formats, we'll be
>> able to evolve production format more aggressively. For example, it
>> would be nice to have Tycho-specific configuration markup inside
>> section. This is not cur
On Nov 23, 2013, at 11:47 PM, Igor Fedorenko wrote:
>
>
> On 11/23/2013, 23:08, Jason van Zyl wrote:
>>
>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
>> wrote:
>>
>>> Before I forget, here are some of my thoughts on moving towards
>>> Model Version 5.0.0
>>>
>>> The pom that we build wi
I haven't looked at log4j2 branch, but master passes all ITs with the
latest verifier 1.5-SNAPSHOT.
--
Regards,
Igor
On 11/24/2013, 5:24, Robert Scholte wrote:
Does it contain a fix for testing the log4j branch of Maven?
See for example
https://builds.apache.org/job/core-integration-testing-ma
I think we are saying the same thing -- we evolve project model used
during the build but deploy both the new and backwards compatible models.
One quick note on representing dependencies as provided/required
capabilities. Although I like this idea in general, I believe it will
require completely
> Date: Sat, 23 Nov 2013 23:47:55 -0500
> From: i...@ifedorenko.com
> To: dev@maven.apache.org
> Subject: Re: Model Version 5.0.0
>
>
>
> On 11/23/2013, 23:08, Jason van Zyl wrote:
> >
> > On Nov 23, 2013, at 5:44 PM, Stephen Connolly
> > wrote:
> >
> >> Before I forget, here are some of m
Does it contain a fix for testing the log4j branch of Maven?
See for example
https://builds.apache.org/job/core-integration-testing-maven-3-jdk-1.6-log4j2/457/console
Running integration tests for Maven 4J2)
using Maven executable:
/home/jenkins/jenkins-slave/workspace/core-integration-tes
On Sunday, 24 November 2013, Manfred Moser wrote:
>
> > By separating "consumption" and "production" metadata formats, we'll be
> > able to evolve production format more aggressively. For example, it
> > would be nice to have Tycho-specific configuration markup inside
> > section. This is not cur
On Sunday, 24 November 2013, Igor Fedorenko wrote:
>
>
> On 11/23/2013, 23:08, Jason van Zyl wrote:
>
>>
>> On Nov 23, 2013, at 5:44 PM, Stephen Connolly
>> wrote:
>>
>> Before I forget, here are some of my thoughts on moving towards
>>> Model Version 5.0.0
>>>
>>> The pom that we build with nee
On Sunday, 24 November 2013, Jason van Zyl wrote:
>
> On Nov 23, 2013, at 5:44 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com > wrote:
>
> > Before I forget, here are some of my thoughts on moving towards Model
> > Version 5.0.0
> >
> >The pom that we build with need not be the pom t
41 matches
Mail list logo
