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 > > > > >
