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

[Paul Hammant]

One more repo:

https://github.com/paul-hammant/mc-xs-all/

One branch for each of classes, javadoc, sources, and poms

15 javadoc original versions: 24.1M

16 sources original versions: 4.9M

27 classes original versions: 8.4M

Afterwards git work the bare .git folder is: 8.4M

*77.5% saving on storage*

Any artifact, *including the poms,* can be pulled down via a single git
command

git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 --branch
TAGNAME

74 TAGNAMEs: classes-0.1, classes-0.2, classes-0.3, classes-0.5,
classes-0.6, classes-1.0, classes-1.0.1, classes-1.0.2, classes-1.1,
classes-1.1.1, classes-1.1.2, classes-1.1.3, classes-1.2, classes-1.2.1,
classes-1.2.2, classes-1.3, classes-1.3.1, classes-1.4, classes-1.4.1,
classes-1.4.2, classes-1.4.3, classes-1.4.4, classes-1.4.5, classes-1.4.6,
classes-1.4.7, classes-1.4.8, classes-1.4.9, javadoc-1.2, javadoc-1.2.1,
javadoc-1.2.2, javadoc-1.3, javadoc-1.3.1, javadoc-1.4, javadoc-1.4.1,
javadoc-1.4.2, javadoc-1.4.3, javadoc-1.4.4, javadoc-1.4.5, javadoc-1.4.6,
javadoc-1.4.7, javadoc-1.4.8, javadoc-1.4.9, pom-1.2, pom-1.2.1, pom-1.2.2,
pom-1.3, pom-1.3.1, pom-1.4, pom-1.4.1, pom-1.4.2, pom-1.4.3, pom-1.4.4,
pom-1.4.5, pom-1.4.6, pom-1.4.7, pom-1.4.8, pom-1.4.9, sources-1.1.3,
sources-1.2, sources-1.2.1, sources-1.2.2, sources-1.3, sources-1.3.1,
sources-1.4, sources-1.4.1, sources-1.4.2, sources-1.4.3, sources-1.4.4,
sources-1.4.5, sources-1.4.6, sources-1.4.7, sources-1.4.8, sources-1.4.9

 - Paul

[GitHub] maven issue #115: Change out JAVA_HOME. Add JRE used. JRE used print /jre an...

[marcelosv]

Github user marcelosv commented on the issue:

https://github.com/apache/maven/pull/115
  
ok. correct the code. :D


---
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 #115: Change out JAVA_HOME. Add JRE used. JRE used print /jre an...

[marcelosv]

Github user marcelosv commented on the issue:

https://github.com/apache/maven/pull/115
  
OK, i go change and correct


---
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: [MNG-6130] Loss of profile information in workaround for MNG-4900

[Michael Osipov]

Am 2017-05-15 um 22:10 schrieb Robert Scholte:

I think I miss a unittest or integration-test, just to be sure.


The reporter says: "It's very tricky and hopefully not necessary, since 
the 1-line fix is provided"


But you are right. This needs some verification.


On Mon, 15 May 2017 21:55:38 +0200, Michael Osipov 
wrote:


Who seconds 6130 for 3.5.1?

This is a one-line fix and all ITs pass.

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-6130] Loss of profile information in workaround for MNG-4900

[Robert Scholte]

I think I miss a unittest or integration-test, just to be sure.

On Mon, 15 May 2017 21:55:38 +0200, Michael Osipov   
wrote:



Who seconds 6130 for 3.5.1?

This is a one-line fix and all ITs pass.

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

[MNG-6130] Loss of profile information in workaround for MNG-4900

[Michael Osipov]

Who seconds 6130 for 3.5.1?

This is a one-line fix and all ITs pass.

Michael

-
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

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven/pull/116
  
@ifedorenko That's the only way w/o INFRA: commit message "This closes 
#xy". You cannot manually close via website. That's what I was trying to say.


---
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
  
@ifedorenko ftr I can close this, so but i'm confused about @michael-o 
comment that your change (I think that is what he meant) wasn't suitable for a 
patch release.  


---
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: Open Maven resolvers issue and release 1.1.0

[Robert Scholte]

IIRC 8, 9 and 10 change the current behavior of Maven a lot.

I think we should transform the use cases first to ITs based on  
mock-repository-manager, which should make it a lot easier to understand  
what's happening.

Next we need to decide what to change: code or documentation.

thanks,
Robert


On Mon, 15 May 2017 17:12:04 +0200, Michael Osipov   
wrote:



Hi folks,

what to do with the remaining issues (pre-reset? Here is the list:
MRESOLVER-3 Update dependencies
MRESOLVER-8 ScopeDependencySelector incorrectly de-selects direct  
dependencies
MRESOLVER-9 DefaultDependencyCollector does not correctly handle  
dependency management
MRESOLVER-10 New class 'TransitiveDependencyManager' supporting  
transitive dependency management.
MRESOLVER-12 Addition of unit tests for the various DependencySelector  
implementations to test things are working as documented.

MRESOLVER-15 Dependency updates

3 and 15 can be easily collapsed. What about the rest? I haven't yet  
tried anything against our Core ITs.


I also tested the current Resolver master against our Core ITs. They all  
pass.


What's next? Release 1.1.0 the way it is? Examine open issues?

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

[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
  
Wow. That's backwards. I wonder what will happen if I push my change with 
github's magic "fixes 116" pseudo comment. Guess there is one way to find out 
:-)


---
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

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven/pull/116
  
@ifedorenko Closing PRs requires a ticket with INFRA on JIRA.


---
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
  
Opened https://issues.apache.org/jira/browse/MNG-6233. If you any concerns 
or suggestions, I suggest we continue the discussion there.

@jdillon I can't close this pull request


---
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

Upgrading maven-release-plugin to maven-scm-api 1.9.5 ?

[Feblot, Alexandre]

Hi,
Jgit provider exposes password if it contains special characters : 
SCM-817 
(https://issues.apache.org/jira/browse/SCM-817) was fixed in maven-scm-api 
1.9.5 which was released in July 1st, 2016. maven-scm-api 1.9.6 has even been 
released since then.
However, maven-release-plugin has not been updated with it so far.
I found a waiting pull request  
(https://github.com/apache/maven-release/pull/7) doing this on github, but I 
don't know if/how this repository is monitored, as your doc page states your 
official repository is a svn one.
So my questions are:

* Is there any chance you release a maven-release-plugin 2.5.4 
depending on maven-scn-api 1.9.5 or 1.9.6 somedays in a not too far future?

* What more can be done to help this happen?

Thanks
--
Cordialement/Regards,

Alexandre Feblot
CM Buildmasters


"Misys" is the trade name of the Misys group of companies. This email and any 
attachments have been scanned for known viruses using multiple scanners. This 
email message is intended for the named recipient only. It may be privileged 
and/or confidential. If you are not the named recipient of this email please 
notify us immediately and do not copy it or use it for any purpose, nor 
disclose its contents to any other person. This email does not constitute the 
commencement of legal relations between you and Misys. Please refer to the 
executed contract between you and the relevant member of the Misys group for 
the identity of the contracting party with which you are dealing.

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

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven/pull/116
  
@jdillon Such a change is not suitable for a patch version in my opinion. 
Please file a JIRA issue for your local branch and push a branch for that.


---
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
  
@ifedorenko can close this if you like, wasn't sure what you mean about "a 
JIRA either way".  If we close this and go with your changes (which if you have 
that mostly done for merge soon is what I would suggest over this).  For now 
I'm assuming you'll merge you changes and file a JIRA, but if you need a JIRA 
specifically about this bug I can file it if you need.


---
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 #117: [MNG-5756] Java home output in mvn -v is misleading

[eis]

GitHub user eis opened a pull request:

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

[MNG-5756] Java home output in mvn -v is misleading

Renamed previous printing of JRE to "JRE used" and provided
separate mechanism to actually tell value of JAVA_HOME

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

$ git pull https://github.com/eis/maven jre-reporting-fix

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

https://github.com/apache/maven/pull/117.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 #117


commit d1911049823bd4ba5f695904500ab4cf2b16207c
Author: eis 
Date:   2017-05-15T15:58:40Z

[MNG-5756] Java home output in mvn -v is misleading

Renamed previous printing of JRE to "JRE used" and provided
separate mechanism to actually tell value of JAVA_HOME




---
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 #115: Change out JAVA_HOME. Add JRE used. JRE used print /jre an...

[eis]

Github user eis commented on the issue:

https://github.com/apache/maven/pull/115
  
Unfortunately it's not only line ending issue - you've changed the 
formatting on those files as well, so ignoring line endings (`?w=1`) the diff 
is still huge. It seems you've reformatted the entire files.


---
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

Open Maven resolvers issue and release 1.1.0

[Michael Osipov]

Hi folks,

what to do with the remaining issues (pre-reset? Here is the list:
MRESOLVER-3 Update dependencies
MRESOLVER-8 ScopeDependencySelector incorrectly de-selects direct 
dependencies
MRESOLVER-9 DefaultDependencyCollector does not correctly handle 
dependency management
MRESOLVER-10 New class 'TransitiveDependencyManager' supporting 
transitive dependency management.
MRESOLVER-12 Addition of unit tests for the various DependencySelector 
implementations to test things are working as documented.

MRESOLVER-15 Dependency updates

3 and 15 can be easily collapsed. What about the rest? I haven't yet 
tried anything against our Core ITs.


I also tested the current Resolver master against our Core ITs. They all 
pass.


What's next? Release 1.1.0 the way it is? Examine open issues?

Michael

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

Re: The maven-archetype-plugin paradox

[Amélie Deltour]

Sorry guys, but as a maven-archetype-plugin user I don't share your views on
this subject.

Of course, I totally agree with the aim of this new 3.x release and the idea to
be compliant with Maven3 behaviour and in particular the security features.
However, there have been quite a lot of complaints from users about regressions
with this new plugin version.
The ARCHETYPE-439 issue [1] you mention does not give much information about the
reasons of these complaints.
But you can see on ARCHETYPE-519 [2] comments that users *really* have a problem
with this release, in case you doubt it.

I will try to explain the use case.
In my company we have several Maven archetypes allowing to create quickly new
projects, with all our standard Maven setup and code skeleton.
We use these archetypes quite a lot.
The problem with the new release is the archetype *catalog*.
Indeed the plugin needs a catalog to be able to use an archetype to create a new
project.
In our case, we use our own private catalog stored in our internal artifacts
manager (Artifactory).
With maven-archetype-plugin 2.4 we used to refer to this catalog with the
-DarchetypeCatalog parameter.

Now with the 3.x plugin we do not have the ability to refer to our catalog any 
more.
The "remote" catalog represents the
http://repo.maven.apache.org/maven2/archetype-catalog.xml catalog file, as
explained in the doc [3].
But we don't want our archetypes to be published there...
Or am I completely mistaken and did I miss anything about the new plugin 
behaviour?

It is a good thing that the plugin now uses the Maven settings.xml, and only
these settings, to resolve the archetypes from the standard artifact repository
and associated settings, and not a custom archetype repository defined 
elsewhere.
But the plugin should have the same behaviour regarding the catalog, i.e. be
able to search the catalogs published in the repositories defined in
settings.xml, and not restrain the catalogs being searched to only the Maven
Central and local catalogs.

So we don't ask to keep the archetypeCatalog parameter, what we need is just a
way to keep a feature which is mandatory for us, the ability to use archetypes
defined in a catalog that is not published in Maven Central (and not available
locally on the machine either).
I am convinced from ARCHETYPE-519 that many users need this feature.
To my mind, the problem with the new plugin release is not a compatibility issue
(i.e. a different way to use or configure Maven), but really a break in
functionality i.e. a feature that is not available any more.

BTW, the documentation about the new behaviour is not as clear as you say, the
documentation still mentions "The Archetype Plugin can use catalogs from local
filesystem and from HTTP connections." and "The Archetype Plugin can also read
catalogs from filesystem/HTTP by providing the path/URL of a catalog file or of
a directory containing an archetype-catalog.xml file." [4]

I really hope you will understand the concern and do something about it, either
revert the plugin or implement something allowing to use private remote 
catalogs.
For the time being we need to stuck to the 2.4 version of the plugin but this is
not an acceptable solution for the long-term.

Regards,

Amélie

[1] https://issues.apache.org/jira/browse/ARCHETYPE-439
[2] https://issues.apache.org/jira/browse/ARCHETYPE-519
[3]
https://maven.apache.org/archetype/archetype-models/archetype-catalog/archetype-catalog.html
[4]
https://maven.apache.org/archetype/maven-archetype-plugin/specification/archetype-catalog.html

On 05/08/2017 07:38 PM, Robert Scholte wrote:

So we have this plugin, which has been released lately as requested by the
community.
It has been released as a 3.x, so it now requires Maven3 and with this
major release[1] we used this opportunity to break compatibility in case
there are parameters we don't want to use anymore.

One of the things changed is the usage of the reference to the archetype
repository. The original implementation was based on Maven2 and wasn't
using all security features as available in Maven3. This also made it hard
to maintain.
So for example, now it is picking up the artifact repository manager by
default, it'll use its credentials when required, etc.
By removing these parameters is should also be easier to use this plugin
(less parameters =ess chance of mistakes)

So I think we made quite some people happy now that things are working
much more according to Maven default behavior. However, other have issues
to use the archetype. Sometimes it is because they are using deprecated
parameters (or use parameters which should have been removed as well),
others have a local setup which now requires to add the repository to
their settings.xml.

I still think that ARCHETYPE-439[2] is valid, so I'd prefer not to revert.
Instead I hope we can find a solution which will fit better for the most.

I can think of the following solutions:
1. Continue with taken decision and further improve 

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

[Michael Osipov]

Am 2017-05-15 um 09:20 schrieb Stephen Connolly:

On Sun 14 May 2017 at 08:51, Hervé BOUTEMY  wrote:


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?



I think we should.

If we don't update, we have a more complex ux for new users.

We already say to pin versions (iirc we even log warnings)

If people choose to ignore the warnings of a build being at risk of
differential behaviour... they get what they configured: differential builds




To me, changing default plugin versions lowers reproducibility.



Which is why we warn users... and the warning is there *to allow us to
upgrade*



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.


We do not have two opposite opinions on this. What now, what to do with 
the branch?


Michael



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

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

[Michael Osipov]

Am 2017-05-11 um 23:30 schrieb Karl Heinz Marbaise:

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


A big +1


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

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

[Karl Heinz Marbaise]

Hi,

I need at least one more PMC vote..
(of course other VOTE's are appriciated)..

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: Silly Saturday idea - If Maven Central were a bunch of Git repos

[Paul Hammant]

There's one repo per thing that is versioned. All these are separate repos

g: com/thoughtworks/paranamer a: paranamer type: javadoc  is one repo
g: com/thoughtworks/paranamer a: paranamer type: sources  is one repo
g: com/thoughtworks/paranamer a: paranamer type: classes  is one repo
g: com/thoughtworks/xstream a: xstream type: javadoc  is one repo
g: com/thoughtworks/xstream a: xstream type: sources  is one repo
g: com/thoughtworks/xstream a: xstream type: classes  is one repo

Or you could do it in less repos, I'm sure, and Git will still make a
compression saving.

And despite what you said, Git manages to find some commonality in *binary
classes *to make a saving. XStream's regular JARs:

Total size for *27* original versions 8.4MB
The .git folder afterwards 2.4MB
Raw/bare storage space saving 71.4%
Your point about the git:// protocol being being more chatty that http://
is true. That's probably more CPU on the server side. It is definitely more
time. See here ...

Git takes 1s to do:

git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 --branch
1.4.3 --bare


Wget takes 0.5s to do:

wget http://central.maven.org/maven2/com/thoughtworks/
xstream/xstream/1.4.3/xstream-1.4.3.jar


On pom files - they are within the base Git repos, yes.  You can't get them
from the server to the client in one Git operation, without bringing at
least a whole tag. Maybe there could be a tag just for the POM file to make
it addressable remotely, and checkoutable locally. I'll test that later
today.

- Paul


On Mon, May 15, 2017 at 4:14 AM, Stian Soiland-Reyes 
wrote:



> Interesting idea! All for experimenting with git!
>
> You did not take into account the protocol differences, fetching a single
> 8MB  jar from Maven Central is easy, while fetching 6 MB via multiple git
> HTTP resources (even assuming git packs there will be multiple http calls)
> is probably more expensive, particularly as a typical project may have 50
> dependencies.
>
> Would each version be a new git repo? The binary class files are not really
> suitable for "diffing" and would pretty sure be changed every release (even
> if the SRC is the exact same).
>
> It is possible in JAR to use jar200 packing, which can significantly reduce
> the compressed size. Perhsps that is relevant here. See
> http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html
>
> Are the pom files within these git repositories or can they be prefetched
> separately like today to speed up transitive dependency loading?
>
>

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

[Stian Soiland-Reyes]

Interesting idea! All for experimenting with git!

You did not take into account the protocol differences, fetching a single
8MB  jar from Maven Central is easy, while fetching 6 MB via multiple git
HTTP resources (even assuming git packs there will be multiple http calls)
is probably more expensive, particularly as a typical project may have 50
dependencies.

Would each version be a new git repo? The binary class files are not really
suitable for "diffing" and would pretty sure be changed every release (even
if the SRC is the exact same).

It is possible in JAR to use jar200 packing, which can significantly reduce
the compressed size. Perhsps that is relevant here. See
http://docs.oracle.com/javase/7/docs/technotes/tools/share/pack200.html

Are the pom files within these git repositories or can they be prefetched
separately like today to speed up transitive dependency loading?



On 13 May 2017 8: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: [MNG-6169] Lifecycle/binding plugin version updates

[Stephen Connolly]

On Sun 14 May 2017 at 08:51, Hervé BOUTEMY  wrote:

> 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?


I think we should.

If we don't update, we have a more complex ux for new users.

We already say to pin versions (iirc we even log warnings)

If people choose to ignore the warnings of a build being at risk of
differential behaviour... they get what they configured: differential builds


>
> To me, changing default plugin versions lowers reproducibility.


Which is why we warn users... and the warning is there *to allow us to
upgrade*


> 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.


This sounds like an argument that we should add a CLI flag turn downgrade
the current warnings back to warnings and escalate them up to errors by
default.


>
> 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?


I've been through this path with Jenkins. My considered opinion is it is
better to just upgrade. We provide a path to lock down versions. We have
warned users for ages.

An alternative could be to leverage the prerequisites value as a selector
of the version defaults... though that would be re-enabling it for
non-plugin packaging ;-)


>
> 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
>
> --
Sent from my phone

Re: Several MRESOLVER issues

[Hervé BOUTEMY]

+1 for the 3 issues: good enhancements without risks

Regards,

Hervé

Le dimanche 14 mai 2017, 00:33:18 CEST Michael Osipov a écrit :
> Folks,
> 
> who seconds the following issues for Maven Resolver 1.1:
> 
> MRESOLVER-4: Use java.util.Objects#requireNonNull to intercept null input
> MRESOLVER-5: Update minimum Java version to 1.7
> MRESOLVER-6: Use java.nio.charset.StandardCharsets wherever possible
> 
> 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