Let maven do the hard work of archetype generation

[laeubi]

Prerequisite for #249

[HannesWell]

This change looks very good.
Addressing the potential crashing of Eclipse by post scripts is IMHO important and this looks like a good step forward to maybe even get completely rid of the embedded archetype dependency?

I basically only have one remark: Could you please provide a more descriptive commit message, like: Generate archtetype projects in separate Maven-build process

[laeubi]

I'm struggling a bit to get the test repo filled completely (I probably will enable online maven central as it otherwise becomes really cumbersome), but the code itself is now functional and thus is ready to be reviewed.

[laeubi]

All tests are green now!

[HannesWell]

In general this looks good to me.

I just have a few minor remarks.

[HannesWell]

Is this logic new? Maybe it should be rejected with an error to create an archetype project where a pom.xml file already exists instead of using an alternative pom that is deleted afterwards.
Is the created project then valid after the empty-pom used for creation is deleted? Or is there a relevant use case for such scenario?

[laeubi]

What do you mean by 'new'? This is to prevent m2e to first generate the code at a temporary place and then move it around, without the empty pom you will get higher build times and can't create a module of a parent that has pom-errors and at least there is a test for that (don't know if it uses intentionally an incomplete module pom).

[laeubi]

By the way there are currently two restrictions one might report to maven and submit a patch, but this would then take some time until it is released:

1. If running mvn inside an empty folder / without a pom, it uses a "no-pom build", one can then force a different location of the pom by -f but if the folder contains no pom I can't force to ignore that file.
2. maven-archetype always generates the archetype at the folder $outputDir/$artifactId while here it would be good if we can just generate it in the current folder (what would be empty anyways).

[HannesWell]

What do you mean by 'new'? This is to prevent m2e to first generate the code at a temporary place and then move it around, without the empty pom you will get higher build times and can't create a module of a parent that has pom-errors and at least there is a test for that (don't know if it uses intentionally an incomplete module pom).

I meant if that the logic you just described was available before too.
Nevertheless what you describe sounds very reasonable. Thank you for your elaboration.

[laeubi]

@HannesWell I have applied your suggestion and fixed the compile issues, if you are fine I'll swash all content into one before merge...

[HannesWell]

Looks good to me. Thank you.

@HannesWell I have applied your suggestion and fixed the compile issues, if you are fine I'll swash all content into one before merge...

Sure squash it, I see no need to keep the review history in git. :)

[HannesWell]

I just noticed that Files.writeString() uses UTF-8 by default so specifying the charset explicitly is actually not necessary.

[HannesWell]

What do you mean by 'new'? This is to prevent m2e to first generate the code at a temporary place and then move it around, without the empty pom you will get higher build times and can't create a module of a parent that has pom-errors and at least there is a test for that (don't know if it uses intentionally an incomplete module pom).

I meant if that the logic you just described was available before too.
Nevertheless what you describe sounds very reasonable. Thank you for your elaboration.

[laeubi]

Okay, lets merge when build runs fine then (after reverting the modules link).

[mickaelistria]

I still don't like much IMavenLauncher (but at least it's internal, so not a too big deal)

I actually want to execute a maven run (with console) like when you do Run As > Maven Build and while the RunPomAction uses the AbstractMavenRuntime to build all the JVM parameters, the actual execution happens as a jvm process and not through AbstractMavenRuntime

Couldn't this be a new method to AbstractMavenRuntime then, something like IProcess runExtenally(...) ?

[laeubi]

Couldn't this be a new method to AbstractMavenRuntime then, something like IProcess runExtenally(...) ?

If you like, just try it out I won't mind adjusting that part of the code as it is covered by tests and not used elsewhere until now we can change relative easy here.