<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi Wolfgang,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I've reached out to try and find out the process for making changes to maven-qstools-plugin, which has been inactive for a couple years.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">The "copy in the pom after" idea could work fine too. It's a bit convoluted, but really so is the whole archetype sync. :)</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Best regards,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Brian</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 6, 2019 at 2:54 PM Wolfgang Knauf <<a href="mailto:wolfgang.knauf@gmx.de">wolfgang.knauf@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Here is another idea to avoid modifications to the qstools plugin:<br>
<br>
As written below, the root pom for the resulting archetype application <br>
is not pulled from kitchensink, but is placed in some directory in the <br>
archetype source tree, e.g. <br>
"wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\archetype_files" <br>
(this is probably a non-standard dir - do you have better suggestions?)<br>
<br>
The "maven-resources-plugin" copies this file to <br>
"${basedir}/target/classes/archetype-resources". If this copying takes <br>
place after the "qstools:archetypeSync" was done, it will overwrite the <br>
file pulled from the kitchensink app.<br>
<br>
What do you think?<br>
<br>
At least it works for me - the archetype can be built.<br>
<br>
Attached file "snippet_pom.xml" contains the snippet for <br>
"wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\pom.xml" which <br>
defines this file copying.<br>
<br>
The attached file "pom.xml" is the static file for the archetype - <br>
stills needs a bit of tuning...<br>
<br>
Greetings<br>
<br>
Wolfgang<br>
<br>
<br>
Am 05.03.19 um 23:00 schrieb Wolfgang Knauf:<br>
> Hi Brian,<br>
> <br>
> Am 05.03.19 um 00:27 schrieb Brian Stansberry:<br>
> <br>
>><br>
>> AIUI your b.2 means decoupling the archetype from the QS code and<br>
>> instead directly having the app code in the wildfly-archetypes codebase.<br>
>> The downside to that is now there's another example app to maintain.<br>
>> (More than one really, as there would be one per archetype.)<br>
>><br>
>> I think the key thing is this would need to be low maintenance. The root<br>
>> QS depends on the wildfly-bom[1] so if there aren't a lot of version<br>
>> dependencies that would need to be in the archetype poms that will help.<br>
>> Is your impression that the archetype pom would be low maintenance?<br>
>><br>
>> [1] <a href="https://github.com/wildfly/quickstart/blob/master/pom.xml#L109" rel="noreferrer" target="_blank">https://github.com/wildfly/quickstart/blob/master/pom.xml#L109</a><br>
>><br>
> <br>
> yes, this sounds like a very good idea: edit and maintain the root pom<br>
> of the archetype in the "archetype-resources" directory and sync only<br>
> all other files. This mean a bit of work each time the archetype is<br>
> updated for a new WildFly version, but less work than editing all files.<br>
> <br>
> The only downside: I think the "ArchetypeSyncMojo" must be modified and<br>
> a "excludedFiles" property added, so that a sync will not overwrite the<br>
> archetype pom with the quickstart file.<br>
> <br>
> I hope I can do this, if you think this sounds reasonable ;-).<br>
> <br>
> Who is responsible for the maven-qstools-plugin? Probably he/she should<br>
> agree to those plans, too... And my change would have to be merged and a<br>
> new release of 1.7.0 (or 1.7.1?) to maven central would have to be<br>
> triggered. As this is my first step in WildFly coding, I am new to all<br>
> this stuff.<br>
> <br>
> Best regards<br>
> <br>
> Wolfgang<br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
> <br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div>