Re: The maven-archetype-plugin paradox

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: The maven-archetype-plugin paradox

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




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 usage without extra
> parameters
> 2. Find somebody willing to maintain the plugin at ASF
> 3. Donate the plugin
> 4. Revert
> #3 is a serious option, because it seems that within the team there's
> nobody willing to maintain the plugin, probably due to other Maven
> sub-projects which have a higher priority.
> Any thoughts on this topic?
> Robert
> [1]
> [2]

Kelkoo SAS
Société par Actions Simplifiée
Au capital de € 4.168.964,30
Siège social : 158 Ter Rue du Temple 75003 Paris
425 093 069 RCS Paris

Ce message et les pièces jointes sont confidentiels et établis à l'attention exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce message, merci de le détruire et d'en avertir l'expéditeur.

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]