You mean "wildfly-subsystem-archetype", building with "mvn clean install
-Dmodule=some.module.name"?
They build for me using Java 1.8 and Java 11 (Win7, Maven 3.6.0).
But when built with Java 11, there is a message "command cmd not found"
(translated) - not an error, just a message. But the build seems to finish.
But I don't know this archetype...
Wolfgang
Am 16.05.19 um 11:09 schrieb Eduardo Martins:
Hmm ok, maybe it just failed build due to some specific like JDK 11,
will recheck that.
—E
> On 16 May 2019, at 02:25, Brian Stansberry
> <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>>
wrote:
>
> These build for me.
>
> They're not as out of date as I'd thought either.
>
> On Fri, May 10, 2019 at 6:34 PM Eduardo Martins <emartins(a)redhat.com
> <mailto:emartins@redhat.com>> wrote:
>
> If you think it’s not a small effort task then certainly agree
> that’s not a blocker, I look at the archetypes same way as the
> quickstarts, an aggregation project, so we may take
> outdated/faulty ones out of build and release the working+actual
> ones. We may give it a thought later if it makes sense effort wise
> to update or drop the subsystem ones, no worries.
>
> —E
>
> On Fri, 10 May 2019 at 21:46, Brian Stansberry
> <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>>
> wrote:
>
> Is that blocking this Eduardo?
>
> If not, updating those is a pretty big task and right now I
> don't see it happening anytime soon.
>
> On Fri, May 10, 2019 at 3:10 PM Eduardo Martins
> <emartins(a)redhat.com <mailto:emartins@redhat.com>> wrote:
>
> Brian, any idea what to do wrt the subsystem archetypes?
> ATM even build fails and most likely there is someone else
> better than me to look into that…
>
> —E
>
> > On 7 May 2019, at 09:18, Eduardo Martins
> <emartins(a)redhat.com <mailto:emartins@redhat.com>> wrote:
> >
> > Hi Wolfgang, I actually did start reviewing it, but
> unfortunately had to put it on hold due to unexpected
> blocker kind of priority tasks/issues needed to be solved
> asap. If nothing urgent comes I should be able to finish
> the review the next couple of days.
> >
> > —E
> >
> >> On 6 May 2019, at 20:50, Wolfgang Knauf
> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>>
wrote:
> >>
> >> Hi,
> >>
> >> just want to ask for an update ;-)
> >>
> >> Best regards
> >>
> >> Wolfgang
> >>
> >> Am 31.03.19 um 21:34 schrieb Eduardo Martins:
> >>> I will review it, soon hopefully.
> >>>
> >>> —E
> >>>
> >>>> On 31 Mar 2019, at 19:40, Wolfgang Knauf
> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>>
wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> just want to ask about the state of the pull request
> and further steps...
> >>>>
> >>>> Best regards
> >>>>
> >>>> Wolfgang
> >>>>
> >>>> Am 21.03.19 um 12:47 schrieb Wolfgang Knauf:
> >>>>> OK, I sent a pull request:
> >>>>>
https://github.com/wildfly/wildfly-archetypes/pull/3
> >>>>>
> >>>>> There already exists a JIRA (created by myself):
> >>>>>
https://issues.jboss.org/browse/WFLY-9703 - but I
> cannot assign it to
> >>>>> myself, probably because I only have the role
"jira
> user".
> >>>>>
> >>>>> Next steps (if the pull request is accepted):
> >>>>> -someone has to release if to maven central. See
the
> release scripts in
> >>>>> the wildfly-archetypes root. This is probably
> something that has to done
> >>>>> by the JBoss team.
> >>>>> -the old archetype can be removed.
> >>>>> -I will create a similar archetype replacement for
> >>>>> "wildfly-javaee7-webapp-archetype"
> >>>>>
> >>>>>
> >>>>> Wolfgang
> >>>>>
> >>>>> Am 19.03.19 um 12:09 schrieb Wolfgang Knauf:
> >>>>>>
> >>>>>> Am 18.03.19 um 22:49 schrieb Eduardo Martins:
> >>>>>>> Webapp-ear sounds a bit weird, perhaps
app-ear and
> app-web instead? :-)
> >>>>>>
> >>>>>>
> >>>>>> What do you think about
> "wildfly-javaee-ear-archetype" and
> >>>>>> "wildfly-javaee-web-archetype"?
> >>>>>>
> >>>>>>
> >>>>>> Attached is a suggested integration test
prototype,
> which shows how to
> >>>>>> create the EAR file using ShrinkWrap. The test
code
> will be placed in
> >>>>>> the web module. The kitchensink quickstart had
the
> tests in the EJB jar,
> >>>>>> but this is the wrong place if you also want to
> test the web layer.
> >>>>>>
> >>>>>> If this is all sound OK, I will start committing
it
> to my git repository
> >>>>>> and sending the pull request.
> >>>>>>
> >>>>>> Best regards
> >>>>>>
> >>>>>> Wolfgang
> >>>>>>
> >>>>>>>
> >>>>>>> On Mon, 18 Mar 2019 at 21:04, Wolfgang
Knauf
> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>
> >>>>>>> <mailto:wolfgang.knauf@gmx.de
> <mailto:wolfgang.knauf@gmx.de>>> wrote:
> >>>>>>>
> >>>>>>> OK, so there are two votes (mine and
> Eduardo's) for "create a blank
> >>>>>>> archetype from scratch - no demo source
> included" and no vote for
> >>>>>>> "continue using the
quickstart" approach.
> >>>>>>>
> >>>>>>> Currently, I struggle with the archetype
and
> will send a pull
> >>>>>>> request in
> >>>>>>> the next few days.
> >>>>>>>
> >>>>>>> Any objections against the name
> >>>>>>>
"wildfly-javaee-webapp-ear-archetype"
> >>>>>>> (which means: a new subdirectory in
git)?
> >>>>>>>
> >>>>>>> If this is done, the next step would be
to
> create a
> >>>>>>>
"wildfly-javaee-webapp-archetype". And then
> someone could clean
> >>>>>>> up the
> >>>>>>> old archetypes.
> >>>>>>>
> >>>>>>> I think about adding a small integration
test
> to the web project
> >>>>>>> which
> >>>>>>> shows how to create the @Deployment
using
> ShrinkWrap? The test
> >>>>>>> itself
> >>>>>>> might have only dummy code, just the
creation
> of the EAR file is
> >>>>>>> relevant. This might be helpful to
users.
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>>
> >>>>>>> Wolfgang
> >>>>>>>
> >>>>>>> Am 18.03.19 um 09:33 schrieb Eduardo
Martins:
> >>>>>>>> The archetype sources should actually be
simpler
> to maintain, no
> >>>>>>> need to “fix” the imported QS sources...
I
> guess for most releases
> >>>>>>> it would be to simply the effort to sync
some
> dependency management
> >>>>>>> versions for the generated parent pom,
e.g.
> WildFly BOMs version.
> >>>>>>>>
> >>>>>>>> Wrt the html5-mobile archetype, I
believe it is
> similar to the
> >>>>>>> ones you were looking at, but pointing
to an
> old QS that was
> >>>>>>> removed
> >>>>>>> at some point.
> >>>>>>>>
> >>>>>>>> —E
> >>>>>>>>
> >>>>>>>>> On 13 Mar 2019, at 19:14, Wolfgang
Knauf
> <wolfgang.knauf(a)gmx.de <mailto:wolfgang.knauf@gmx.de>
> >>>>>>> <mailto:wolfgang.knauf@gmx.de
> <mailto:wolfgang.knauf@gmx.de>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Am 13.03.19 um 18:25 schrieb Eduardo
Martins:
> >>>>>>>>>>
> >>>>>>>>>>> On 12 Mar 2019, at 19:12,
Wolfgang Knauf
> >>>>>>> <wolfgang.knauf(a)gmx.de
> <mailto:wolfgang.knauf@gmx.de>
> <mailto:wolfgang.knauf@gmx.de
> <mailto:wolfgang.knauf@gmx.de>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Eduardo,
> >>>>>>>>>>>
> >>>>>>>>>>> Am 12.03.19 um 08:58 schrieb
Eduardo Martins:
> >>>>>>>>>>>> Hi Wolfgang, the
kitchensink QS truly depends
> on the QS
> >>>>>>> parent pom (dependency management,
plugins,
> etc.), which means that
> >>>>>>> if we replace it with a “local” parent
pom
> then, for each release,
> >>>>>>> we need to sync manually such parents
poms
> content… I don’t see any
> >>>>>>> issue with using QS parent pom, it seems
that
> those archetypes were
> >>>>>>> designed to generate clones of specific
> quickstarts with just
> >>>>>>> different Maven GAVs. Have you tried to
> install the SNAPSHOT
> >>>>>>> versioned QS parent first (mvn install
-N at
> QS repo root), or
> >>>>>>> use a
> >>>>>>> tag such as 16.0.0.Final, which parent
was
> released to Maven,
> >>>>>>> instead of pointing to QS master branch
?
> >>>>>>>>>>>> Honestly I’m not sure
this kind of app
> archetype is of much
> >>>>>>> interest as it is, mostly due to the
app's
> complexity, probably
> >>>>>>> would be more helpful almost “empty”
apps, but
> if the idea is to
> >>>>>>> have a QS clone tool then perhaps a
single
> generic archetype for
> >>>>>>> that would make more sense. I’m open to
QS
> source changes needed to
> >>>>>>> be friendly with such archetype :-)
> >>>>>>>>>>>> —E
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> I agree that the
> "wildfly-javaee7-webapp-ear-archetype"
> >>>>>>> archetype is not really useful. But
based on
> this archetype, an
> >>>>>>> empty archetype
> "wildfly-javaee7-webapp-ear-blank-archetype" is
> >>>>>>> generated, which consists of all
necessary
> pom.xml files and some
> >>>>>>> deployment descriptor stubs. And *this*
> archetype is the reason why
> >>>>>>> I started working on it: it is a good
starting
> point for a new
> >>>>>>> JavaEE application which already defines
all
> necessary components.
> >>>>>>>>>>>
> >>>>>>>>>>> I am willing to maintain
this archetype for
> the next few
> >>>>>>> years
> >>>>>>> and trying to release a version for each
major
> WildFly version. As
> >>>>>>> suggested I would add a static root
pom.xml to
> the archetype github
> >>>>>>> project which is independent of the
quickstart
> files, as they are
> >>>>>>> not "standalone". This main
pom.xml has to be
> updated for each
> >>>>>>> WildFly version, but all the other files
still
> can be pulled from
> >>>>>>> the "KitchensinkEar"
quickstart.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Then why get any sources from QS
repo, having a
> proper
> >>>>>>> do-nothing app project all locally
sounds
> better to me, probably
> >>>>>>> less effort needed on every release
too.
> >>>>>>>>>>
> >>>>>>>>>> —E
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> So you prefer to create a blank
archetype which
> has no build
> >>>>>>>>> dependencies, just containing the
relevant
> pom.xml files and
> >>>>>>> maybe some
> >>>>>>>>> required files (don't know if
there are any)?
> And this
> >>>>>>> archetype is
> >>>>>>>>> updated by someone (e.g. me) each
time a new
> major release
> >>>>>>> is done?
> >>>>>>>>>
> >>>>>>>>> Same applies to the other
archetype,
> >>>>>>>
"wildfly-javaee7-webapp-archetype”.
> >>>>>>>>> The wildfly-archetypes project
contains two more
> archetypes
> >>>>>>>>>
("wildfly-html5-mobile-archetype",
> >>>>>>>
"wildfly-subsystem-archetype"), but I
> >>>>>>>>> did not even take a look at those.
> >>>>>>>>>
> >>>>>>>>> Personally, I prefer the standalone
approach,
> too. It means
> >>>>>>> more
> >>>>>>> work to
> >>>>>>>>> maintain it, but it is simpler ;-)
> >>>>>>>>>
> >>>>>>>>> Please vote for any of those
solutions ;-):
> >>>>>>>>> a) continue pulling from
KitchensinkEAR
> quickstart ("blank"
> >>>>>>> archetype
> >>>>>>>>> and archetype with a basic
project)...
> >>>>>>>>> b) create standalone archetype (only
"blank"
> archetype).
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 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
> >>>
> >>>
> >>
> >> _______________________________________________
> >> 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
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev