Enrique, please check carefully your comment: For each version, DMN has 5 different xsd to manage. In the next releases we are going to support other two versions (1.6 and 1.7) , that means at least 10 other xsd. For each of them, we need to provide at least a full *execution* tag, which means 20. For each *execution* tag, 15 lines of carefully crafted tags/lines need to be written. That means 150 new lines for DMN 1.6 to start with, and we're going to introduce it very soon (1.7 later on, but not too much, IINW). Then, we do not even consider: 1 possibility of having more then one fallback 2 eventual need of authentication setup All of that, would make that solution to being harder to maintain soonish, IMO
Il giorno mer 11 giu 2025 alle ore 13:30 Enrique Gonzalez Martinez < egonza...@apache.org> ha scritto: > I think Tibor approach is fine as xsd are limited number and they wont > change that often. It is a bit cumbersome but it will do the trick. > > El mié, 11 jun 2025, 12:35, Gabriele Cardosi <gabriele.card...@gmail.com> > escribió: > > > Hi Francisco, many thanks for your comment, I was going to write exactly > > the same things, moreover because some comparison made are extremely > unfair > > and does not enter the real content, but only the external surface 😅 > > As I wrote, I do not like much the other solution proposed because IMO it > > is much more cumbersome and error-prone to maintain longish > configurations > > that depends mostly on sort of "chance" - i.e. combination of flags and > > order of writing - than writing ad-hoc code that by-design provides the > > required behavior. > > The copy'n'paste issue could have simply been solved using > programmatically > > the invoker plugin (a thing I already did in other plugins, sort of > > "standard" for such use cases). > > Anyway, there are multiple cases that would not be covered by my > too-naive > > approach. > > It would require a longish refactoring to ensure that all of them would > be > > correctly managed, so I preferred to close it, since we have an > > alternative, and keep going on with more urgent tasks. > > Reason I mention that is because I did not see any comment about what are > > the real problems behind my solution, why and in which cases it could > fail, > > etc etc. > > And, IMO, this is a symptom of sort of "superficiality" in correct > > evaluation of pros/cons of different alternatives, that often are based > > only on abstract and generic concepts and do not really go inside the > > matter. > > I write this reply only as input/suggestion for the future, and the > > discussion for this specific PR is settled, for me. > > > > M2C > > > > Cheers > > > > > > > > Il giorno mer 11 giu 2025 alle ore 11:49 Francisco Javier Tirado Sarti > > <ftira...@redhat.com.invalid> ha scritto: > > > > > Hi Tibor, > > > I think both PRs have merit. > > > Yours is a kind of simpler workaround for that particular issue. So my > > > kudos ;) > > > Gabriele's is the almost optimal solution from my point of view > (except > > > for the missing simplification to reuse the copy-pasted code, which > would > > > have been my comment in that PR ;)) And it is potentially usable in > > > other scenarios we might have in the future, so my kudos too ;) > > > Now, being controversial. Taking into account (if I understood > correctly > > > the time sequence) that Gabriele's PR was already there when you opened > > > yours, I agree with Gabriele that the second one was probably not > needed. > > > Also, more globally and not strictly related to this issue, we should > not > > > "fear" adding extra code. It is a recurrent comment that adding lines > of > > > code is a negative thing, like if maintaining code by people used to > > > maintaining code was a problem. It should not be, as long as the code > is > > > fine and has a purpose, which is therothetically guaranteed by code > > > reviews. > > > Which is a problem is to maintain cumbersome code that nobody is able > to > > > fully understand or to keep dead code that is not used by anyone, > > > Gabriele's PR does not enter into any of these two categories, so I > > hardly > > > see how a supposed "maintenance problem" can be an argument against his > > PR. > > > Now, being practical. Since Gabriele's PR is already closed and yours > is > > > opened and approved, let's move forward and merge it. If, in future, we > > > need multiple URLs again, then we should recover Gabriele`s PR and use > > his > > > approach. > > > > > > > > > On Wed, Jun 11, 2025 at 9:35 AM Tibor Zimányi <tzima...@apache.org> > > wrote: > > > > > > > Hi, > > > > > > > > I see Gabriele closed his PR and there is feedback from one person > > (thank > > > > you Alex for the feedback). Does anyone else have opinions about > this, > > > > please? > > > > > > > > If it is fine to continue with my PR (as Gabriele decided to close > > his), > > > > could someone please review my PR, if it is fine? I see Yeser already > > > > approved, however based on the guidelines, there needs to be more > > > > reviewers. > > > > > > > > Best regards, > > > > Tibor > > > > > > > > On Tue, Jun 10, 2025 at 10:44 AM Alex Porcelli <porce...@apache.org> > > > > wrote: > > > > > > > > > Hi all, > > > > > > > > > > First of all, thank you both, Tibor and Gabriele, for the work and > > > > > time you put into this. > > > > > > > > > > I understand that Gabriele's solution aims to simplify the > > > > > configuration, which is appreciated. However, it introduces around > > > > > ~1,000 lines of custom plugin code, which brings additional > > > > > maintenance overhead. Based on our experience with build-chain, > > > > > investing in code outside the core Apache KIE domain is something > we > > > > > should approach with caution. > > > > > > > > > > Tibor's approach, although more verbose in configuration, utilizes > > > > > only standard tools and does not require additional code for > > > > > maintenance. The concern is not just about writing more code, but > > > > > about maintaining code that falls outside the core scope of the > > > > > project (such as Maven plugin logic for downloading resources). > > > > > > > > > > Given that, I advocate for and support Tibor's approach as the > > > > > immediate path forward. > > > > > > > > > > At the same time, I'd encourage Gabriele to explore contributing > the > > > > > enhancement to the original plugin. If accepted, we could adopt it > > and > > > > > simplify the configuration. > > > > > > > > > > Thanks again to both of you for your efforts. > > > > > > > > > > - > > > > > Alex > > > > > > > > > > On Tue, Jun 10, 2025 at 2:59 AM Tibor Zimányi <tzima...@apache.org > > > > > > wrote: > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > for external XSD downloads for the DMN and BPMN standard, we have > > > Maven > > > > > > modules that downloads those XSDs and packs them into jars. > > Recently > > > > > there > > > > > > was a problem with the Drools build, because the OMG organisation > > had > > > > > some > > > > > > outage and the XSDs were not available to download, so the DMN > XSDs > > > jar > > > > > > build was failing. To fix the problem, there was an effort to > have > > > > > fallback > > > > > > URLs for download. For DMN, there is GitHub organisation of the > OMG > > > RTF > > > > > > taskforce, that contains these XSDs. > > > > > > > > > > > > We have two proposed solutions, how to have the fallback > downloads > > > > > > implemented. Gabriele implemented a custom Maven plugin, > extending > > > the > > > > > > download-maven-plugin that we already use to download the XSDs. > You > > > can > > > > > see > > > > > > it in his PR here (1). I myself found out that such fallback > > > downloads > > > > > are > > > > > > able to be configured without any custom code just using the > > > > > > download-maven-plugin we aready use. You can see my solution here > > > (2). > > > > > > There is some discussion about the proposed solutions in my PR, > > where > > > > > > Gabriele thinks my solution is not ideal and where I think > > Gabriele's > > > > > > solution is not ideal. > > > > > > > > > > > > Could you please review both solutions and give us feedback, > which > > is > > > > the > > > > > > preferred one? > > > > > > > > > > > > Best regards, > > > > > > Tibor > > > > > > > > > > > > (1) https://github.com/apache/incubator-kie-drools/pull/6370 > > > > > > (2) https://github.com/apache/incubator-kie-drools/pull/6371 > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > >
