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] > >
