514993 - Maven archetype post generated script is not executed while creating from maven module wizard

[hd42]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=514993
Maven archetypes can include Groovy scripts which will be executed after the Maven project is created from that archetype. It works fine from the command prompt. But the script is not executed when the project is created using the same archetype via the Eclipse >> New >> Maven project wizard.
Apparently, license issues prevent(ed?) m2e's move from including the maven-artefact-plugin 2.* to 3.*.

This issue still persists in Eclipse 21.6.

[mbooth101]

This is expected, m2e includes a very old version of maven archetype (2.4) and only maven-archetype 3.x supports the post-step groovy scripts.

I don't think the groovy license is a problem at all, there is already lots of ASL licensed software in m2e, Eclipse and Orbit.

More likely the blocker is the non-trivial porting effort to move to archetype 3.x.

As a starting point, you can look at the patch I carried in Fedora:

https://src.fedoraproject.org/rpms/eclipse-m2e-core/blob/f34/f/0005-Port-to-latest-version-of-maven-archetypes.patch

[mickaelistria]

@mbooth101 you're right; going to archiver 2.4 to 3.x isn't trivial enough to be a priority at the moment. Is the Fedora patch functional? Would you be willing to submit it as a pull request?

[mbooth101]

Err, sure. I'll rebase it and open a PR then we can take a closer look

[laeubi]

Err, sure. I'll rebase it and open a PR then we can take a closer look

Any updates here? I'd like to push this forward for the 2.x line as this is a good opportunity to change versions.

[fbricon]

few things to take into consideration:

• post scripts support means we need to bring in those big fat groovy dependencies. So Cut dependency to maven archetype runtime from m2e.core #731 needs to be fixed.
• those scripts can crash eclipse (if calling System.exit)
• those scripts can be interactive. Need to be presented in an interactive console.

[hd42]

We are using a Groovy script in the faktorips-maven-archetype for optional parameters that are only required when other parameters have certain values - using System.in and for some postprocessing. If the interactive console does not work in Eclipse, we could change those parameters to a "not set" default - and define them in the archetype-metadata - but still run the postprocessing with Groovy.

[HannesWell]

few things to take into consideration:

* post scripts support means we need to bring in those big fat groovy dependencies. So [Cut dependency to maven archetype runtime from m2e.core #731](https://github.com/eclipse-m2e/m2e-core/issues/731) needs to be fixed.

I stumbled upon the fact that we ship an relatively ancient version of and updated it locally. Not only does it require the groovy-all jar (which has about 7Mb at the moment), even worse it also requires icu4j/com.ibm.icu that has ~13MB. In total the size of o.e.m2e.archetype.common grows to ~25MB from 1.9MB which is more than 10 times bigger.

At the moment Eclipse itself ships com.ibm.icu, so we could use that, but IIRC the plan is to remove that jar so in the future m2e will have to ship it as well.

[HannesWell]

Err, sure. I'll rebase it and open a PR then we can take a closer look

Any updates here? I'd like to push this forward for the 2.x line as this is a good opportunity to change versions.

@laeubi if you plan to update the code I can offer to contribute the update of org.eclipse.m2e.archetype.common/pom.xml. It is a bit tedious work to find all the right exclusion but I have done locally already.

[laeubi]

@HannesWell sure, every piece would help, I think the discussions about size, interactive and system exit are valid but don't have to be the primary driver here given that

1. It does not work at all (even not for 'gracefull' scripts
2. We are shipping ancient versions
3. It seems not profitable to first refactor m2e using ancient versions and then refactor it to use newer versions
4. 'size' is not a development goal of m2e and if we find opportunities to reduce the size can do so any time later

So if you have anything here to upgrade right now we should do it, my idea is to try overhaul the thing then in a way where we collect all possible stuff and then simply fire of a (forked) maven run as if you run it on the console, then we probably can even omit most parts and let maven download the required stuff on demand, we have in/out and we don't need to care about system.exit at all.

[HannesWell]

@HannesWell sure, every piece would help, I think the discussions about size, interactive and system exit are valid but don't have to be the primary driver here given that

Ack. Do you plan to start with that work right now or is it sufficient if I push those changes at the weekend?

So if you have anything here to upgrade right now we should do it, my idea is to try overhaul the thing then in a way where we collect all possible stuff and then simply fire of a (forked) maven run as if you run it on the console, then we probably can even omit most parts and let maven download the required stuff on demand, we have in/out and we don't need to care about system.exit at all.

I'm not familiar with that part of the code base but that sounds like a very good suggestion to me.

[laeubi]

Ack. Do you plan to start with that work right now or is it sufficient if I push those changes at the weekend?

Not immediately, most probably somewhere end of next week.

[HannesWell]

Do you think it will make it into 2.0?

If not we should make all exported packages of org.eclipse.m2e.archetype.common internal in order to be able to remove it later without another major release and announce that they are also planned for removal.

[laeubi]

As far as I have understand the 2.0 is delayed until 2022-09 so I think it would be possible.

we should make all exported packages of org.eclipse.m2e.archetype.common internal

If we feel better then ... why not, we can still delete them in the 2.0 anyways ;-)

[HannesWell]

As far as I have understand the 2.0 is delayed until 2022-09 so I think it would be possible.

I thought @mickaelistria wanted to release ASAP altough we would have time for next SimRel.
Nevertheless I would also be in favor to wait longer with a release. Removing Archetype is IMHO definitly a goal to wait for.
Especially since Archtype is also used in m2e's API in IProjectConfigurationManager.
So we should remove those usages before a 2.0 release.

[laeubi]

Especially since Archtype is also used in m2e's API in IProjectConfigurationManager

Yes that's something I want to get rid of.

[HannesWell]

So if you have anything here to upgrade right now we should do it, my idea is to try overhaul the thing then in a way where we collect all possible stuff and then simply fire of a (forked) maven run as if you run it on the console, then we probably can even omit most parts and let maven download the required stuff on demand, we have in/out and we don't need to care about system.exit at all.

Do you already have a plan how to replace the fetch of archetype-catalogs that is done in the import/create project dialogs?
Maybe it is maybe possible to query some Web/REST-API just like the LemMinX Editor does now to find dependencies?

[laeubi]

Do you already have a plan how to replace the fetch of archetype-catalogs that is done in the import/create project dialogs?

This will still use Archetype directly I think, just in case, one could call mvn archetype:generate and that will present a list of all archetypes.

[HannesWell]

Do you already have a plan how to replace the fetch of archetype-catalogs that is done in the import/create project dialogs?

This will still use Archetype directly I think, just in case, one could call mvn archetype:generate and that will present a list of all archetypes.

Just like in #767 couldn't we replace the listing then by a similar launch of mvn archetype:generate, parse the output and present it to the user.
Since mvn archetype:generate is interactive maybe archetype:crawl would be better suited for that.

The plug-in page also shows how to handle alternative repositories:
https://maven.apache.org/archetype/maven-archetype-plugin/

Isn't that then everything that uses the embedded archetype jars and we can then remove them or did I oversaw something?

[laeubi]

Just like in #767 couldn't we replace the listing then by a similar launch of mvn archetype:generate, parse the output and present it to the user.

We already use (internal) maven APIs in m2e I don't think we gain much in making a difference here and doing some parsing of data we can acquire at the first place.

Isn't that then everything that uses the embedded archetype jars and we can then remove them or did I oversaw something?

There is a lot of stuff around the archetypes but we might reduce the number of jars actually required...

[HannesWell]

Just like in #767 couldn't we replace the listing then by a similar launch of mvn archetype:generate, parse the output and present it to the user.

We already use (internal) maven APIs in m2e I don't think we gain much in making a difference here and doing some parsing of data we can acquire at the first place.

Isn't that then everything that uses the embedded archetype jars and we can then remove them or did I oversaw something?

There is a lot of stuff around the archetypes but we might reduce the number of jars actually required...

My main motivation was mainly to not pull in large dependency jars. So if we can avoid reduce the archetype-common dependency to archetype-catalog and archetype-descriptor only this would make a huge difference in the size of the resulting o.e.m2e.archtype.common jar (which should then actually be renamed).

After #767 is completed it looks like the main task to achive this would be to remove the need for org.apache.maven.archetype.ArchetypeManager and org.apache.maven.archetype.ArchetypeGenerationRequest.

[laeubi]

We made a big step forward and moved everything to Archetype 3.x now, there is one little thing left to have an option to enable interactive mode (currently everything uses the batch mode).

[laeubi]

This should now be possible, I can use the referenced faktor-ips archetype from the latest snapshot.

I'd like to give special thanks to Faktor Zehn GmbH who gently sponsored this feature.

@hd42 please let me know if you see any further issues with using your archetype here.