Hi Jason, thanks for bringing this to the mailing list. My opinion on this matter is that it'd be fine both ways (versions on <properties> or inline), whatever is easier to keep things working well on PR checks and other automations. The important thing, IMHO, is that we remove the <parent> declarations to make examples self-contained.
On Wed, Aug 7, 2024 at 3:31 PM Roberto Oliveira <[email protected]> wrote: > > Hi, > > My comment in the PR was only about not inlining versions from properties > into dependencies. > For example the quarkus version (3.8.4) will start to be inlined twice > (both for quarkus-bom and quarkus-maven-plugin), while for the property it > would be defined in a single place, and AFAIK in Maven people tend to use > properties block for most of the dependencies versions. > > Also I didn't understand why in this thread was mentioned about downstream > builds, as no one in the PR said anything about downstream builds. > But as it was brought up in this thread, yes, we still have a downstream > build which becomes a product, and yes, every release it is becoming more > difficult to build that product due to all changes in the Apache community, > but again, I don't see any mentions of it in that PR... > > > > On Wed, 7 Aug 2024 at 14:22, Jason Porter <[email protected]> wrote: > > > I sent a pull request the other week ( > > https://github.com/apache/incubator-kie-kogito-examples/pull/1988) which > > removes many of the properties in the Kogito Quarkus Examples. It has > > sparked some conversation, and I figured instead of talking on the PR, the > > mailing list would be a better place to have the conversation. > > > > Let me start with the reasoning behind this PR. This was done to make the > > examples easier to understand and easier to use as a starting place for new > > applications/uses. The examples as they currently exist today, have many > > properties used in various parts of the pom.xml file. Some of these > > properties specify versions, others modify maven plugin settings, and still > > others specify the group and artifact ids for any downstream modifications. > > > > It is my own opinion that modifying the community project to make it > > easier on downstream builds should not happen. If any entity is taking the > > community project and building on top of it, it should be up to that entity > > to make the necessary changes from the community source for their usage. > > Modifying the community to suite any downstream activity should be avoided. > > It shows bias toward that entity, and creates an atmosphere of exclusion, > > which should not happen. > > > > For anyone coming to our project for the first time, they should have a > > path of least resistance for onboarding. Our examples should be easy to > > use, understand, and modify. There is simplicity in keeping everything in > > one file and not having to scroll around looking at what a particular > > property is. This also goes for parent poms, but that is a slightly > > different discussion. I believe there is value in keeping our examples > > simple. > > > > The other side of this is the additional maintenance we incur doing things > > this way. It is certainly easier to only have these properties defined once > > and reused in various places. It is also considered best practice by many. > > I would agree with those as well, for everything besides examples. However, > > we’re only talking about a hand full of changes, and these can be automated > > it the build. We’re already doing modifications to pom.xml files during > > builds anyway. It doesn’t add much (any?) additional work beyond what we’re > > already doing. > > > > We don’t know the level of people coming to the project for the first > > time. They may never have seen an Apache Maven pom.xml file before, or they > > may be trying to integrate it into something else which has differing > > versions of dependencies. Making these examples easy to understand helps > > all these people. > > > > I’ve gathered a small list of different Java based projects to show how > > others do this. Unfortunately, there isn’t a single way everyone does this > > in their examples, so there isn’t a guiding example for us to follow: > > > > • > > https://github.com/eclipse-ee4j/eclipselink-examples/blob/master/jpa/employee/employee.model/pom.xml > > • > > https://github.com/eclipse-ee4j/jakartaee-examples/blob/main/applications/kickoff/pom.xml > > • https://github.com/apache/camel-examples/blob/main/basic/pom.xml > > • > > https://github.com/apache/activemq-artemis-examples/blob/main/examples/features/ha/application-layer-failover/pom.xml > > • > > https://github.com/apache/ignite-extensions/blob/master/modules/azure-ext/pom.xml > > • > > https://github.com/apache/flink/blob/master/flink-examples/flink-examples-batch/pom.xml > > • > > https://github.com/spring-guides/gs-spring-cloud-loadbalancer/blob/main/complete/user/pom.xml > > • > > https://github.com/spring-guides/gs-messaging-jms/blob/main/complete/pom.xml > > • > > https://github.com/spring-guides/gs-spring-boot/blob/main/complete/pom.xml > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
