Hi Tibor, Thanks for the explanation. I feel I'm still missing something that will be crystal clear if we know the exact problem the customer has with the parent tag. I guess they have a problem with a dependency and they have to investigate the parent to override the version of one of them, isnt it? If that is the case, it won't be easier to have one unfolded example available to the community that they can extend and keep the examples we are showcasing with the parent approach?. Also, as Nicholas was asking, would a bom be easier for them to handle? Anyway, it will be nice to have a diff view between the current example pom and the unfolded one, because maybe the latter is not so large after all.
On Fri, Aug 9, 2024 at 1:27 PM Tibor Zimányi <[email protected]> wrote: > Hi Francisco, > > the examples serve the purpose of a starting point for users for our > technology. So I personally think they should be as easily consumable as > possible, even sacrificing a bit of maintainability. Unfortunately I cannot > share the feedback as it is from my job, so it is confidential. However in > general, it is as I wrote in the proposal. Users expect to be able to just > take an example and start extending it with their own code. Forcing them to > investigate external dependencies too much, just makes the usability much > worse. I know it even from my own experience from the past. When trying new > technology, it was always much easier for me to start with a simple > standalone example, than to search for clues, why my project doesn't > compile (e.g. because I expect different dependency version than is > declared in some parent module or similar). > > Best regards, > Tibor > > On Fri, Aug 9, 2024 at 1:20 PM Enrique Gonzalez Martinez < > [email protected]> wrote: > > > Hi Francisco, > > As a general principal i would agree with you, but the main reason for > > doing this is to offer basic scaffolding to the end user. If we move > this > > information to the user it will make things more complicated to be reused > > > > El vie, 9 ago 2024, 13:13, Francisco Javier Tirado Sarti < > > [email protected]> escribió: > > > > > Hi Tibor. > > > It would be nice to read that feedback. > > > Without a good reason, I consider information duplication in several > > poms a > > > step back. > > > And I personally found it surprising that having a parent is considered > > > more complicated and having multiple larger poms is not. > > > As a compromise, we can include a template without parent, so users > that > > do > > > not want to use parent in their examples can evolve from it. > > > > > > On Fri, Aug 9, 2024 at 1:10 PM Tibor Zimányi <[email protected]> > > > wrote: > > > > > > > Hi everyone, > > > > > > > > our current kogito-examples are structured in a way that each example > > > has a > > > > parent Maven module, similarly as here (1). From feedback I heard, it > > > > sometimes makes using them more complicated, because they are usually > > > used > > > > as a template for users to start with, when implementing some new > > > project. > > > > They just copy paste them somewhere and extend. With the reliance on > > > parent > > > > Maven module, not everything is enclosed in such example, therefore > it > > > > needs investigation, e.g. about the properties defined in parent > poms, > > > etc. > > > > > > > > My proposal is that it may be good to make the examples standalone. > > 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. > > > > > > > > What do you think please? I can work on that myself, if we agree, > that > > it > > > > would be good to have. > > > > > > > > Best regards, > > > > Tibor > > > > > > > > (1) > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-kogito-examples/blob/stable/kogito-quarkus-examples/dmn-event-driven-quarkus/pom.xml#L7 > > > > > > > > -- > > > > Tibor Zimanyi > > > > > > > > > > > > -- > Tibor Zimanyi >
