Quickstarts hierarchy/isolation

[Marco Sappe Griot]

Manuel and I have been discussing quickstarts.

We found out that quickstarts, differently from narayana, don't have the jboss-parent parent pom. This means they don't inherit properties and plugins as narayana does.

Although we think that having a parent pom with properties and plugins can be useful, we would like to focus on simplifying the customer experience. Thus we would like to keep the quickstarts as isolated as possible and easy to use.

We have 2 alternatives we would like to share with you:

1. Use the `jboss-parent` pom as parent of `narayana-quickstarts-all` (we don't need to maintain `jboss-parent` but more dependencies will be downloaded automatically) and add `narayana-quickstarts-all` as parent for all the quickstarts to inherit all parent’s properties/plugins/dependencies

2. Create a parent pom in a separated repository (see https://github.com/wildfly/wildfly-quickstart-parent and https://github.com/wildfly/quickstart/): each quickstart is lighter to build and run, all dependencies and properties are easy to retrieve and understand. In this way,  we will "detach" all quickstarts from `narayana-quickstarts-all` to connect them to an "external" artifact . i.e. using a parent pom as in WFLY

What do you think about it?

Best Regards,

Marco and Manuel

[Michael Musgrove]

The decision to not use a global parent pom was deliberate since a quickstart is, by definition, intended to help people easily get started with transactions. If you tie the examples into other projects such as wildfly etc (or even simply maven) then the user will need to unpick the boiler plate in order to effectively use the recipes within their own projects.

--
You received this message because you are subscribed to the Google Groups "narayana-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to narayana-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/ae07f4ad-95b5-423d-be1d-c2ef1e54e7dbn%40googlegroups.com.

[Manuel Finelli]

Hi Michael, Thank you very much for your reply. I think what Marco meant with:

Create a parent pom in a separated repository (see https://github.com/wildfly/wildfly-quickstart-parent and https://github.com/wildfly/quickstart/): each quickstart is lighter to build and run, all dependencies and properties are easy to retrieve and understand. In this way,  we will "detach" all quickstarts from `narayana-quickstarts-all` to connect them to an "external" artifact . i.e. using a parent pom as in WFLY

achieves exactly our goal (i.e. The decision to not use a global parent pom was deliberate since a quickstart is, by definition, intended to help people easily get started with transactions). The two links [1][2] that Marco added to his email show how the WildFly community achieved the same goal (i.e. having independent quickstarts) with a very clever hack: defining a "parent" pom in a separate repository [1], all their quickstarts can be connected with that "parent" pom without having a parent pom in the same repository where quickstarts are [2].

What is the reason for this proposal? Marco and I found out that to update our quickstarts to JDK 17, some maven plugins need to be updated for all our quickstarts. This will pollute our quickstarts with loads of boilerplate. The most obvious solution is to define a parent pom in our quickstarts repository BUT this would mean going against our initial goal (i.e. independent quickstarts). The solution that the WFLY community implemented seems to be the most reasonable one.

Please, let us know what you think.

[1] https://github.com/wildfly/wildfly-quickstart-parent

[2] https://github.com/wildfly/quickstart/

To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/CAKJ8-j4UNB8BvskLJJQrF%3DzyGYVYa3%3DZAtdjM3kC7n%2BLw7xrkQ%40mail.gmail.com.

[Michael Musgrove]

Could a similar goal not be achieved by importing a narayana bom?

Anyway, let's see what the opinion of the broader community is.

To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/CAG9sn3OC741kq215BDQghgfjxfRsXstzDF6QkQJo_2ahXRwkDQ%40mail.gmail.com.

--

Michael Musgrove

mmus...@redhat.com

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

[Manuel Finelli]

Isn't [1] a BOM in a different repository? To clarify this further, we do not want to use `wildfly-quickstart-parent` as the parent pom for our quickstarts but we would like to use the idea the WFLY community implemented for its quickstarts to "inspire" our own solution, i.e. a parent pom for Narayana's quickstarts in a separate repository.

[Michael Musgrove]

On Wed, Aug 10, 2022 at 12:41 PM Manuel Finelli <jfin...@redhat.com> wrote:

Isn't [1] a BOM in a different repository?

The bom would be the narayana bom which we need anyway so that it's clear to users which set of dependency versions we support/have tested on.

I don't think we need anything beyond that for the quickstarts, unless you can provide a convincing reason why we need something else.

Perhaps if a collection of quickstarts are pulling in shared dependencies for the purposes of the particular examples only (such as the tomcat, or LRA or RTS collections) then each such collection could share a separate pom in the quickstart repo although I don't think we've had an example of that to date.

 

To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/d05f1695-1be7-4d5a-aa16-59343b1570dcn%40googlegroups.com.

[Manuel Finelli]

On Wed, 10 Aug 2022 at 13:59, Michael Musgrove <mmus...@redhat.com> wrote:

On Wed, Aug 10, 2022 at 12:41 PM Manuel Finelli <jfin...@redhat.com> wrote:

Isn't [1] a BOM in a different repository?

The bom would be the narayana bom which we need anyway so that it's clear to users which set of dependency versions we support/have tested on.

Yep, I agree we only need a `narayana bom`. I propose to put it in a different repository (e.g. `narayana-quickstart-parent`). (Narayana already uses this logic here [3])

I don't think we need anything beyond that for the quickstarts, unless you can provide a convincing reason why we need something else.

This need arose using JDK17 in our quickstarts. During the update of Narayana to JDK17 we did not have this need because of [3]. As Marco said in his email, using [3] in our quickstarts might be an overkill (loads of stuff to download) but we can always use that bom instead of defining a new one (see first point in Marco's email).

[3] https://github.com/jbosstm/narayana/blob/master/pom.xml#L18-L22

[Michael Musgrove]

Maybe I have a different understanding of the issue that Marco is raising, perhaps other community members can chip in. Marco talks about the need for inheriting plugins and properties from a common location:

- a pluginManagement section in the top level pom would satisfy the plugin requirement;

- regarding inheriting properties, are there many such properties that need sharing (currently we only define a shared property for the modular.jdk.args we introduced for JDK 9 in the top level pom and I'd imagine something similar for the JDK 17 work you mention would suffice, but not much more);

- my point about using a narayana bom is if you want to include dependency management in Marco's issue.

[Manuel Finelli]

On Wed, 10 Aug 2022 at 15:50, Michael Musgrove <michael....@gmail.com> wrote:

Maybe I have a different understanding of the issue that Marco is raising, perhaps other community members can chip in. Marco talks about the need for inheriting plugins and properties from a common location:

- a pluginManagement section in the top level pom would satisfy the plugin requirement;

At the moment, we do not have a top level pom for our quickstarts, which is in line with our goal (i.e. the decision to not use a global parent pom was deliberate since a quickstart is, by definition, intended to help people easily get started with transactions). What we have now is this pom [4], which is only specified as parent in 5 "sub"-poms. [4] is only used to build all quickstarts with one command (i.e. mvn clean install) but it does not act as a parent pom for most of our quickstarts. This means that our quickstarts cannot benefit from a `pluginManagement` section in the `narayana-quickstarts-all` pom. That is why Marco wrote his initial email: we would like to respect our goal (i.e. independent quickstarts) but we realise that we need a BOM to specify shared plugins' versions (and, eventually/maybe, other shared properties, dependencies, etc.) in a single place (eliminating useless repetitions).

 

- regarding inheriting properties, are there many such properties that need sharing (currently we only define a shared property for the modular.jdk.args we introduced for JDK 9 in the top level pom and I'd imagine something similar for the JDK 17 work you mention would suffice, but not much more);

- my point about using a narayana bom is if you want to include dependency management in Marco's issue.

At the moment, we only need the `pluginManagement` section. A dependencyManagement section might become a nice-to-have improvement (which would also simplify other repetitions in our quickstarts).

[4] https://github.com/jbosstm/quickstart/blob/master/pom.xml

 

To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/c86312d6-db1c-490e-8407-704bdcfa65d2n%40googlegroups.com.

[Michael Musgrove]

You just need to add a parent section to each quickstart that refers to the top level quickstart pom if you want to implement Marco's new requirements. But keep it minimal, restricting it to versioning and jdk profiles so as to maintain the independence of each of our quickstarts.

If more requirements, above and beyond what Marco identifies, arise then we can look at creating new repos and/or new artifacts etc.

[Marco Sappe Griot]

Thanks Michael and Manuel for your mails.

I would like to summarize to see if I understood correctly:

- We agree to have a common parent pom (can be also a bom) like https://github.com/jbosstm/quickstart/blob/master/pom.xml for the quickstarts (even quickstarts that don't have it  as a parent now)

- We agree this parent pom should be as simple as possible in order to make it easy for the user to run use each quickstart independently.

At the moment I would need to add to many quickstarts 1 property, 1 plugin and 1 profile to make them run with JDK17 ( I would add it to the parent pom).

Did I understand correctly?

Thanks in advance,

Marco

[thje...@redhat.com]

I think something like this would be OK.

I think we should extend https://github.com/jbosstm/quickstart/blob/master/pom.xml and I think as appropriate the poms of the various quickstarts should set that as their parent.

I am not particularly certain about when a specific quickstart uses a dependency whether it should add it via groupId, artifactId _and _ version or just groupId and artifactId (and then having a dependencyManagement section in that root pom.xml to define the version). Maybe we just extend the properties section (https://github.com/jbosstm/quickstart/blob/master/pom.xml#L148-L150) to cover adding version numbers for dependencies to it and have the quickstarts declare groupId, artifactId and version (coming from a declared property in the root pom.xml).

I think general plugin configuration should go into a new pluginManagement section in https://github.com/jbosstm/quickstart/blob/master/pom.xml.

Thank you,

Tom

[Michael Musgrove]

I think the last suggestion from Tom is a solution that meets my expectations and I think it also matches Marco's requirements.
Marco, did you pick an approach or did you abandon the idea and end up leaving the poms as they were?

[Marco Sappe Griot]

Thanks Michael for the question. As you can see in my PR: https://github.com/jbosstm/quickstart/pull/403/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8

I implemented what Tom suggested:

- "I think we should extend https://github.com/jbosstm/quickstart/blob/master/pom.xml and I think as appropriate the poms of the various quickstarts should set that as their parent."

-"Maybe we just extend the properties section (https://github.com/jbosstm/quickstart/blob/master/pom.xml#L148-L150) to cover adding version numbers for dependencies to it and have the quickstarts declare groupId, artifactId and version (coming from a declared property in the root pom.xml)."

-"I think general plugin configuration should go into a new pluginManagement section in https://github.com/jbosstm/quickstart/blob/master/pom.xml."

So I have a plugin dependency section in the root pom, I added dependencies version as properties in root pom and I extended the quickstart pom so now they have got the root pom as parent pom.

In this PR I don't intend to implement a dependency management, but it can be added in a separate PR if needed.

To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/aaa773ec-2f66-4c71-869a-6a3cd2a55a87n%40googlegroups.com.

[Michael Musgrove]

I am closing this question as complete, if there is something still to do on it please raise a JBTM.