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]
