Hi all, as mentioned elsewhere, making "standalone" is the goal, as mentioned in the very beginning: "That means removing the parent tag from each example and extending them with the information needed, from the original parent. This will make it much easier to just grab an example and extend it right away, without the need to dig into parent modules."
But at the same time we should provide all the following: 1. avoid implicit hard-binding with unrelated examples (this is what currently happens with the parent pom) 2. avoid increasing the time needed to maintain the examples (this would be the consequence of a simple copy and paste of all dependencies/properties in all examples) 3. simplify the life to everyone (both maintainers and users) when the version and GAV of required dependencies changes. While I strongly agree on removing the parent, I also have the impression that some sort of "single configuration point" is required. The worst scenario I think is: 1. a user creates a project from an example that has a hardcoded set of dependencies (I'm referring only to our own) 2. in a new version of our code, we add new dependencies, rename some, remove other 3. the user wants to update the original project to the new version 4. the user has to manually fix all the above We may also try to think of some sort of "modularization", i.e. a setup specific for processes, one for rules, one for decisions, etc. etc. We would have on one side a very limited bunch of "setup modules" to maintain, and we would provide a better-focused project to start with. Wdyt ? Il giorno mar 13 ago 2024 alle ore 14:55 ricardo zanini fernandes < [email protected]> ha scritto: > Hi Enrique, > > In another thread, it was mentioned that we were looking for examples of > other projects that follow a similar approach. So, I bought the most used > one. > > Again, I understand users want to copy and paste, which should work. AFAIK > we have a stable branch in the examples directory where the pom parent is > available in Maven, so it's a matter of copying and pasting locally and > running `mvn install`. > > So, I'm not following the roadblocks here. If something has to change, I'd > say migrating to importing a BOM should be the way (and recommended). > Copying every property and dependency to the example can be done IF someone > writes AND maintains a GHA to update everything our main BOM changes to > guarantee ubiquity. Otherwise, it's a -1 from my side. > > > On Tue, Aug 13, 2024 at 6:23 AM Enrique Gonzalez Martinez < > [email protected]> wrote: > > > Hi Francisco, > > > > Maybe the proposal was misinterpreted. This is about exactly making > > these examples as a starting point (scaffolding). Summarizing this: > > > > From the first email: " From feedback I heard, it > > sometimes makes using them more complicated, because they are usually > used > > as a template for users to start with" > > > > So the problem we are trying to solve is to improve the examples in > > order to be used as templates. The proposed solution by Tibor was to > > make them standalone (which makes a lot of sense) > > > > Cheers :) > > > > El mar, 13 ago 2024 a las 11:18, Francisco Javier Tirado Sarti > > (<[email protected]>) escribió: > > > > > > Hi Enrique, > > > One point that I mention but maybe was missed. > > > It is not crystal clear that our examples are intended to be > scaffolded. > > > I would argue their purpose is more to showcase functionality. > > > Thats why I feel, for scaffolding, we should add an empty module with a > > > reference pom and leave current examples as they are, avoiding a copy > > paste > > > festival. > > > > > > On Mon, Aug 12, 2024 at 8:20 PM Enrique Gonzalez Martinez < > > > [email protected]> wrote: > > > > > > > Hi Ricardo, > > > > > > > > If our focus is to provide scaffolding for new projects having > > standalone > > > > projects is the way to go. Having parent pom with dependencies will > > create > > > > a coupling between our examples and end user deployment. I can see > some > > > > problems with that philosophy: > > > > > > > > 1. We cannot change our deps as we will create a dep between the > > projects > > > > and examples and end user > > > > 2. It will burden our examples as scaffolding as it cannot be changed > > among > > > > versions because of the dependency created. > > > > > > > > A middle ground wont be bom but some sort of starters or group > > dependencies > > > > pom. > > > > > > > > Other projects do not necessarily follow what we are trying to do > here. > > > > They might have. Different philosophy > > > > > > > > El lun, 12 ago 2024, 19:29, ricardo zanini fernandes < > > > > [email protected]> escribió: > > > > > > > > > Every proposal to make it easier for users would have my +1. > However, > > > > > removing parent/BOM is not one of them. Having a template like > > > > Francisco's > > > > > mentioned could be a good idea, too, or even importing the BOM like > > what > > > > > Nicolas mentioned. > > > > > > > > > > FWIW, SpringBoot uses parent: > > > > > > > > > > > > > > > > > https://github.com/spring-guides/gs-spring-boot/blob/main/initial/pom.xml#L5-L10 > > > > > > > > > > On Fri, Aug 9, 2024 at 10:00 AM Martin Weiler > > <[email protected]> > > > > > wrote: > > > > > > > > > > > +1 to making it easier for users to consume and adapt our > examples > > > > > > > > > > > > ________________________________________ > > > > > > From: Tibor Zimányi <[email protected]> > > > > > > Sent: Friday, August 9, 2024 5:54 AM > > > > > > To: [email protected] > > > > > > Subject: [EXTERNAL] Re: [PROPOSAL] Making individual > > kogito-examples > > > > > > standalone > > > > > > > > > > > > I will try to get an example of a standalone one. > > > > > > > > > > > > T. > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Saludos, Enrique González Martínez :) > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
