Hi everyone, as we don't have a clear alignment on the purpose of the kogito-examples, I am currently withdrawing this proposal (may be reopened in the future) and will make another one, so we align on what we expect from the examples. Thank you for your feedback.
Best regards, Tibor On Wed, Aug 14, 2024 at 10:25 PM Jason Porter <[email protected]> wrote: > A fair point about plugins, properties, profiles, etc. > > As far as Maven goes, there is no difference between using an imported pom > or declaring dependencies one at a time. You are absolutely correct in that > regard. What is different though, is how it looks to someone for the first > time. Imagine using a brand new project for the first time. You don't know > how it works or what is necessary. The example uses an imported pom in > their setup. Great, you go find that pom file (one additional step). > Assuming that pom file doesn't itself have an import nor a parent pom, all > you have to do is parse through all the stuff in the imported pom and > figure out what the version numbers are of the dependencies that are used > (a step you'd have to do anyway if the dependencies are already in the main > pom, however, it is another file to look at and keep in your head while you > do this). Now, if there are any profiles, build chain modifications, > plugins, etc. you also need to figure out if those are relevant in your own > situation to use them (another step you have to do). > > But you could use the maven dependency:tree to see what is there without > looking up the imported pom some may say. Absolutely you could, if you > happen to know about that. Honestly, I think developers that end up working > on projects, especially in open source forget how much the average > developer knows or doesn't know. At the end of the day, your average > enterprise developer simply wants to know how use the thing they've found > or been tasked with using. That is exactly why there is so much copy and > paste of code from things like Stack Overflow or ChatGPT. It solves a > problem they have now, and does so fairly easily. Is it the right solution? > Maybe, maybe not. Will it create problems down the line? Again, maybe, > maybe not. But it is easy and gets you moving on with the next task. > > What I'm trying to do with a standalone example, or an example that is > easy to extend, is to give the average developer the easiest path we can > toward using our product. You don't have to look through more code, you > don't need to guess, and you certainly don't need to waste hours or more in > trial and error. Any solution that leaves most developers in that situation > will be disregarded as a poor solution, even if in the long run it is a > better solution. > > I want Apache KIE to be the solution that is the easiest to pick up and > run with. > > On 2024/08/13 17:27:23 Gabriele Cardosi wrote: > > Hi Jason, > > l wanted to underly what IMO are the critical aspects to consider, to > avoid > > bigger problems in future; but tbh, I also think it is just a matter to > > define one (or more) bom, and declare them as import (as already > mentioned > > by others). > > For dependency resolution and standalone pov, there is not a substantial > > difference between declaring all the dependecies one by one or import a > bom. > > As per plugin, properties and profiles, I think those should be > completely > > excluded because those reflects, more or less, "our" own environment, and > > could be useless, if not cumbersome, for other users, that needs a > > "template" as most generic as possible. > > IMO the problem we are facing is very common in the maven world, nothing > > fancy, and this is one of the standard way to achieve what we are > > discussing about. > > > > m2c > > > > Gabriele > > > > > > > > > > Il Mar 13 Ago 2024, 18:54 Jason Porter <[email protected]> ha > scritto: > > > > > I'm not sure how to achieve all of those ideals you've put forth, > > > Gabriele. If we don't have a parent pom, and you can't inherit > everything > > > (I think?) from a BOM (thinking things like profiles, properties, > plugins, > > > etc.) there will be some additional maintenance. Maybe it is some XSLT > > > files or a shell script, I don't know. But hitting all of those is > going to > > > be difficult. > > > > > > On 2024/08/13 13:40:13 Gabriele Cardosi wrote: > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > >
