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]
