Re: Question regarding repository overriding.

On Thursday, 15 December 2016, Christian Schulte wrote: > Am 12/15/16 um 01:09 schrieb Christian Schulte: > > I would have expected the nearest wins strategy as well, BTW. Seems to > > not make sense for the resolver to just ignore repository declarations > > matching an ID

Re: 2nd question regarding repository overriding.

profiles are applied IMHO *after* the current pom... and whatever is in the current pom overrides dependencies... On 13 December 2016 at 01:57, Christian Schulte wrote: > Am 12/13/16 um 02:32 schrieb Christian Schulte: > > Consider these projects: > > > > P1 declares a

Re: Question regarding repository overriding.

definition nearest to the project should win is the principle that has been in force... when the definition is coming from a dependency, however, the concept of distance can become confused - especially given how the dependency graph is version conflict reduced On 13 December 2016 at 01:32,

Re: POM 5: The problems with mixins

gonomic as needed > using custom configuration > same way configuration is used by mojos. > > [1] > https://github.com/sviperll/ozymandias/tree/master/maven- > profiledep-extension > [2] https://github.com/repaint-io/maven-tiles > [3] https://issues.apache.org/jira/browse/MNG-

POM 5: The problems with mixins

I'm currently trying to figure out how to make mixins possible in POM 5. Mixins basically bring a form of multiple inheritance to the POM... which leads to the problems of how to solve conflicts. Inheritance Style = The first problem I hit was how to actually deal with a parent that

Re: [MNG-5761] Dependency management is not transitive.

Given all the bugs I found in parent version ranges, it would not surprise me if it had previously been appearing to work as long as you have a full reactor, but using -pl to slice and dice the reactor or building individual modules by cd-ing into them But anyway YMMV On Sat 19 Nov 2016 at

Re: [MNG-5761] Dependency management is not transitive.

the time to do that... though on a release VOTE thread I will be reviewing the changes to the integration tests as well as master -Stephen > > > On Nov 17, 2016, at 12:10 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > > Jason, yo

Re: [MNG-5761] Dependency management is not transitive.

Jason, your hyperbole has slipped again. There is no need to make assertions about how many or what kind of users other developers have worked with, as that both does not foster the community and deflects from the valid point you were otherwise making. Christian has done the right thing in seeking

Re: Build behavior differences between 3.2.5 and 3.3.9 with dependency shading

ives.apache.org/mod_mbox/flink-dev/201512. > mbox/%3CCANZa%3DGvFA%2B61968DBYoZc%3D8WfEmoF01DJAkmvzUcUH5XycLQ5w > %40mail.gmail.com%3E > > > On Thu, Dec 10, 2015 at 5:01 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > You need to do this in any

Re: simplify release procedure

+1 to the principle. Can we see your proposed procedure (if you are tweaking one of the other steps to mention this requirement) On Sunday 30 October 2016, Robert Scholte wrote: > Hi, > > I'd like to remove step 6 of our release procedure[1]: > 6. Add the release

Re: Some thoughts on Maven 5

wrote: > Stephen Connolly wrote: > > * we should let the user define lifecycles directly in the Pom (ok, > maybe we don't *encourage it*) > > More packaging-related phases in the default lifecycle. > > I very much like the idea of a standard lifecycle, as it often forces &

Re: Some thoughts on Maven 5

{ compile: [ "org.slf4j:slf4j-api::1.8.0::jar" ] test: [ "junit:junit::4.12::jar" ] } On 20 October 2016 at 08:46, Andreas Sewe < s...@st.informatik.tu-darmstadt.de> wrote: > Stephen Connolly wrote: > > Hmmm shower thinking now has me pondering

Re: Maven 3.4.0 color output and default slf4j implementation

On 19 October 2016 at 12:37, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > Le lundi 17 octobre 2016 20:58:16 Stephen Connolly a écrit : > > Could you at least raise the issues that you see as blocking Gossip > against > > it. I presume you have them currently in y

Re: Maven 3.4.0 color output and default slf4j implementation

Could you at least raise the issues that you see as blocking Gossip against it. I presume you have them currently in your context and it would be good to capture them now so that if somebody can add those features to Gossip (assuming they are aligned with the direction Gossip wants to go) then we

Re: Some thoughts on Maven 5

On 17 October 2016 at 01:25, Christian Schulte <c...@schulte.it> wrote: > Am 10/15/16 um 15:20 schrieb Stephen Connolly: > > * Pom doesn't need to be XML any more... (maybe we want to keep XML > though... just a less verbose form) > > Maybe XML really isn't the wa

Re: [jira] [Created] (MRESOLVER-4) Use Commons Lang's Validate to intercept invalid input

Let's just go for Java 7... this is linked to core... if you are stuck on an older Java likely you can't upgrade Maven anyway On Sunday 16 October 2016, Christian Schulte wrote: > Am 10/16/16 um 22:51 schrieb Michael Osipov: > > Am 2016-10-16 um 22:48 schrieb Christian Schulte:

Re: ASF IRC Services and Archives

INFRA-12772 On 16 October 2016 at 20:43, Robert Scholte <rfscho...@apache.org> wrote: > +1 > > > On Sun, 16 Oct 2016 21:13:53 +0200, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > >> http://wilderness.apache.org/ >> >> Ju

ASF IRC Services and Archives

http://wilderness.apache.org/ Just found out about this... should we request to get this setup for our two IRC channels on freenode? My vote is yes Sent from my iPhone - To unsubscribe, e-mail:

Re: Some thoughts on Maven 5

uot;cdutz". > > > Chris > > ____ > Von: Stephen Connolly <stephen.alan.conno...@gmail.com <javascript:;>> > Gesendet: Sonntag, 16. Oktober 2016 13:49:39 > An: Maven Developers List > Betreff: Re: Some thoughts on Maven 5 > > Let us know

Re: Some thoughts on Maven 5

che.org/jira/browse/MNG-6107 > > But I can't edit or comment on the page: > > https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0 > > > Chris > > > Von: Stephen Connolly <stephen.alan.conno...@gmail.com <java

Re: Some thoughts on Maven 5

t; But I can't edit or comment on the page: > > https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0 > > > Chris > > ____ > Von: Stephen Connolly <stephen.alan.conno...@gmail.com <javascript:;>> > Gesendet: Sonntag

Re: Some thoughts on Maven 5

Adding a section to the wiki to help track this https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0 On 16 October 2016 at 04:12, Christian Schulte <c...@schulte.it> wrote: > Am 10/16/16 um 02:03 schrieb Stephen Connolly: > >> On 16 Oct 2016, at 00:07, Ch

Re: Some thoughts on Maven 5

Sent from my iPhone > On 16 Oct 2016, at 00:07, Christian Schulte <c...@schulte.it> wrote: > >> Am 10/16/16 um 00:57 schrieb Stephen Connolly: >> We only have to generate a "consumer pom" in modelVersion 4.0.0... and that >> need only be best e

Re: Some thoughts on Maven 5

On Sunday 16 October 2016, Christian Schulte <c...@schulte.it> wrote: > Am 10/16/16 um 00:57 schrieb Stephen Connolly: > > We only have to generate a "consumer pom" in modelVersion 4.0.0... and > that > > need only be best effort, and will be generated off th

Re: Some thoughts on Maven 5

ache.org> wrote: >> >> We should have a look at the MNG jira issues for those marked for Maven 4 >>> too >>> >>> >>> On Sat, 15 Oct 2016 15:20:40 +0200, Stephen Connolly < >>> stephen.alan.conno...@gmail.com> wrote: >>&

Re: Some thoughts on Maven 5

On Saturday 15 October 2016, Christian Schulte <c...@schulte.it> wrote: > Am 10/15/16 um 15:20 schrieb Stephen Connolly: > > * does Maven 5 build Maven 2/3 projects? > > No need for this, IMHO. Maven 2 could not build Maven 1 projects. Maven > 3 could build Maven 2 pro

Re: Some thoughts on Maven 5

t 2016 15:20:40 +0200, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > So now that I have a spec for the PDTs drafted, I have been thinking of >> how that could influence Maven 5. Some things that came to mind, in no >> particular order: >> >>

Re: Some thoughts on Maven 5

..@apache.org> wrote: > We should have a look at the MNG jira issues for those marked for Maven 4 > too > > On Sat, 15 Oct 2016 15:20:40 +0200, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > So now that I have a spec for the PDTs drafted, I have been thin

Re: Some thoughts on Maven 5

the parent pom... and I wonder if the supports concept in the PDT will remove the need... Needs thinking either way Sent from my iPhone > On 15 Oct 2016, at 15:26, Stephen Connolly <stephen.alan.conno...@gmail.com> > wrote: > > Thinking out loud... perhaps something l

Re: Some thoughts on Maven 5

, allow platform activation to be considered... each platform is like a mini-sub project that can "run in parallel" (yes I need to doc this better...) Sent from my iPhone > On 15 Oct 2016, at 15:26, Stephen Connolly <stephen.alan.conno...@gmail.com> > wrote: > >

Re: Some thoughts on Maven 5

, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Thinking out loud... perhaps something like > > [version="..."] packaging=&

Re: Some thoughts on Maven 5

for myself based on thoughts I had while going for a walk... but it may inspire others to think about this topic too -Stephen On 15 October 2016 at 14:34, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > > > Sent from my iPhone > > > On 15 Oct 2016, at

Re: Some thoughts on Maven 5

Sent from my iPhone > On 15 Oct 2016, at 14:20, Stephen Connolly <stephen.alan.conno...@gmail.com> > wrote: > > So now that I have a spec for the PDTs drafted, I have been thinking of how > that could influence Maven 5. Some things that came to mind, in no particular

Some thoughts on Maven 5

So now that I have a spec for the PDTs drafted, I have been thinking of how that could influence Maven 5. Some things that came to mind, in no particular order: * scope becomes a build time only concern. Thus we can let users define custom scopes in their pom. If we let plugin executions

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

On Friday 14 October 2016, Robert Scholte wrote: > On Fri, 14 Oct 2016 00:09:26 +0200, Christian Schulte > wrote: > > Am 10/13/16 um 21:52 schrieb Robert Scholte: >> >>> On Thu, 13 Oct 2016 02:53:54 +0200, Christian Schulte >>>

Project Dependency Trees RFC draft completed

https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema I deem the first draft completed. Please can we get comments from the other Maven Developers as I am sure it is not quite ready for sharing with the other build tool developers yet. -Stephen

Re: Maven 3.4.0 Release

On 10 October 2016 at 09:40, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > > https://issues.apache.org/jira/browse/MNG-5971 > > I would argue that the behaviour change in MNG-5971 should not be > introduced at the same time as a refactoring to move to the new &

Re: Maven 3.4.0 Release

t want that included with the other changes for 3.4.x anyway On 10 October 2016 at 09:26, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On 10 October 2016 at 01:38, Christian Schulte <schu...@apache.org> wrote: > >> Am 10/09/16 um 21:44 schrieb Stephen C

Re: Maven 3.4.0 Release

On 10 October 2016 at 01:38, Christian Schulte <schu...@apache.org> wrote: > Am 10/09/16 um 21:44 schrieb Stephen Connolly: > > Open issues bound to 3.4.0 > > > > * Introduction of model version 4.1.0. > > https://issues.apache.org/ji

Re: Maven 3.4.0 Release

On Sunday 9 October 2016, Robert Scholte wrote: > Open issues bound to 3.4.0 > > * Introduction of model version 4.1.0. > https://issues.apache.org/jira/browse/MNG-6082 > assignee: Christian Schulte (reporter: Christian Schulte) I am -1 on this change as I understand

Re: Maven 3.4.0 Release

Did we revert the modelVersion bump? On Sunday 9 October 2016, Karl Heinz Marbaise wrote: > Hi Jason, > > > On 09/10/16 14:10, Jason van Zyl wrote: > >> The preparation of detailed released notes to be reviewed. >> > > The last release was almost a year ago, and an enormous

Re: Project Dependency Trees schema...

is kind of hacking. > > Assuming you will only specify runtime required dependencies here, I think > the flex-team had the requirement for different scopes of jar files both > required at runtime. Will need to go through the archive for this. > > thanks, > Robert > > On Mo

Re: Project Dependency Trees schema...

:27 schrieb Stephen Connolly: > > On Wednesday 28 September 2016, Christian Schulte <c...@schulte.it > <javascript:;>> wrote: > > > >> Am 09/28/16 um 08:25 schrieb Stephen Connolly: > >>> So if we provide a way to decentralise. > >> > >>

Re: Project Dependency Trees schema...

On Wednesday 28 September 2016, Christian Schulte <c...@schulte.it> wrote: > Am 09/28/16 um 08:25 schrieb Stephen Connolly: > > So if we provide a way to decentralise. > > We do already. > > > > > So now junit hosts their own artifacts, not central >

Towards Maven 4.0.0

I have started gathering together my proposals on how we can move Maven forward under the https://cwiki.apache.org/confluence/display/MAVEN/Requests+for+Comment page. Hopefully we can use the wiki to actually drive discussion and collaboration on the topics that concern us this way. -Stephen

Re: Project Dependency Trees schema...

What happens if I want to use an in-house patch build of junit? I will not have the same origin... On Wednesday 28 September 2016, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > > > On Wednesday 28 September 2016, Christian Schulte <c...@schulte.it > <javasc

Re: Project Dependency Trees schema...

On Wednesday 28 September 2016, Christian Schulte <c...@schulte.it> wrote: > Am 09/28/16 um 04:48 schrieb Christian Schulte: > > Am 09/28/16 um 04:16 schrieb Christian Schulte: > >> Am 09/27/16 um 15:24 schrieb Stephen Connolly: > >>> I think that may be probl

Re: Project Dependency Trees schema...

f artifactId or groupId authority. So as long as the coordinates > cannot be used to map to a set of authoritative repositories, this > information needs to be tracked somehow. > > > Am 09/26/16 um 15:29 schrieb Stephen Connolly

Re: Project Dependency Trees schema...

26 September 2016, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Here's an approximation of my current

Re: Project Dependency Trees schema...

On Monday 26 September 2016, Christian Schulte <c...@schulte.it> wrote: > Am 09/26/16 um 15:29 schrieb Stephen Connolly: > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> > For additional commands, e-mail: dev-h...@mave

Re: Project Dependency Trees schema...

On Monday 26 September 2016, Christian Schulte <c...@schulte.it> wrote: > Am 26.09.2016 um 15:29 schrieb Stephen Connolly: > > Here's an approximation of my c

Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?

Sounds reasonable. I think you have your answer On Monday 26 September 2016, Stian Soiland-Reyes <st...@apache.org> wrote: > If you don't mind helping with back porting, then we can help push > maintenance releases out :) > > On 26 Sep 2016 11:03 a.m., "Stephen Connolly&

Project Dependency Trees schema...

Here's an approximation of my current thinking: [...] [...] ... ... ...

Thoughts on Robert's JavaOne talk

https://www.youtube.com/watch?v=Wef9p4ykNMM Some questions Robert had: 1. Do we need module-info.java for src/main/test? * Well if I'm creating a test-jar to allow reuse of the tests in downstream projects, then yes we do 2. Is Animal-Sniffer relevant now that we have --release N? * Well more

Re: Would Commons Lang on Java 8 be a problem for the Apache Maven project?

Well another question is how much longer will we support Java 7 anyway... what we have said in the past is the next release line after JDK9 is released will only support Java 8+... now we could change that, but that is *currently* what we have currently stated. I suspect that a bump to Java 8 by

Re: ComparableVersionTest

So let's think how this would work in a project dependency tree world... For each node in the tree we would need to provide: 1. Any coordinates of artifacts that are provided by this artifact (or a compatible implementation is provided)... in most cases this will be empty, but still 2. Any

Re: [DISCUSS] Incorporating an ArchitectureId into the GAVCT of the repository

? On Thursday 1 September 2016, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > One of the things I feel is necessary to grow Maven in the modelVersion > 5.0.0 world is to start taking account of architecture specific artifacts. > > Currently, the Maven repository layo

Re: [DISCUSS] Incorporating an ArchitectureId into the GAVCT of the repository

derstood this and maybe internally it is not pure webcontent. > In few years later we or Nexus wants to add "cloudId" similar to what you > introduced with "architectureId". Again the pair in database would be > key=value is architectureId=POM; just a pure examp

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Friday 2 September 2016, Robert Scholte <rfscho...@apache.org> wrote: > On Wed, 31 Aug 2016 22:51:20 +0200, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > On Wednesday 31 August 2016, Robert Scholte <rfscho...@apache.org> wrote: >> &

Re: [DISCUSS] Incorporating an ArchitectureId into the GAVCT of the repository

t; Been there with maven1->maven2 Consensus is "let's not do that again" > So the next generation 5.0 would go to *https://repo1.maven.org/ > <https://repo1.maven.org/>maven5*. > > WDYT? > > > > > > On Thu, Sep 1, 2016 at 12:07 PM, Stephe

Re: [DISCUSS] Incorporating an ArchitectureId into the GAVCT of the repository

es building these projects magically easier though ;-) ) > > Chris > > > Von: Stephen Connolly <stephen.alan.conno...@gmail.com <javascript:;>> > Gesendet: Donnerstag, 1. September 2016 12:07:18 > An: Maven Developers List > Betreff: [DISCUSS] Incorporating an A

[DISCUSS] Incorporating an ArchitectureId into the GAVCT of the repository

One of the things I feel is necessary to grow Maven in the modelVersion 5.0.0 world is to start taking account of architecture specific artifacts. Currently, the Maven repository layout does not handle architecture specific dependencies well. So, for example: Say I have a foo.jar that depends

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Thursday 1 September 2016, Christian Schulte <c...@schulte.it> wrote: > Am 08/31/16 um 22:51 schrieb Stephen Connolly: > > So for the tests-jar.., that would have a declared dependency on the > > regular .jar and provide the tree for the test-runtime s

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Wednesday 31 August 2016, Robert Scholte <rfscho...@apache.org> wrote: > On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > On Wednesday 31 August 2016, Christian Schulte <c...@schulte.it> wrote: >> >&

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Wednesday 31 August 2016, Christian Schulte <c...@schulte.it> wrote: > Am 08/31/16 um 18:39 schrieb Christian Schulte: > > Am 08/31/16 um 07:52 schrieb Stephen Connolly: > >> I've been thinking about what to call the "consumer Pom"... > >> > &g

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

Next steps: * start fleshing out a schema for the .pdt files * start fleshing out a spec for the repository layout (should be "parsable" by modelVersion 4.0.0 aware clients, but need to decide how to expose new features) On Tuesday 30 August 2016, Stephen Connolly <stephen.alan.conno...@gma

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On 29 August 2016 at 23:27, Christian Schulte wrote: > Am 08/30/16 um 00:16 schrieb Paul Benedict: > > I see a deployed faulty "consumer pom" to be more more harmful than > > generating it locally on demand. At least with the local one I can > upgrade > > my client to fix a

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

ble to inherit from the primary artifact Whether to include scm or repository info is an open question On Thursday 25 August 2016, Robert Scholte <rfscho...@apache.org> wrote: > On Thu, 25 Aug 2016 18:30:50 +0200, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Thursday 25 August 2016, Robert Scholte <rfscho...@apache.org> wrote: > On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > On 24 August 2016 at 04:50, Robert Scholte <rfscho...@apache.org> wrote: >> >&g

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

ests as we could attach the test dependencies to the test artifact details in the consumer pom) Consumer-dom is an extraction and enriched version of the pom and will be a > separate upload to the repository. Build tools who can understand this file > can use it or fall back by downloading all poms.

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

e SCM is offline or gone or private or > > > > > whatever. > > > > > Or did I misunderstand? If so, please clarify? > > > > > > > > when you consume an artifact not build with Maven, do you get the > full > > > > build > > >

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Tuesday 23 August 2016, Paul Benedict wrote: > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte > wrote: > > > Am 08/24/16 um 00:08 schrieb Paul Benedict: > > > POM and a future major version POM? I am hinting at a strategy for > >

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Monday 22 August 2016, Karl Heinz Marbaise <khmarba...@gmx.de> wrote: > Hi Stephen, > On 23/08/16 01:12, Stephen Connolly wrote: > >> On Monday 22 August 2016, Christian Schulte <c...@schulte.it> wrote: >> >> Am 08/22/16 um 09:08 schrieb Stephe

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

On Monday 22 August 2016, Christian Schulte <c...@schulte.it> wrote: > Am 08/22/16 um 09:08 schrieb Stephen Connolly: > > This is why I said that the v5 pom (which v4.1 is... just under a > different > > name) would have to be deployed separately with a *best effort

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

This is why I said that the v5 pom (which v4.1 is... just under a different name) would have to be deployed separately with a *best effort* translation down to the 4.0.0 model deployed at the standard coordinates. The problem then becomes that we are deploying now two poms for everything, a 4.0.0

Re: [DISCUSSION] finishing Aether import: help find a new name

+1 On 5 August 2016 at 14:34, Tamás Cservenák wrote: > ... Mercury > > On Thu, Aug 4, 2016 at 11:09 PM Jason van Zyl wrote: > > > When in doubt I have tried Velocity, Turbine, Plexus, Nexus, Aether and > > Tycho. None of them very useful for people to

Re: [DISCUSSION] finishing Aether import: help find a new name

Eclipse owns the Aether name. We cannot use the name Aether. On 5 August 2016 at 05:14, Uwe Barthel wrote: > Hi, > > I know Aether is one of the catchy non telling name. > But, why not leave Aether with new Maven namespace like > org.apache.maven.aether? > > -- barthel > >

Re: [DISCUSSION] finishing Aether import: help find a new name

On Thursday 28 July 2016, Jason van Zyl wrote: > What the external name is can be whatever people feel is most suitable. > > We should jump into IRC, as I think that will be faster, to figure out how > it should be used. > > I’m a vehement -1 to changing the artifactIds or

Re: [DISCUSSION] finishing Aether import: help find a new name

On 28 July 2016 at 09:35, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > -1 on Akasha actually that should be -0. on Akasha... i.e. I am not vetoing the name, just really don't like it

Re: [DISCUSSION] finishing Aether import: help find a new name

I don't see that this needs a special name, so I am -1 on Akasha I like Maven Artifact Resolver API... but my only concern with the "mara" short form is that I'll keep replaying radio satire in my head every time I say it, e.g. https://www.youtube.com/watch?v=d6ITDfkwKTA What exactly is wrong

Re: Extending Maven to allow scope resolutions for other languages than Java

The code for the project formerly known as Aether is being migrated to Maven as the Eclipse Aether project has been retired. Ideally we do not want to expose the code known as Aether to plugins, so we will probably expose APIs targeted for the use-cases of Maven plugins... We were somewhat

Re: svn commit: r1752607 - /maven/pom/trunk/maven/pom.xml

Welcome on board On Thursday 14 July 2016, wrote: > Author: gboue > Date: Thu Jul 14 09:10:51 2016 > New Revision: 1752607 > > URL: http://svn.apache.org/viewvc?rev=1752607=rev > Log: > Added Guillaume Boué in the list of committers > > Modified: >

Re: MNG-4883

07/04/16 um 22:37 schrieb Stephen Connolly: > > 1.0 is just a hint, hints can be overridden > > By means of dependency mediation? So a "1.0" can be ignored during > dependency mediation due to e.g. the nearest wins strategy eliminating > that "1.0" but a "[

Re: MNG-4883

sorting for distance... and wahhh So people don't use ranges and just use hints On 4 July 2016 at 21:37, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > 1.0 is just a hint, hints can be overridden > [1.0] is a hard requirement > > On 4 July 2016 at 21:35, Ch

Re: MNG-4883

1.0 is just a hint, hints can be overridden [1.0] is a hard requirement On 4 July 2016 at 21:35, Christian Schulte wrote: > Hi, > > is version "1.0" really different to the version range "[1.0]"? I am > asking because I would like to understand what MNG-4883 is about. If you >

Re: svn commit: r1747802 - in /maven/release/trunk/maven-release-plugin/src: it/projects/perform/MRELEASE-459/pom.xml main/java/org/apache/maven/plugins/release/PerformReleaseMojo.java

Well I always end up with multiple release profiles because different orgs need different GPG signing keys etc... On Saturday, 11 June 2016, Anders Hammar wrote: > Even if this (breaking) change is for v3.0.0 of the plugin, I'm missing > some clear docs about how it is

Re: any ideas why 'Scanning for projects' is very slow ?

http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html On 2 June 2016 at 07:22, Jorg Heymans wrote: > Hi, > > Thanks for the suggestions. > > --no-snapshot-updates does not make a difference. I tried out the profiler > and it gives me a

Re: [VOTE] Retire Maven Ant Tasks

+1 On 15 May 2016 at 22:24, Michael Osipov wrote: > Hi, > > this component hasn't been touched for years effectively and we rely now > on Maven for Maven (dog food). Additionally, Ant build support has already > been removed from Maven. This relic shouldn't be used with

Re: Maven and DevOps

On Saturday 14 May 2016, Hohwiller, Jörg wrote: > Hi there, > > thanks for all your feedback. > > Just to clarify: > > * I do not want to really discuss the processes of mojohaus or maven > community projects with this thread. If you get inspired to simplify by > this

Re: [jira] Michael Osipov mentioned you (JIRA)

On Sunday 17 April 2016, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > So the following is not of concern to the maven project - as we do not > ship a JRE - but anyone who does ship a JRE cannot do so and ship the > annotations *claimed* to be JSR-305 Now it co

Re: [jira] Michael Osipov mentioned you (JIRA)

So the following is not of concern to the maven project - as we do not ship a JRE - but anyone who does ship a JRE cannot do so and ship the annotations *claimed* to be JSR-305 This is because the JRE binary license specifically contains a clause mandating that you do not add or redefine classes

Anyone care to advise?

I had an evil idea... https://github.com/stephenc/reactor-snapshot-maven-plugin So the idea is to let you do things and resume quicker while doing things that need the reactor artifacts when you don't want to invoke the full lifecycle e.g. mvn package

Re: Julia Antonova is out of office.

w00t... I missed finding out about her holidays and had assumed she had unsubscribed... I am happy again On 22 February 2016 at 18:59, Jesse McConnell wrote: > So where did the wiki page for this end up getting migrated after codehaus > shutdown? > > -- > jesse

Some interesting thoughts on project dependency models

https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.mnt09gdr7 I like the lock file concept... Would it make ranges actually useful for maven? That is, leave the version range in the pom, have the resolved version in the lock file that gets checked in and published

Re: Apache Build Server Jobs

W. You can perfectly create and version pipeline jobs > through Job DSL. > Granted if using multibranch pipeline jobs, then the frontier becomes even > more tenuous as the project build description then lays in the code itself. > But still you can handle creating/versioning the job

Re: Apache Build Server Jobs

I'd rather use pipeline or literate so we get better branch support, but I need to bash Andrew on the head first On Wednesday 10 February 2016, Karl Heinz Marbaise wrote: > Hi, > > after a request to INFRA they have installed Jenkins Job DSL Plugin very > quickly (Thanks to

Re: Custom lifecycles

en bundled phase we just force using that one... But otherwise, yes we could blow up if there is a conflict... Though I like namespaces to auto-select the project module subset to run on > > my 2 cents, > Robert > > > Op Mon, 08 Feb 2016 23:33:54 +0100 schreef Stephen Connolly

Custom lifecycles

So I was thinking somewhat about the issues with custom lifecycles. One of the nice things I like about Maven is that the use of the standard lifecycles helps orientate new developers and prevents the sprawl of ANT targets. When I look at all the other build systems, what I keep missing in them

Re: Maven extensions

+1 On Tuesday 12 January 2016, Hervé BOUTEMY wrote: > installation level need to point to user space, in a per-user location (~, > or > ${user.home} if you prefer this syntax): then the user space is filled or > not, > user per user > > multi-user installation is exactly

Re: [DISCUSS] MDEPLOY-205: MavenProject with only attachments must have packaging "pom"

+1 On 11 January 2016 at 21:37, Robert Scholte wrote: > this might be the root cause: > > MINSTALL-41 [1]: > I have a project wich I need to build only specifying a classifier (in > detail: a war project which I need to build with different profiles to > include different

<    3   4   5   6   7   8   9   10   11   12   >