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

[Hervé BOUTEMY]

Le mardi 16 mai 2017, 22:20:35 CEST Stephen Connolly a écrit :
> On Tue 16 May 2017 at 22:40, Hervé BOUTEMY  wrote:
> > Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit :
> > > 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*
> > 
> > no, for these default plugin bindings, there is no warning, since the
> > default
> > binding defines a default version: that's the magic that happens with
> > minimal
> > poms.
> > 
> > The warning happens only when a new plugin is used without version.
> 
> Hmmm then that must have changed at some time because I am 99% certain that
> at some point in time there was a warning of plugins in the default
> lifecycle did not have a version specified...
> 
> But I recall at some point I lost the ability in the versions-m-p to detect
> that "normally" on the 3.x line (perhaps from 3.1.x onwards... I cannot
> recall)
as Robert explained, reproducibility was introduced in 2.0.9 (see MNG-3395, 
and the mecanism changed later to not be in super pom but in bindings): this 
removed the warning

just create a minimal pom with just groupId/artifactId/version and you'll see: 
no warning

> 
> I think we should restore those warnings then.
that's the whole complexity of ux: should we warn new users creating minimal 
poms? if not, when to warn them that minimal poms are just a fast track, that 
should rapidly be enhanced through a parent pom or an import?

Regards,

Hervé

> 
> > Then no, I don't see what "more complex ux" is there for new users.
> > This upgrade of default lifecycle plugin version looks to me just a big
> > misunderstanding on the expected benefit (or loss IMHO)
> > 
> > > > 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.
> > 
> > no, definitely not on default plugin bindings: this is a magic that not
> > many
> > people understand, and I don't think upgrading default version will
> > improve
> > this understanding.
> 
> Well if the warning was lost then yes, we would first need to restore the
> warning... then we can move to start upgrading again.
> 
> > > 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 ;-)
> > 
> 

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

[Stephen Connolly]

On Tue 16 May 2017 at 22:40, Hervé BOUTEMY  wrote:

> Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit :
> > 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*
> >
> no, for these default plugin bindings, there is no warning, since the
> default
> binding defines a default version: that's the magic that happens with
> minimal
> poms.
>
> The warning happens only when a new plugin is used without version.
>

Hmmm then that must have changed at some time because I am 99% certain that
at some point in time there was a warning of plugins in the default
lifecycle did not have a version specified...

But I recall at some point I lost the ability in the versions-m-p to detect
that "normally" on the 3.x line (perhaps from 3.1.x onwards... I cannot
recall)

I think we should restore those warnings then.


> Then no, I don't see what "more complex ux" is there for new users.
> This upgrade of default lifecycle plugin version looks to me just a big
> misunderstanding on the expected benefit (or loss IMHO)
>
> > > 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.
> no, definitely not on default plugin bindings: this is a magic that not
> many
> people understand, and I don't think upgrading default version will improve
> this understanding.
>

Well if the warning was lost then yes, we would first need to restore the
warning... then we can move to start upgrading again.


> >
> > 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 ;-)
> yes, this could be a solution: that would give a meaning to this
> prerequisites
> field in case of non-plugin packaging.
> But it would be more complex than just providing a parent pom, or an import
> pom


Yes... and we've just told everyone to stop using it... but I do see it as
a good solution.


>
> Regards,
>
> Hervé
>
> >
> > > 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 

[GitHub] maven issue #118: Upgrade SLF4J to 1.7.25

[hboutemy]

Github user hboutemy commented on the issue:

https://github.com/apache/maven/pull/118
  
AFAIK, you have colors on messages, but not on levels: the specific logger 
is necessary for levels.
It's also necessary for colored error rendering.
Just look at MavenSimpleLogger and you'll see exactly these 2 features in 
this class


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

[Hervé BOUTEMY]

this idea of putting everything in git is funny: not sure this will go very 
far from this poc, but let's imagine...

on classes branch, splitting the jar into individual .class has IMHO a big 
drawback: we loose original jar and its signature

On the other branches, the current poc shows commits for versions that are 
perfectly linear: if there are multiple branches that are released in 
parallel, the commit won't be so clean. I don't know if this will have an 
impact on compression efficiency.

Another issue with this idea: during development, with SNAPSHOTs, the git repo 
will be polluted: this idea IMHO could only be valid for releases

not to speak about read concurrency when one requires to use multiple versions 
of a lib. And of course, write concurrency is even harder.


Definitely, the idea is funny, but I don't see how this could go very far than 
this funny idea (in addition to the complexity for implementing this format in 
tooling)

Regards,

Hervé

Le lundi 15 mai 2017, 21:45:00 CEST Paul Hammant a écrit :
> 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



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

Le lundi 15 mai 2017, 07:20:08 CEST Stephen Connolly a écrit :
> 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*
> 
no, for these default plugin bindings, there is no warning, since the default 
binding defines a default version: that's the magic that happens with minimal 
poms.

The warning happens only when a new plugin is used without version.

Then no, I don't see what "more complex ux" is there for new users.
This upgrade of default lifecycle plugin version looks to me just a big 
misunderstanding on the expected benefit (or loss IMHO)

> > 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.
no, definitely not on default plugin bindings: this is a magic that not many 
people understand, and I don't think upgrading default version will improve 
this understanding.

> 
> 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 ;-)
yes, this could be a solution: that would give a meaning to this prerequisites 
field in case of non-plugin packaging.
But it would be more complex than just providing a parent pom, or an import 
pom

Regards,

Hervé

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

maven-compiler-plugin + maven-invoker-plugin

[Robert Scholte]

Hi,

Just a pre-announcement: I'd like to release these plugins within a couple  
of days.


maven-compiler-plugin is required because for Java9 a flag required for  
testing has been replaced. The old flag is now removed, so some Jigsaw  
testers are blocked.


maven-invoker-plugin will be a 3.0.0, meaning Maven2 support has been  
dropped.


please have a look at these plugins to see if they are ready to go.

thanks,
Robert

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

Re: [MNG-6167] Clean up dependency mess (reported by dependency:analyze)

[Stephen Connolly]

On 16 May 2017 at 06:53, Michael Osipov  wrote:

> MNG-6167


+1

Re: Releases for Maven Dependency Plugin / Maven Deploy Plugin

[Robert Scholte]

Hi Karl Heinz,

regarding both install/deploy plugin in combination with  
artifact-transfer: we should somehow make this a 2-phase strategy in the  
future: first phase upload pom, main artifact and attached artifacts (in  
parallel when possible), second phase download + upload metadata files. I  
don't think the current implementation does like this, I'm not even sure  
what the strategy was before.

Please verify if this is possible before releasing.

thanks,
Robert


On Sun, 07 May 2017 15:55:21 +0200, Karl Heinz Marbaise  
 wrote:



Hi to all,

after maven-artifact-transfer 0.9.1 is done

I will go forward to make a release of:

maven-dependency-plugin 3.0.1 which contains a Java 8 fix
and afterwards I will go further to release

maven-deploy-plugin version 3.0.0

this is my plan...

If there are no objections...

Kind regards
Karl Heinz

-
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

[ANN] Apache Maven Dependency Plugin Version 3.0.1 Released

[Karl Heinz Marbaise]

The Apache Maven team is pleased to announce the release of the 
Apache Maven Dependency Plugin Version 3.0.1.
 
https://maven.apache.org/plugins/maven-dependency-plugin/

Important Note since 3.0.0:

 * Maven 3.X only
 * JDK 6 minimum requirement

You should specify the version in your project's plugin configuration:
 

  org.apache.maven.plugins
  maven-dependency-plugin
  3.0.1


You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/plugins/maven-dependency-plugin/download.cgi
 
Release Notes Maven Dependency Plugin 3.0.0

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

Bugs:

 * [MDEP-409] - dependency:tree fails for a multi-module project where one 
module depends on another and "mvn install" has not been run yet
 * [MDEP-419] - dependency:list, dependency:build-classpath and dependency:tree 
result with the different dependencies order
 * [MDEP-428] - Unpack goal does not fail build when destination could not be 
created and unpacks to current working directory instead
 * [MDEP-471] - Java 8 Method references are not detected
 * [MDEP-548] - The get Mojo doesn't resolve the artifact when setting 
transitive to false
 * [MDEP-565] - Upgrade maven-artifact-transfer to version 0.9.1

Documentation:

 * [MDEP-534] - Document format of mojo parameter 'artifact'

Improvements:

 * [MDEP-482] - Can't use both outputProperty and outputFile in build-classpath 
mojo
 * [MDEP-563] - Print dependency:resolve-plugins output just like other goal 
output
 * [MDEP-566] - Upgrade maven-common-artifact-filter to version 3.0.1
 * [MDEP-567] - Upgrade to maven-dependency-tree to 3.0.1

New Feature:
 * [MDEP-500] - Print GAV information in console output during 
dependency:resolve-plugins execution

Task:

 * [MDEP-547] - Remove some old (404) links from site

Reporters of this Release:

 * Elias Elmqvist Wulcan [MDEP-534]
 * Andrew Wright [MDEP-500]
 * Dagan Sandler [MDEP-482]
 * Ben Hardy [MDEP-471]
 * Dave Moten [MDEP-428]
 * Julien Boulay [MDEP-419]
 * Eric Pabst [MDEP-409]

Many thanks to all reporters/contributors/testers of this release.

Enjos,
 
-The Apache Maven team

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

On Tue, 16 May 2017 19:00:14 +0200, Michael Osipov   
wrote:



Am 2017-05-15 um 20:57 schrieb 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.


Right, I will pick up the dependency updates have this seconded by  
someone and start 1.1.0 release.




Seconded by me, looks fine to me.

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





-
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: The maven-archetype-plugin paradox

[Anders Hammar]

> The more I think about it, the more I'm convinced we should also remove
> the archetypeCatalog parameter. Right now it is only causing confusion.
>

Yes, you're probably right. It should just work - you shouldn't have to
specify what sort of catalog to be used.

/Anders


> Does it still make sense to have "internal", which are in fact a small set
> of embedded archetypes, and they are old (and remote available as well)?
> Aether/Artifact Resolver should solve the rest: use both remote and local
> as everybody is used to. Want to only use local, then I guess you should
> add --offline.
>
> WDYT?
>
> Robert
>
> [1] https://issues.apache.org/jira/browse/ARCHETYPE-520
>
> On Tue, 16 May 2017 13:02:11 +0200, Anders Hammar 
> wrote:
>
> I would expect "remote" not be the central repo but what repo(s) (or
>> mirrors) are configured in settings.xml.
>>
>> Robert, what's your view of how this works in the plugin now?
>>
>> /Anders
>>
>> On Tue, May 16, 2017 at 11:06 AM, Amélie Deltour <
>> amelie.delt...@kelkoo.com>
>> wrote:
>>
>> Hi Anders,
>>>
>>> Thanks for your clarification.
>>> In understand well the idea behind the 3.x version and the concern for
>>> more security and avoid to fetch anything directly from the Internet.
>>> Every
>>> "external" access should go throud the repositories configured in the
>>> Maven
>>> settings.xml, I completely agree with this, and this was indeed a flaw in
>>> the 2.x version of the plugin.
>>>
>>> However, with the 3.x version, there are only 3 possible sources for the
>>> archetype catalog [1]:
>>> - "remote": this is atually Maven Central i.e. the
>>> http://repo.maven.apache.org/maven2/archetype-catalog.xml catalog
>>> - "local": the local Maven repository on the user's machine
>>> - "internal": the plugin's internal catalog
>>>
>>> None of these is suitable for our case.
>>> What we need is to use a catalog hosted on our internal repository
>>> manager
>>> i.e. http://myrepo.mycompany/archetype-catalog.xml and unless I am
>>> completely mistaken this is not possible anymore.
>>> Although the repository manager is well configured in the Maven settings,
>>> it is used for fetching dependencies, is is used to fetch the archetype
>>> artifacts themselves, but no way to use it for the catalog.
>>> So using our own internal catalog hosted on our own internal repository
>>> is
>>> just not possible anymore.
>>> Several users report the same issue in the ARCHETYPE-519 issue.
>>>
>>> To my mind, the possibility to use an "alternative" catalog is an
>>> important feature of the plugin that should not be removed in the 3.x
>>> version.
>>> I totally agree that the alternative catalog should not be configured as
>>> a
>>> direct URL in the CI, the 2.x way to do it was not the right way.
>>> But there should still be a way to have it configured via Maven
>>> settings.xml.
>>>
>>> Do you think my concern is valid?
>>>
>>> Amélie
>>>
>>> [1] http://maven.apache.org/archetype/maven-archetype-plugin/
>>> examples/generate-alternative-catalog.html
>>>
>>> On 05/16/2017 08:56 AM, Anders Hammar wrote:
>>>
>>> Amélie,
>>>
>>> Thanks for describing your use case here on the list! As I am one of the
>>> reporters for the tickets behind the change in question I'd like to
>>> describe my reasoning:
>>>
>>> First off, your use case is actually (if I understand it correctly)
>>> standard for Maven usage. For a company environment I expect that central
>>> repo (and any other external repo) to be proxied by a repo manager and
>>> Maven should be configured to use the internal repo manager as mirror for
>>> e.g. central. The idea is that Maven should NEVER go out on the Internet
>>> to
>>> fetch artifacts (and archetypes are in fact artifacts).
>>>
>>> However, the archetype maven plugin didn't cope well with that setup.
>>> Regardless of a correctly Maven configuration it would reach out to the
>>> Internet in many cases. And if you specified an archetype catalog via the
>>> CLI param it would then often go out to the Internet to download the
>>> archetype itself. It just didn't follow the Maven idea of convention over
>>> configuration but the users had to do workarounds to get things to work
>>> (like specifying the archetype catalog on the CLI although it actually
>>> existed in there internal repo manager). If there was security (auth)
>>> involved with the repos it got even more messy.
>>>
>>> This we wanted to fix to simplify for our users. Possibly, not everything
>>> worked out perfectly in v3.0.0 and there might be some bugs and I know
>>> Robert has done some changes in this area in the upcoming v3.0.1.
>>> Unfortunately I haven't had the time to verify and test this but I invite
>>> you to help out by testing SNAPSHOT versions while changes are applied or
>>> participate in the actual vote. By doing so you will ensure that your
>>> actual use case is covered.
>>>
>>> /Anders
>>>
>>> On Mon, May 15, 2017 at 4:42 PM, Amélie Deltour <
>>> amelie.delt...@kelkoo.com
>>> 

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

[Karl Heinz Marbaise]

Hi,

The vote has passed with the following result:

+1 : Hervé Boutemy, Michael Osipov, Karl Heinz Marbaise

PMC quorum: reached.

I will promote the artifacts to the central repo.

Kind regards
Karl Heinz Marbaise

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

[GitHub] maven-release pull request #7: Upgraded to maven-scm-api 1.9.5

[llebegue]

Github user llebegue closed the pull request at:

https://github.com/apache/maven-release/pull/7


---
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: The maven-archetype-plugin paradox

[Robert Scholte]

Looks like ARCHETYPE-520[1] to me. I've created an integration-test for  
it, so that should work with 3.0.1


The more I think about it, the more I'm convinced we should also remove  
the archetypeCatalog parameter. Right now it is only causing confusion.
Does it still make sense to have "internal", which are in fact a small set  
of embedded archetypes, and they are old (and remote available as well)?
Aether/Artifact Resolver should solve the rest: use both remote and local  
as everybody is used to. Want to only use local, then I guess you should  
add --offline.


WDYT?

Robert

[1] https://issues.apache.org/jira/browse/ARCHETYPE-520

On Tue, 16 May 2017 13:02:11 +0200, Anders Hammar   
wrote:



I would expect "remote" not be the central repo but what repo(s) (or
mirrors) are configured in settings.xml.

Robert, what's your view of how this works in the plugin now?

/Anders

On Tue, May 16, 2017 at 11:06 AM, Amélie Deltour  


wrote:


Hi Anders,

Thanks for your clarification.
In understand well the idea behind the 3.x version and the concern for
more security and avoid to fetch anything directly from the Internet.  
Every
"external" access should go throud the repositories configured in the  
Maven
settings.xml, I completely agree with this, and this was indeed a flaw  
in

the 2.x version of the plugin.

However, with the 3.x version, there are only 3 possible sources for the
archetype catalog [1]:
- "remote": this is atually Maven Central i.e. the
http://repo.maven.apache.org/maven2/archetype-catalog.xml catalog
- "local": the local Maven repository on the user's machine
- "internal": the plugin's internal catalog

None of these is suitable for our case.
What we need is to use a catalog hosted on our internal repository  
manager

i.e. http://myrepo.mycompany/archetype-catalog.xml and unless I am
completely mistaken this is not possible anymore.
Although the repository manager is well configured in the Maven  
settings,

it is used for fetching dependencies, is is used to fetch the archetype
artifacts themselves, but no way to use it for the catalog.
So using our own internal catalog hosted on our own internal repository  
is

just not possible anymore.
Several users report the same issue in the ARCHETYPE-519 issue.

To my mind, the possibility to use an "alternative" catalog is an
important feature of the plugin that should not be removed in the 3.x
version.
I totally agree that the alternative catalog should not be configured  
as a

direct URL in the CI, the 2.x way to do it was not the right way.
But there should still be a way to have it configured via Maven
settings.xml.

Do you think my concern is valid?

Amélie

[1] http://maven.apache.org/archetype/maven-archetype-plugin/
examples/generate-alternative-catalog.html

On 05/16/2017 08:56 AM, Anders Hammar wrote:

Amélie,

Thanks for describing your use case here on the list! As I am one of the
reporters for the tickets behind the change in question I'd like to
describe my reasoning:

First off, your use case is actually (if I understand it correctly)
standard for Maven usage. For a company environment I expect that  
central

repo (and any other external repo) to be proxied by a repo manager and
Maven should be configured to use the internal repo manager as mirror  
for
e.g. central. The idea is that Maven should NEVER go out on the  
Internet to

fetch artifacts (and archetypes are in fact artifacts).

However, the archetype maven plugin didn't cope well with that setup.
Regardless of a correctly Maven configuration it would reach out to the
Internet in many cases. And if you specified an archetype catalog via  
the

CLI param it would then often go out to the Internet to download the
archetype itself. It just didn't follow the Maven idea of convention  
over

configuration but the users had to do workarounds to get things to work
(like specifying the archetype catalog on the CLI although it actually
existed in there internal repo manager). If there was security (auth)
involved with the repos it got even more messy.

This we wanted to fix to simplify for our users. Possibly, not  
everything

worked out perfectly in v3.0.0 and there might be some bugs and I know
Robert has done some changes in this area in the upcoming v3.0.1.
Unfortunately I haven't had the time to verify and test this but I  
invite
you to help out by testing SNAPSHOT versions while changes are applied  
or

participate in the actual vote. By doing so you will ensure that your
actual use case is covered.

/Anders

On Mon, May 15, 2017 at 4:42 PM, Amélie Deltour  

wrote:



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 

Re: Open Maven resolvers issue and release 1.1.0

[Michael Osipov]

Am 2017-05-15 um 20:57 schrieb 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.


Right, I will pick up the dependency updates have this seconded by 
someone and start 1.1.0 release.



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





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

[GitHub] maven issue #118: Upgrade SLF4J to 1.7.25

[ebourg]

Github user ebourg commented on the issue:

https://github.com/apache/maven/pull/118
  
Is the StaticLoggerBinder implementation necessary? I built Maven without 
and it seemed to work, the resulting version was able to build a couple of 
random projects and the console output was colored.


---
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: [VOTE] Release Apache Maven Dependency Plugin version 3.0.1

[Michael Osipov]

Karl Heinz,

the vote is over, do you want to continue with the release?

Michael

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

[MNG-6167] Clean up dependency mess (reported by dependency:analyze)

[Michael Osipov]

Who seconds MNG-6167 for 3.5.1?

All ITs pass locally and on Jenkins.

Michael

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

[GitHub] maven pull request #118: Upgrade SLF4J to 1.7.25 and expelled the groovy mon...

[ebourg]

GitHub user ebourg opened a pull request:

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

Upgrade SLF4J to 1.7.25 and expelled the groovy monkey

The changes to SLF4J required to support maven-slf4j-provider have been 
[released ](https://jira.qos.ch/browse/SLF4J-394) in the version 1.7.25. If I'm 
not mistaken it should be possible to remove the patching tweak now.

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

$ git pull https://github.com/ebourg/maven master

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

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


commit c0de5b5720626a21544c374018af922e793f4a88
Author: Emmanuel Bourg 
Date:   2017-05-16T13:30:29Z

Upgraded SLF4J to 1.7.25 and expelled the groovy monkey




---
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: The maven-archetype-plugin paradox

[Anders Hammar]

I would expect "remote" not be the central repo but what repo(s) (or
mirrors) are configured in settings.xml.

Robert, what's your view of how this works in the plugin now?

/Anders

On Tue, May 16, 2017 at 11:06 AM, Amélie Deltour 
wrote:

> Hi Anders,
>
> Thanks for your clarification.
> In understand well the idea behind the 3.x version and the concern for
> more security and avoid to fetch anything directly from the Internet. Every
> "external" access should go throud the repositories configured in the Maven
> settings.xml, I completely agree with this, and this was indeed a flaw in
> the 2.x version of the plugin.
>
> However, with the 3.x version, there are only 3 possible sources for the
> archetype catalog [1]:
> - "remote": this is atually Maven Central i.e. the
> http://repo.maven.apache.org/maven2/archetype-catalog.xml catalog
> - "local": the local Maven repository on the user's machine
> - "internal": the plugin's internal catalog
>
> None of these is suitable for our case.
> What we need is to use a catalog hosted on our internal repository manager
> i.e. http://myrepo.mycompany/archetype-catalog.xml and unless I am
> completely mistaken this is not possible anymore.
> Although the repository manager is well configured in the Maven settings,
> it is used for fetching dependencies, is is used to fetch the archetype
> artifacts themselves, but no way to use it for the catalog.
> So using our own internal catalog hosted on our own internal repository is
> just not possible anymore.
> Several users report the same issue in the ARCHETYPE-519 issue.
>
> To my mind, the possibility to use an "alternative" catalog is an
> important feature of the plugin that should not be removed in the 3.x
> version.
> I totally agree that the alternative catalog should not be configured as a
> direct URL in the CI, the 2.x way to do it was not the right way.
> But there should still be a way to have it configured via Maven
> settings.xml.
>
> Do you think my concern is valid?
>
> Amélie
>
> [1] http://maven.apache.org/archetype/maven-archetype-plugin/
> examples/generate-alternative-catalog.html
>
> On 05/16/2017 08:56 AM, Anders Hammar wrote:
>
> Amélie,
>
> Thanks for describing your use case here on the list! As I am one of the
> reporters for the tickets behind the change in question I'd like to
> describe my reasoning:
>
> First off, your use case is actually (if I understand it correctly)
> standard for Maven usage. For a company environment I expect that central
> repo (and any other external repo) to be proxied by a repo manager and
> Maven should be configured to use the internal repo manager as mirror for
> e.g. central. The idea is that Maven should NEVER go out on the Internet to
> fetch artifacts (and archetypes are in fact artifacts).
>
> However, the archetype maven plugin didn't cope well with that setup.
> Regardless of a correctly Maven configuration it would reach out to the
> Internet in many cases. And if you specified an archetype catalog via the
> CLI param it would then often go out to the Internet to download the
> archetype itself. It just didn't follow the Maven idea of convention over
> configuration but the users had to do workarounds to get things to work
> (like specifying the archetype catalog on the CLI although it actually
> existed in there internal repo manager). If there was security (auth)
> involved with the repos it got even more messy.
>
> This we wanted to fix to simplify for our users. Possibly, not everything
> worked out perfectly in v3.0.0 and there might be some bugs and I know
> Robert has done some changes in this area in the upcoming v3.0.1.
> Unfortunately I haven't had the time to verify and test this but I invite
> you to help out by testing SNAPSHOT versions while changes are applied or
> participate in the actual vote. By doing so you will ensure that your
> actual use case is covered.
>
> /Anders
>
> On Mon, May 15, 2017 at 4:42 PM, Amélie Deltour  >
> wrote:
>
>
>
> 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 

Re: The maven-archetype-plugin paradox

[Amélie Deltour]

Hi Anders,

Thanks for your clarification.
In understand well the idea behind the 3.x version and the concern for more security and 
avoid to fetch anything directly from the Internet. Every "external" access 
should go throud the repositories configured in the Maven settings.xml, I completely 
agree with this, and this was indeed a flaw in the 2.x version of the plugin.

However, with the 3.x version, there are only 3 possible sources for the 
archetype catalog [1]:
- "remote": this is atually Maven Central i.e. the 
http://repo.maven.apache.org/maven2/archetype-catalog.xml catalog
- "local": the local Maven repository on the user's machine
- "internal": the plugin's internal catalog

None of these is suitable for our case.
What we need is to use a catalog hosted on our internal repository manager i.e. 
http://myrepo.mycompany/archetype-catalog.xml and unless I am completely 
mistaken this is not possible anymore.
Although the repository manager is well configured in the Maven settings, it is 
used for fetching dependencies, is is used to fetch the archetype artifacts 
themselves, but no way to use it for the catalog.
So using our own internal catalog hosted on our own internal repository is just 
not possible anymore.
Several users report the same issue in the ARCHETYPE-519 issue.

To my mind, the possibility to use an "alternative" catalog is an important 
feature of the plugin that should not be removed in the 3.x version.
I totally agree that the alternative catalog should not be configured as a 
direct URL in the CI, the 2.x way to do it was not the right way.
But there should still be a way to have it configured via Maven settings.xml.

Do you think my concern is valid?

Amélie

[1] 
http://maven.apache.org/archetype/maven-archetype-plugin/examples/generate-alternative-catalog.html

On 05/16/2017 08:56 AM, Anders Hammar wrote:

Amélie,

Thanks for describing your use case here on the list! As I am one of the
reporters for the tickets behind the change in question I'd like to
describe my reasoning:

First off, your use case is actually (if I understand it correctly)
standard for Maven usage. For a company environment I expect that central
repo (and any other external repo) to be proxied by a repo manager and
Maven should be configured to use the internal repo manager as mirror for
e.g. central. The idea is that Maven should NEVER go out on the Internet to
fetch artifacts (and archetypes are in fact artifacts).

However, the archetype maven plugin didn't cope well with that setup.
Regardless of a correctly Maven configuration it would reach out to the
Internet in many cases. And if you specified an archetype catalog via the
CLI param it would then often go out to the Internet to download the
archetype itself. It just didn't follow the Maven idea of convention over
configuration but the users had to do workarounds to get things to work
(like specifying the archetype catalog on the CLI although it actually
existed in there internal repo manager). If there was security (auth)
involved with the repos it got even more messy.

This we wanted to fix to simplify for our users. Possibly, not everything
worked out perfectly in v3.0.0 and there might be some bugs and I know
Robert has done some changes in this area in the upcoming v3.0.1.
Unfortunately I haven't had the time to verify and test this but I invite
you to help out by testing SNAPSHOT versions while changes are applied or
participate in the actual vote. By doing so you will ensure that your
actual use case is covered.

/Anders

On Mon, May 15, 2017 at 4:42 PM, Amélie Deltour 

wrote:



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

Re: The maven-archetype-plugin paradox

[Anders Hammar]

Amélie,

Thanks for describing your use case here on the list! As I am one of the
reporters for the tickets behind the change in question I'd like to
describe my reasoning:

First off, your use case is actually (if I understand it correctly)
standard for Maven usage. For a company environment I expect that central
repo (and any other external repo) to be proxied by a repo manager and
Maven should be configured to use the internal repo manager as mirror for
e.g. central. The idea is that Maven should NEVER go out on the Internet to
fetch artifacts (and archetypes are in fact artifacts).

However, the archetype maven plugin didn't cope well with that setup.
Regardless of a correctly Maven configuration it would reach out to the
Internet in many cases. And if you specified an archetype catalog via the
CLI param it would then often go out to the Internet to download the
archetype itself. It just didn't follow the Maven idea of convention over
configuration but the users had to do workarounds to get things to work
(like specifying the archetype catalog on the CLI although it actually
existed in there internal repo manager). If there was security (auth)
involved with the repos it got even more messy.

This we wanted to fix to simplify for our users. Possibly, not everything
worked out perfectly in v3.0.0 and there might be some bugs and I know
Robert has done some changes in this area in the upcoming v3.0.1.
Unfortunately I haven't had the time to verify and test this but I invite
you to help out by testing SNAPSHOT versions while changes are applied or
participate in the actual vote. By doing so you will ensure that your
actual use case is covered.

/Anders

On Mon, May 15, 2017 at 4:42 PM, Amélie Deltour 
wrote:

> 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