[wildfly-dev] Updating the WildFly archetypes
Wolfgang Knauf
wolfgang.knauf at gmx.de
Thu Mar 7 16:25:51 EST 2019
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 at gmx.de
> <mailto:wolfgang.knauf at 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 at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
More information about the wildfly-dev
mailing list