[GitHub] maven issue #116: Fix jsr-330 injection of DefaultArtifactDescriptorReader

[jdillon]

Github user jdillon commented on the issue:

https://github.com/apache/maven/pull/116
  
@ifedorenko howdy, i'm fine to wait if you are gonna adjust to jsr330 that 
will be better generally for the project anyways IMO; i'm just trying to learn 
how to use the api and can live with this change locally for now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #116: Fix jsr-330 injection of DefaultArtifactDescriptorReader

[ifedorenko]

Github user ifedorenko commented on the issue:

https://github.com/apache/maven/pull/116
  
I have a commit on a local branch that fully converts 
maven-resolver-provider to jsr330, I can push that to master if you can wait 
few days. Either way we'll need a JIRA to track the changes.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #116: Fix jsr-330 injection of DefaultArtifactDescriptorReader

[jdillon]

Github user jdillon commented on the issue:

https://github.com/apache/maven/pull/116
  
the plexus @Requirement injection is probably why this works at all in 
Maven, though w/o using maven-resolver-provider in a pure guice/sisu 
environment, this fails and causes NPE:

```
java.lang.NullPointerException
 at 
org.apache.maven.repository.internal.DefaultModelResolver.resolveModel 
(DefaultModelResolver.java:198)
 at 
org.apache.maven.model.building.DefaultModelBuilder.readParentExternally 
(DefaultModelBuilder.java:1051)
 at org.apache.maven.model.building.DefaultModelBuilder.readParent 
(DefaultModelBuilder.java:829)
 at org.apache.maven.model.building.DefaultModelBuilder.build 
(DefaultModelBuilder.java:331)
 at 
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom 
(DefaultArtifactDescriptorReader.java:321)
 at 
org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
 (DefaultArtifactDescriptorReader.java:199)
 at 
org.eclipse.aether.internal.impl.DefaultDependencyCollector.resolveCachedArtifactDescriptor
 (DefaultDependencyCollector.java:544)
 at 
org.eclipse.aether.internal.impl.DefaultDependencyCollector.getArtifactDescriptorResult
 (DefaultDependencyCollector.java:528)
 at 
org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency 
(DefaultDependencyCollector.java:418)
 at 
org.eclipse.aether.internal.impl.DefaultDependencyCollector.processDependency 
(DefaultDependencyCollector.java:372)
 at org.eclipse.aether.internal.impl.DefaultDependencyCollector.process 
(DefaultDependencyCollector.java:360)
 at 
org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies 
(DefaultDependencyCollector.java:263)
 at 
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies 
(DefaultRepositorySystem.java:325)
...
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven pull request #116: Fix jsr-330 injection of DefaultArtifactDescriptorR...

[jdillon]

GitHub user jdillon opened a pull request:

https://github.com/apache/maven/pull/116

Fix jsr-330 injection of DefaultArtifactDescriptorReader

... which is not setting the VersionRangeResolver; cause NPE when use w/o 
plexus requirement injection

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jdillon/maven 
DefaultArtifactDescriptorReader-injection-fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven/pull/116.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #116


commit 0c3f3a42262c5692742abc73042a1deece0898e0
Author: Jason Dillon 
Date:   2017-05-14T19:45:11Z

Fix jsr-330 injection of DefaultArtifactDescriptorReader; which was not 
setting the VersionRangeResolver




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Aldrin Leal]

This is quite similar to what "go get" does to golang. I'd say its worth a
try

On May 14, 2017 09:28, "Paul Hammant"  wrote:

> Article updated to eliminate misunderstandings and talk about a different
> index for 'maven central' too.
>
> - ph
>
> On Sat, May 13, 2017 at 3:04 PM, Paul Hammant  wrote:
>
> > I was discussing this of the list today, and it may interest people on
> dev@
> >
> > https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/
> >
> >  "Maven Central as multiple Git repositories"
> >
> > Enjoy,
> >
> > - Paul
> >
>

Re: [VOTE] Release Apache Maven Dependency Plugin version 3.0.1

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le jeudi 11 mai 2017, 23:30:29 CEST Karl Heinz Marbaise a écrit :
> Hi,
> 
> We solved 13 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227
> rsion=12338874
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MDEP%20AND%20stat
> us%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1338
> https://repository.apache.org/content/repositories/maven-1338/org/apache/mav
> en/plugins/maven-dependency-plugin/3.0.1/maven-dependency-plugin-3.0.1-sourc
> e-release.zip
> 
> Source release checksum(s):
> maven-dependency-plugin-3.0.1-source-release.zip sha1:
> c932c10fe7abcdcc406f5b49c60e23ed168156dc
> 
> Staging site:
> http://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

Article updated to eliminate misunderstandings and talk about a different
index for 'maven central' too.

- ph

On Sat, May 13, 2017 at 3:04 PM, Paul Hammant  wrote:

> I was discussing this of the list today, and it may interest people on dev@
>
> https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/
>
>  "Maven Central as multiple Git repositories"
>
> Enjoy,
>
> - Paul
>

Re: [VOTE] Release Apache Maven Dependency Plugin version 3.0.1

[Karl Heinz Marbaise]

Hi,

this is my +1

Kind regards
Karl Heinz Marbaise
On 11/05/17 23:30, Karl Heinz Marbaise wrote:

Hi,

We solved 13 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12338874


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MDEP%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC


Staging repo:
https://repository.apache.org/content/repositories/maven-1338
https://repository.apache.org/content/repositories/maven-1338/org/apache/maven/plugins/maven-dependency-plugin/3.0.1/maven-dependency-plugin-3.0.1-source-release.zip


Source release checksum(s):
maven-dependency-plugin-3.0.1-source-release.zip sha1:
c932c10fe7abcdcc406f5b49c60e23ed168156dc

Staging site:
http://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

[ ] +1
[ ] +0
[ ] -1


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [MNG-6169] Lifecycle/binding plugin version updates

[Michael Osipov]

Am 2017-05-14 um 09:33 schrieb Hervé BOUTEMY:

I don't understand what changed in Maven 3.1.0-alpha-1 that changed the
behaviour: did you find which issue was fixed?


Unfortunately not. Issue titles weren't helpful, commit messages also. I 
assume this is an Aether update.



Adding a pointer to that issue as comment (and not only in git commit message)
would be useful before merging so that this change is understood when reading
the code


Did update JIRA issues. I will go ahead and merge the commit.


Regards,

Hervé

Le dimanche 14 mai 2017, 00:25:10 CEST Michael Osipov a écrit :

I need to have a closer look at it through the Maven versions.


Tackled it. Any objections to merge
44ae63380768e53fab11ffb73131f201b268ed81 on Core ITs?

Michael



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [MNG-6169] Lifecycle/binding plugin version updates

[Hervé BOUTEMY]

thank you Robert: this is exactly the logic I was looking for, and explanation 
of changes over time to improve user experience through reproducibility.

Now the question is: should we change default plugin versions in Maven core?
Does it improve Maven or not?

To me, changing default plugin versions lowers reproducibility.
And it does not help users learn that they should define their own plugin 
versions instead of depending on the magic defaults that have to be included 
in Maven core to permit basic poms.

Then in general, if we have found a bug in a plugin with default version that 
hits users using this default basic poms, we should update the version: good 
default behaviour requirement surpasses reproducibility over Maven version 
expectation.

But if a plugin default version upgrade is just to have newer defaults, IMHO, 
we sacrifice reproducibility and teaching to users that basic poms are just a 
quick start but should soon be extended to manage explicitely plugins 
versions: is there a good reason to sacrifice this? I don't find any good 
reason: the sooner user discovers that he's using old plugins, the better. 

What we should give him are easy to discover and learn recipes to manage his 
plugin versions: for example through a basic neutral parent pom with newest 
plugins, or a BOM pom. Maybe there are other ideas.
Yes, neutral parent pom or BOM pom are to me good ways to improve Maven for 
users: not changing default plugin versions in Maven core.

Do I miss an aspect that should be taken into account?

Regards,

Hervé

Le samedi 13 mai 2017, 23:11:05 CEST Robert Scholte a écrit :
> >> If you are saying that depending on default version is a bad practice it
> >> actually means to me that this should change in the new major.
> >> Shouldn't it?
> > 
> > this is a bad practice from a very long time, even in the Maven 2.x
> > time: what
> > should change more in next Maven version that would show it more, without
> > breaking the magic that these defaults are used to? A warning message
> > proposing to add pluginManagement corresponding to current Maven version
> > used?
> > Or propose a parent pom to add?
> 
> IIRC up until Maven 2.0.8 there were no default plugin version, it was
> always selecting the latest when not specified. This was bad, because a
> new release of a plugin could suddenly make projects fail.
> Since Maven 2.0.9 there we started specifying default values to make
> everything more predictable.
> Right now we're also moving these information to the matching
> packaging-plugin, so the maven-jar-plugins specifies the lifecycle-plugins
> and their versions.
> So in the end we should only specify the packaging-plugins in Maven core.
> Ideally these should not be part of maven-core, but that will it harder to
> start using Maven. For that reason it will be likely that some plugins
> will still need to be specified with the Maven distribution.
> 
> Robert


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [MNG-6169] Lifecycle/binding plugin version updates

[Hervé BOUTEMY]

I don't understand what changed in Maven 3.1.0-alpha-1 that changed the 
behaviour: did you find which issue was fixed?

Adding a pointer to that issue as comment (and not only in git commit message) 
would be useful before merging so that this change is understood when reading 
the code

thanks for digging into this

Regards,

Hervé

Le dimanche 14 mai 2017, 00:25:10 CEST Michael Osipov a écrit :
> > I need to have a closer look at it through the Maven versions.
> 
> Tackled it. Any objections to merge
> 44ae63380768e53fab11ffb73131f201b268ed81 on Core ITs?
> 
> Michael
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org