Re: The maven-archetype-plugin paradox

[Robert Scholte]

Looks like https://issues.apache.org/jira/browse/ARCHETYPE-528

With mirror this seems to work as expected, but without is uses Central to  
look for the catalog.

So that's a bug.

Robert

On Mon, 22 May 2017 17:53:36 +0200, Amélie Deltour  
 wrote:


(the catalog is located at  
http://artifactory.mycompany.com/internal-releases/archetype-catalog.xml)


On 05/22/2017 05:52 PM, Amélie Deltour wrote:
Hi,

Thanks for the link, I could not find where this "archetype" repository  
was documented.


However, I tried to use the "archetype" repository earlier, and tried  
again, and I can't make it work.


With 2.4: mvn  
org.apache.maven.plugins:maven-archetype-plugin:2.4:generate  
-DarchetypeGroupId=com.mycompany.archetype  
-DarchetypeArtifactId=myCustomArchetype  
-DarchetypeCatalog=http://artifactory.mycompany.com/internal-releases/

=> it works fine (that's what we used to do)

With 3.0: mvn  
org.apache.maven.plugins:maven-archetype-plugin:3.0.0:generate  
-DarchetypeGroupId=com.mycompany.archetype  
-DarchetypeArtifactId=myCustomArchetype
=> does not work - I get "[WARNING] Specified archetype not found." and  
I am proposed the list of archetypes from Maven central

Tried with both 3.0 and 3.0.1.

Attached is my full settings.xml.

Can you explain what is wrong with these settings?
(or if this is not the right place to ask, please tell me where to ask)

Amélie

On 05/19/2017 09:54 PM, Robert Scholte wrote:

Hi Amélie,

first thank you for helping to us to improve this and to get more
information about the several use cases.

If you have a repository in the settings.xml, it must be inside a  
profile.

This would mean that it looks more like you have to do this:
https://maven.apache.org/archetype/maven-archetype-plugin/archetype-repository.html

Right now it is required to call the repository "archetype" which also
prevents Maven from going over all repositories and trying to fetch all
catalogs.

I assume the name "archetype" is not a real issue since you need to
activate a profile, but if there are good reasons to change this, we
should have another look at it.

thanks,
Robert

On Thu, 18 May 2017 16:58:47 +0200, Amélie Deltour
 wrote:



ARCHETYPE-520 (and ARCHETYPE-358) are indeed close to the problem I try
to describe, but not exactly the same.
These issues are about using the mirror configuration to access
archetype data, i.e. using
http://myrepo.mycompany/maven/archetype-catalog.xml instead of direct
access to http://repo1.maven.org/maven2/archetype-catalog.xml, but this
is still the Maven central catalog, just accessed through a mirror
instead of accessing it directly.

But my issue, and the issue behind most ARCHETYPE-519 comments, is not a
mirror issue, it is not either a CLI vs settings.xml issue, it is about
the ability to use an *alternative catalog* which is not published on
Maven central.

In my settings.xml I have several repositories defined:


  internal
  repository for internal artifacts
  http://myrepo.mycompany/internal
  ...


  central
  repository for external artifacts
  http://myrepo.mycompany/external
  ...




With 3.x it seems that the "remote" catalog uses the catalog located at
http://myrepo.mycompany/external/archetype-catalog.xml (which is a proxy
for Maven central catalog) but we need the catalog published at
http://myrepo.mycompany/internal/archetype-catalog.xml to be used as
well and this one is ignored.
That's to say, "remote" is interpreted as the "central" repository only,
and other repositories configured in settings.xml are ignored.

This is what I call an "alternative catalog" and I think it is a valid
use case for the plugin.
This was possible with the archetypeCatalog CLI parameter (giving the
catalog URL), and it is probably what the parameter was meant for.
But is not possible anymore with 3.x.
I agree the CLI parameter can be removed, *but* the other repositories
defined in settings.xml have to be taken into account when searching for
remote archetype catalogs.

Please confirm if my use case is valid - in that case I think
ARCHETYPE-519 should be reopend or I can open a new issue if you think
it is more appropriate.
Or I misunderstood / misconfigured something: if my Maven configuration
or usage is wrong I would be glad to understand what's wrong and why.

Thanks,

Amélie


On 05/16/2017 07:06 PM, Robert Scholte wrote:

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

Re: The maven-archetype-plugin paradox

[Amélie Deltour]

(the catalog is located at 
http://artifactory.mycompany.com/internal-releases/archetype-catalog.xml)

On 05/22/2017 05:52 PM, Amélie Deltour wrote:
Hi,

Thanks for the link, I could not find where this "archetype" repository was 
documented.

However, I tried to use the "archetype" repository earlier, and tried again, 
and I can't make it work.

With 2.4: mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate 
-DarchetypeGroupId=com.mycompany.archetype -DarchetypeArtifactId=myCustomArchetype 
-DarchetypeCatalog=http://artifactory.mycompany.com/internal-releases/
=> it works fine (that's what we used to do)

With 3.0: mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.0:generate 
-DarchetypeGroupId=com.mycompany.archetype 
-DarchetypeArtifactId=myCustomArchetype
=> does not work - I get "[WARNING] Specified archetype not found." and I am 
proposed the list of archetypes from Maven central
Tried with both 3.0 and 3.0.1.

Attached is my full settings.xml.

Can you explain what is wrong with these settings?
(or if this is not the right place to ask, please tell me where to ask)

Amélie

On 05/19/2017 09:54 PM, Robert Scholte wrote:

Hi Amélie,

first thank you for helping to us to improve this and to get more
information about the several use cases.

If you have a repository in the settings.xml, it must be inside a profile.
This would mean that it looks more like you have to do this:
https://maven.apache.org/archetype/maven-archetype-plugin/archetype-repository.html

Right now it is required to call the repository "archetype" which also
prevents Maven from going over all repositories and trying to fetch all
catalogs.

I assume the name "archetype" is not a real issue since you need to
activate a profile, but if there are good reasons to change this, we
should have another look at it.

thanks,
Robert

On Thu, 18 May 2017 16:58:47 +0200, Amélie Deltour
 wrote:



ARCHETYPE-520 (and ARCHETYPE-358) are indeed close to the problem I try
to describe, but not exactly the same.
These issues are about using the mirror configuration to access
archetype data, i.e. using
http://myrepo.mycompany/maven/archetype-catalog.xml instead of direct
access to http://repo1.maven.org/maven2/archetype-catalog.xml, but this
is still the Maven central catalog, just accessed through a mirror
instead of accessing it directly.

But my issue, and the issue behind most ARCHETYPE-519 comments, is not a
mirror issue, it is not either a CLI vs settings.xml issue, it is about
the ability to use an *alternative catalog* which is not published on
Maven central.

In my settings.xml I have several repositories defined:

   
 internal
 repository for internal artifacts
 http://myrepo.mycompany/internal
 ...
   
   
 central
 repository for external artifacts
 http://myrepo.mycompany/external
 ...
   



With 3.x it seems that the "remote" catalog uses the catalog located at
http://myrepo.mycompany/external/archetype-catalog.xml (which is a proxy
for Maven central catalog) but we need the catalog published at
http://myrepo.mycompany/internal/archetype-catalog.xml to be used as
well and this one is ignored.
That's to say, "remote" is interpreted as the "central" repository only,
and other repositories configured in settings.xml are ignored.

This is what I call an "alternative catalog" and I think it is a valid
use case for the plugin.
This was possible with the archetypeCatalog CLI parameter (giving the
catalog URL), and it is probably what the parameter was meant for.
But is not possible anymore with 3.x.
I agree the CLI parameter can be removed, *but* the other repositories
defined in settings.xml have to be taken into account when searching for
remote archetype catalogs.

Please confirm if my use case is valid - in that case I think
ARCHETYPE-519 should be reopend or I can open a new issue if you think
it is more appropriate.
Or I misunderstood / misconfigured something: if my Maven configuration
or usage is wrong I would be glad to understand what's wrong and why.

Thanks,

Amélie


On 05/16/2017 07:06 PM, Robert Scholte wrote:

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

Re: The maven-archetype-plugin paradox

[Amélie Deltour]

Hi,

Thanks for the link, I could not find where this "archetype" repository was 
documented.

However, I tried to use the "archetype" repository earlier, and tried again, 
and I can't make it work.

With 2.4: mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate 
-DarchetypeGroupId=com.mycompany.archetype -DarchetypeArtifactId=myCustomArchetype 
-DarchetypeCatalog=http://artifactory.mycompany.com/internal-releases/
=> it works fine (that's what we used to do)

With 3.0: mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.0:generate 
-DarchetypeGroupId=com.mycompany.archetype 
-DarchetypeArtifactId=myCustomArchetype
=> does not work - I get "[WARNING] Specified archetype not found." and I am 
proposed the list of archetypes from Maven central
Tried with both 3.0 and 3.0.1.

Attached is my full settings.xml.

Can you explain what is wrong with these settings?
(or if this is not the right place to ask, please tell me where to ask)

Amélie

On 05/19/2017 09:54 PM, Robert Scholte wrote:

Hi Amélie,

first thank you for helping to us to improve this and to get more
information about the several use cases.

If you have a repository in the settings.xml, it must be inside a profile.
This would mean that it looks more like you have to do this:
https://maven.apache.org/archetype/maven-archetype-plugin/archetype-repository.html

Right now it is required to call the repository "archetype" which also
prevents Maven from going over all repositories and trying to fetch all
catalogs.

I assume the name "archetype" is not a real issue since you need to
activate a profile, but if there are good reasons to change this, we
should have another look at it.

thanks,
Robert

On Thu, 18 May 2017 16:58:47 +0200, Amélie Deltour
 wrote:



ARCHETYPE-520 (and ARCHETYPE-358) are indeed close to the problem I try
to describe, but not exactly the same.
These issues are about using the mirror configuration to access
archetype data, i.e. using
http://myrepo.mycompany/maven/archetype-catalog.xml instead of direct
access to http://repo1.maven.org/maven2/archetype-catalog.xml, but this
is still the Maven central catalog, just accessed through a mirror
instead of accessing it directly.

But my issue, and the issue behind most ARCHETYPE-519 comments, is not a
mirror issue, it is not either a CLI vs settings.xml issue, it is about
the ability to use an *alternative catalog* which is not published on
Maven central.

In my settings.xml I have several repositories defined:

   
 internal
 repository for internal artifacts
 http://myrepo.mycompany/internal
 ...
   
   
 central
 repository for external artifacts
 http://myrepo.mycompany/external
 ...
   



With 3.x it seems that the "remote" catalog uses the catalog located at
http://myrepo.mycompany/external/archetype-catalog.xml (which is a proxy
for Maven central catalog) but we need the catalog published at
http://myrepo.mycompany/internal/archetype-catalog.xml to be used as
well and this one is ignored.
That's to say, "remote" is interpreted as the "central" repository only,
and other repositories configured in settings.xml are ignored.

This is what I call an "alternative catalog" and I think it is a valid
use case for the plugin.
This was possible with the archetypeCatalog CLI parameter (giving the
catalog URL), and it is probably what the parameter was meant for.
But is not possible anymore with 3.x.
I agree the CLI parameter can be removed, *but* the other repositories
defined in settings.xml have to be taken into account when searching for
remote archetype catalogs.

Please confirm if my use case is valid - in that case I think
ARCHETYPE-519 should be reopend or I can open a new issue if you think
it is more appropriate.
Or I misunderstood / misconfigured something: if my Maven configuration
or usage is wrong I would be glad to understand what's wrong and why.

Thanks,

Amélie


On 05/16/2017 07:06 PM, Robert Scholte wrote:

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) 

Re: The maven-archetype-plugin paradox

[Robert Scholte]

Hi Amélie,

first thank you for helping to us to improve this and to get more  
information about the several use cases.


If you have a repository in the settings.xml, it must be inside a profile.
This would mean that it looks more like you have to do this:
https://maven.apache.org/archetype/maven-archetype-plugin/archetype-repository.html

Right now it is required to call the repository "archetype" which also  
prevents Maven from going over all repositories and trying to fetch all  
catalogs.


I assume the name "archetype" is not a real issue since you need to  
activate a profile, but if there are good reasons to change this, we  
should have another look at it.


thanks,
Robert

On Thu, 18 May 2017 16:58:47 +0200, Amélie Deltour  
 wrote:


ARCHETYPE-520 (and ARCHETYPE-358) are indeed close to the problem I try  
to describe, but not exactly the same.
These issues are about using the mirror configuration to access  
archetype data, i.e. using  
http://myrepo.mycompany/maven/archetype-catalog.xml instead of direct  
access to http://repo1.maven.org/maven2/archetype-catalog.xml, but this  
is still the Maven central catalog, just accessed through a mirror  
instead of accessing it directly.


But my issue, and the issue behind most ARCHETYPE-519 comments, is not a  
mirror issue, it is not either a CLI vs settings.xml issue, it is about  
the ability to use an *alternative catalog* which is not published on  
Maven central.


In my settings.xml I have several repositories defined:


  internal
  repository for internal artifacts
  http://myrepo.mycompany/internal
  ...


  central
  repository for external artifacts
  http://myrepo.mycompany/external
  ...




With 3.x it seems that the "remote" catalog uses the catalog located at  
http://myrepo.mycompany/external/archetype-catalog.xml (which is a proxy  
for Maven central catalog) but we need the catalog published at  
http://myrepo.mycompany/internal/archetype-catalog.xml to be used as  
well and this one is ignored.
That's to say, "remote" is interpreted as the "central" repository only,  
and other repositories configured in settings.xml are ignored.


This is what I call an "alternative catalog" and I think it is a valid  
use case for the plugin.
This was possible with the archetypeCatalog CLI parameter (giving the  
catalog URL), and it is probably what the parameter was meant for.

But is not possible anymore with 3.x.
I agree the CLI parameter can be removed, *but* the other repositories  
defined in settings.xml have to be taken into account when searching for  
remote archetype catalogs.


Please confirm if my use case is valid - in that case I think  
ARCHETYPE-519 should be reopend or I can open a new issue if you think  
it is more appropriate.
Or I misunderstood / misconfigured something: if my Maven configuration  
or usage is wrong I would be glad to understand what's wrong and why.


Thanks,

Amélie


On 05/16/2017 07:06 PM, Robert Scholte wrote:

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. 

Re: The maven-archetype-plugin paradox

[Amélie Deltour]

ARCHETYPE-520 (and ARCHETYPE-358) are indeed close to the problem I try to 
describe, but not exactly the same.
These issues are about using the mirror configuration to access archetype data, 
i.e. using http://myrepo.mycompany/maven/archetype-catalog.xml instead of 
direct access to http://repo1.maven.org/maven2/archetype-catalog.xml, but this 
is still the Maven central catalog, just accessed through a mirror instead of 
accessing it directly.

But my issue, and the issue behind most ARCHETYPE-519 comments, is not a mirror 
issue, it is not either a CLI vs settings.xml issue, it is about the ability to 
use an *alternative catalog* which is not published on Maven central.

In my settings.xml I have several repositories defined:

   
 internal
 repository for internal artifacts
 http://myrepo.mycompany/internal
 ...
   
   
 central
 repository for external artifacts
 http://myrepo.mycompany/external
 ...
   



With 3.x it seems that the "remote" catalog uses the catalog located at 
http://myrepo.mycompany/external/archetype-catalog.xml (which is a proxy for Maven 
central catalog) but we need the catalog published at 
http://myrepo.mycompany/internal/archetype-catalog.xml to be used as well and this one is 
ignored.
That's to say, "remote" is interpreted as the "central" repository only, and 
other repositories configured in settings.xml are ignored.

This is what I call an "alternative catalog" and I think it is a valid use case 
for the plugin.
This was possible with the archetypeCatalog CLI parameter (giving the catalog 
URL), and it is probably what the parameter was meant for.
But is not possible anymore with 3.x.
I agree the CLI parameter can be removed, *but* the other repositories defined 
in settings.xml have to be taken into account when searching for remote 
archetype catalogs.

Please confirm if my use case is valid - in that case I think ARCHETYPE-519 
should be reopend or I can open a new issue if you think it is more appropriate.
Or I misunderstood / misconfigured something: if my Maven configuration or 
usage is wrong I would be glad to understand what's wrong and why.

Thanks,

Amélie


On 05/16/2017 07:06 PM, Robert Scholte wrote:

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 

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

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

[Anders Hammar]

As one of the reporters of the breaking change tickets I also rather not
see this reverted as I think that our plugins should follow The Maven Way
and help people do the right thing.

I've seen some voices raises in some of the tickets (after the fact). But
how many is it really that has a problem? The case that I take most concern
about is that m2e uses the archetypeCatalog param, see [1].

In general I have no problems with us donating the plugin as I don't really
see the archetype solution as a core part of Maven. But if we keep it
within the Maven project I think we should stick to (our perception of) The
Maven way and follow path #1.

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

/Anders

On Mon, May 8, 2017 at 7: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 = less 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] http://semver.org/
> [2] https://issues.apache.org/jira/browse/ARCHETYPE-439
>
>
>
> -
> 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

[Hervé BOUTEMY]

+1 to the general analysis

perhaps using previous release is not so easy since this plugin is used on 
CLI, not in a pom.xml (in general), then you don't really choose which version 
will be used when you launch "mvn archetype:generate": Maven magic does a 
choice for you
The longer command line to choose version "mvn org.apache.maven.plugins:maven-
archetype-plugin:2.4:generate" is really so much harder to write

I don't know why we don't support "mvn archetype:2.4:generate": is it just we 
didn't find any use case until now or there is some issue? And we could perhaps 
even support "mvn archetype::generate" which displays available versions to 
choose from, in case one does not remember which precise version he wants 
(apart from "not the latest")

Regards,

Hervé

Le lundi 8 mai 2017, 19:47:08 CEST Manfred Moser a écrit :
> I think you have done the right thing even if some users are not necessarily
> happy. The documentation about the new behavior is clear enough, but maybe
> it needs to be more explicit.
> 
> In either I would just keep the plugin at ASF and do minimal maintenance
> like you have been doing. If someone wants to step up and do more they can
> right here easily enough or via pull requests.
> 
> Donating the plugin does not really solve anything imho. If someone really
> wants to use the old setup they have many options (use old version, fork,
> help us).
> 
> Reverting seems the wrong choice given that the new behavior is more in line
> with common Maven idioms..
> 
> In a nutshell.. dont fret. Keep up the good work ;-)
> 
> Manfred
> 
> Robert Scholte wrote on 2017-05-08 10:38:
> > 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 = less 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] http://semver.org/
> > [2] https://issues.apache.org/jira/browse/ARCHETYPE-439
> > 
> > 
> > 
> > -
> > 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

[Karl Heinz Marbaise]

Hi,

On 08/05/17 19:38, 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.


with a major number we break compatibility which we have decided cause 
otherwise we can't go further any step...


I've taken a look into the issue comment which is from my point of view 
useless...cause it's claiming about compatility which is intended to 
change with 3.X apart from that i does not give more details why etc.




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.


That sounds like wrong setup's etc. which we had thought about several 
times and we don't want to support it any longer with release 3.X 


The users need to learn we will change things and sometimes we need to 
break things with major version changes...if users don't like the 
changes they need to stuck with older versions...





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.


it is valid Absolutely no doubt about it...If people don't like the new 
release they have to stuck with the older version...that's it...


Apart from that you will always have people which complain about a 
change cause they don't like to change anything...(I'm making this 
experience several times on the job as well)..




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


+1 for this...



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.


The later is more the truth...cause we have many things to do at the 
moment..


If someone has a problem it there are pull request which can be 
made...or if really necessary a fork is also possible...


The mantenaince has been done over the time seemed to be fine...and keep 
the plugin here...


And as Manfred alsready said:

dont fret. Keep up the good work ;-)


Kind regards
Karl Heinz Marbaise




Any thoughts on this topic?

Robert

[1] http://semver.org/
[2] https://issues.apache.org/jira/browse/ARCHETYPE-439




-
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

[Manfred Moser]

I think you have done the right thing even if some users are not necessarily 
happy. The documentation about the new behavior is clear enough, but maybe it 
needs to be more explicit.

In either I would just keep the plugin at ASF and do minimal maintenance like 
you have been doing. If someone wants to step up and do more they can right 
here easily enough or via pull requests.

Donating the plugin does not really solve anything imho. If someone really 
wants to use the old setup they have many options (use old version, fork, help 
us). 

Reverting seems the wrong choice given that the new behavior is more in line 
with common Maven idioms.. 

In a nutshell.. dont fret. Keep up the good work ;-) 

Manfred

Robert Scholte wrote on 2017-05-08 10:38:

> 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 = less 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] http://semver.org/
> [2] https://issues.apache.org/jira/browse/ARCHETYPE-439
> 
> 
> 
> -
> 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