3:25 p.m.
Hi Brian,
ok, I think now I can start reworking the archetype...
What name do you suggest? "wildfly-javaee-webapp-ear-archetype" - just
remove the "7" from the current archetype.
This means:
a) rename the "wildfly-javaee7-webapp-ear-archetype" directory in GIT?
or
b) create a new project?
========================
Two more questions:
there is a file "kitchensink-ear\readme.adoc", which is added to the
archetype.
But this will probably not work in the archetype, because it includes of
other adoc files in "../shared-doc"
Just remove it? I might also add a static file, like the "readme.md"
from the old archetype if necessary - but if it is static, it should
explain the archetype itself.
==========================
There is a profile "arq-managed" defined in
https://github.com/wildfly/quickstart/blob/master/pom.xml, which I would
also copy to the static archetype pom.xml.
I assume it does not work the way it is declared in the quickstart root
"pom.xml":
When running the "arq-managed" profile (after copying it to my sample
application), I see this error:
org.jboss.arquillian.container.spi.client.container.LifecycleException:
Could not start container
Caused by: java.lang.IllegalArgumentException: WFLYLNCHR0001: The path
'null' does not exist
Does it work for you in the quickstarts?
As far as I know, it requires also the maven-dependency-plugin which
downloads the Wildfly server, and it needs a "systemPropertyVariables"
named "jboss.home" pointing to the WildFly download - see snippet below.
Or did you resolve this otherwise? Does it work if an environment
variable JBOSS_HOME is present and set outside?
The quickstart pom.xml defines "jboss.home.name"
Adding my snippet to download the WildFly server to the root pom is not
smart - downloading and unpacking the wildFly server will be executed
before EJB and WAR project are scanned for tests, thus running twice -
so it would be better to just comment it and add an explanation "copy
this to the EJB/WAR pom.xml where the tests are located"?
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<id>unpack</id>
<phase>pre-integration-test</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-dist</artifactId>
<version>${version.wildfly}</version>
<type>zip</type>
<overWrite>false</overWrite>
<outputDirectory>target</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-failsafe-plugin</artifactId>
<version>${version.failsafe.plugin}</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
<configuration>
<systemPropertyVariables>
<jboss.home>${project.basedir}/target/wildfly-${version.wildfly}</jboss.home>
</systemPropertyVariables>
</configuration>
</plugin>
Thanks
Wolfgang
Am 06.03.19 um 23:27 schrieb Brian Stansberry:
Hi Wolfgang,
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.
The "copy in the pom after" idea could work fine too. It's a bit
convoluted, but really so is the whole archetype sync. :)
Best regards,
Brian
On Wed, Mar 6, 2019 at 2:54 PM Wolfgang Knauf <wolfgang.knauf(a)gmx.de
<mailto:wolfgang.knauf@gmx.de>> wrote:
Here is another idea to avoid modifications to the qstools plugin:
As written below, the root pom for the resulting archetype application
is not pulled from kitchensink, but is placed in some directory in the
archetype source tree, e.g.
"wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\archetype_files"
(this is probably a non-standard dir - do you have better suggestions?)
The "maven-resources-plugin" copies this file to
"${basedir}/target/classes/archetype-resources". If this copying takes
place after the "qstools:archetypeSync" was done, it will overwrite the
file pulled from the kitchensink app.
What do you think?
At least it works for me - the archetype can be built.
Attached file "snippet_pom.xml" contains the snippet for
"wildfly-archetypes\wildfly-javaee7-webapp-ear-archetype\pom.xml" which
defines this file copying.
The attached file "pom.xml" is the static file for the archetype -
stills needs a bit of tuning...
Greetings
Wolfgang
Am 05.03.19 um 23:00 schrieb Wolfgang Knauf:
> Hi Brian,
>
> Am 05.03.19 um 00:27 schrieb Brian Stansberry:
>
>>
>> AIUI your b.2 means decoupling the archetype from the QS code and
>> instead directly having the app code in the wildfly-archetypes
codebase.
>> The downside to that is now there's another example app to maintain.
>> (More than one really, as there would be one per archetype.)
>>
>> I think the key thing is this would need to be low maintenance.
The root
>> QS depends on the wildfly-bom[1] so if there aren't a lot of version
>> dependencies that would need to be in the archetype poms that
will help.
>> Is your impression that the archetype pom would be low maintenance?
>>
>> [1] https://github.com/wildfly/quickstart/blob/master/pom.xml#L109
>>
>
> yes, this sounds like a very good idea: edit and maintain the
root pom
> of the archetype in the "archetype-resources" directory and sync
only
> all other files. This mean a bit of work each time the archetype is
> updated for a new WildFly version, but less work than editing all
files.
>
> The only downside: I think the "ArchetypeSyncMojo" must be
modified and
> a "excludedFiles" property added, so that a sync will not
overwrite the
> archetype pom with the quickstart file.
>
> I hope I can do this, if you think this sounds reasonable ;-).
>
> Who is responsible for the maven-qstools-plugin? Probably he/she
should
> agree to those plans, too... And my change would have to be
merged and a
> new release of 1.7.0 (or 1.7.1?) to maven central would have to be
> triggered. As this is my first step in WildFly coding, I am new
to all
> this stuff.
>
> Best regards
>
> Wolfgang
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat