RE: Maven Developer Hangout

> Date: Fri, 4 Jul 2014 18:31:35 -0500 > Subject: Re: Maven Developer Hangout > From: pbened...@apache.org > To: dev@maven.apache.org > > The use of even with a symbolic id assumes there's only one > canonical location for the artifact. I don't think that's true and would > never want to be the

Re: Maven Developer Hangout

Removing Settings' mirror? we use it exclusively at work where we maintain a customize maven distribution with maven's conf/settings.xml has the mirror pointing to internal repository. I would be very much appreciated with Maven team can point me to a reference of this discussion that make Mirror

Re: Maven Developer Hangout

The use of even with a symbolic id assumes there's only one canonical location for the artifact. I don't think that's true and would never want to be the end-user who has to manage those symbolic ids. I still advocate removing this tag. I think it's the job of the intermediary (like Nexus) to writ

Re: [VOTE] Release Apache Maven Site Plugin version 3.4

+1 Op Fri, 04 Jul 2014 01:00:20 +0200 schreef Hervé BOUTEMY : Hi, We solved 13 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&styleName=Html&version=19228 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=tr

Re: Maven Developer Hangout

I fully agree on the SHA1 check and the repo manager protocol, but as long as we need the in the pom.xml, the repositoryId can help to optimize the searchpath for the artifacts. That would make the pom responsible for mapping dependency to the original repositoryUrl and the repository mana

Re: [VOTE] Release Apache Maven Site Plugin version 3.4

Hi Hervé checked SHA1 Ok. tested with several projects without an issue. so my +1 (non binding). Kind regards Karl-Heinz Marbaise Hi, We solved 13 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&styleName=Html&version=19228 There are still a couple of issues left i

Re: Maven Developer Hangout

If you consider the identity of the artifact to be its SHA1, theoretically it doesn't matter where it comes from. This is not to say that's optimal to go looking everywhere for an artifact. How this is constrained in Nexus is through routing rules where Nexus knows only to look for given groupId

RE: Maven Developer Hangout

Many is the time I wonder where did that dependency come from? I see the addition of a repositoryId attribute as an "essential feature" for aufgeregt sein auditing goal by maven-audit-plugin Good Idea Robert! +1 Martin _ > To: dev@maven.apache.org > Subject: Re: Maven Developer Hangout >

Re: Maven Developer Hangout

In addition to our hangout session: isn't it weird that for a dependency Maven can go over all the repositories, even though when an extra repository is added to the pom.xml, the developer knows exactly which dependencies should make use of that repository. To me it would make sense if you

Re: Question concerning Resolving an artifact within a plugin

Easiest way I know of is using Aether directly: https://github.com/eclipse/aether-demo/blob/master/aether-demo-snippets/src/main/java/org/eclipse/aether/examples/FindAvailableVersions.java This is predicated on their being intact Maven metadata for that particular artifact, which is in turn pred

Question concerning Resolving an artifact within a plugin

Hi, i have the following code which should resolve an artifact given GAV etc. so far so good... /** * The project currently being build. */ @Parameter( defaultValue = "${project}" ) private MavenProject mavenProject; /** * The current Maven session. */ @Pa

Re: [VOTE] Release Apache Maven Site Plugin version 3.4

+2 > Gesendet: Freitag, 04. Juli 2014 um 01:00 Uhr > Von: "Hervé BOUTEMY" > An: "Maven Developers List" > Betreff: [VOTE] Release Apache Maven Site Plugin version 3.4 > > Hi, > > We solved 13 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&styleName=Html&version=19228

Early Access builds for JDK 9 b21, JDK 8u20 b21 are available on java.net

Hi Robert,Kristian, Early Access builds for JDK 9 b21 and JDK 8u20 b21 are available on java.net. As we enter the later phases of development for JDK 8u20 , please log any show stoppers as soon as possible. Rgds, Ror