I'm suggesting that because I'm assuming that most of our current examples are closed ones, not really intended for extension by users, but as a showcase of the system functionality. In fact there are few of them that are pretty complex and specific (requiring several quakus instances) and it does not really make sense to extend them at all. However, I do see the case in which an user wants to start writing BPMN with a self contained pom, so I feel the issue being discussed will be solved exposing one maven module that have a self container pom and en empty bpmn, witn not IT test (as we usually have in our examples)
On Fri, Aug 9, 2024 at 1:39 PM Francisco Javier Tirado Sarti < [email protected]> wrote: > 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 >> >
