Open Edition

Hi,

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Ok Bertrand, 

I'm sorry it does not work. I perfectly agree on not messing with src/main/resources during compile-time.
We definetely need to fix the code ASAP, I'll look to see if there is already a ticket for that or how we can manage it.
Best

Gabriele

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Thanks Gabriele for your confirmation.

I will look then forward to your feedback about the fix for this issue.

Kr,

Bertrand

Ok Bertrand, 

I'm sorry it does not work. I perfectly agree on not messing with src/main/resources during compile-time.
We definetely need to fix the code ASAP, I'll look to see if there is already a ticket for that or how we can manage it.
Best

Gabriele

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Hi Bertrand,

FYI: https://github.com/apache/incubator-kie-issues/issues/847

I'm sorry I can not provide any given deadline, but I'll try to do that ASAP

Best

Gabriele

Thanks Gabriele for your confirmation.

I will look then forward to your feedback about the fix for this issue.

Kr,

Bertrand

Ok Bertrand, 

I'm sorry it does not work. I perfectly agree on not messing with src/main/resources during compile-time.
We definetely need to fix the code ASAP, I'll look to see if there is already a ticket for that or how we can manage it.
Best

Gabriele

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Hi Bertrand,

finally I've been able to open the PRs (currently on draft).

https://github.com/apache/incubator-kie-drools/pull/5765

https://github.com/apache/incubator-kie-kogito-runtimes/pull/3427

I've slightly modified your original reproducer, please let me know how I may send it, so that you may give it a try.

Best
Gabriele

Hi Bertrand,

FYI: https://github.com/apache/incubator-kie-issues/issues/847

I'm sorry I can not provide any given deadline, but I'll try to do that ASAP

Best

Gabriele

Thanks Gabriele for your confirmation.

I will look then forward to your feedback about the fix for this issue.

Kr,

Bertrand

Ok Bertrand, 

I'm sorry it does not work. I perfectly agree on not messing with src/main/resources during compile-time.
We definetely need to fix the code ASAP, I'll look to see if there is already a ticket for that or how we can manage it.
Best

Gabriele

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Hi Gabriele,

Good news to read that it will be possible in the next releases of Drools and Kogito to auto-detect DMNs also in /target/generated-resources.

Could you confirm that it will work in a Springboot project but also in a Quarkus project ?

Please share with me your modified reproducer project on any sharing service (eg. Box).

Kr,

Bertrand

Hi Bertrand,

finally I've been able to open the PRs (currently on draft).

https://github.com/apache/incubator-kie-drools/pull/5765

https://github.com/apache/incubator-kie-kogito-runtimes/pull/3427

I've slightly modified your original reproducer, please let me know how I may send it, so that you may give it a try.

Best
Gabriele

Hi Bertrand,

FYI: https://github.com/apache/incubator-kie-issues/issues/847

I'm sorry I can not provide any given deadline, but I'll try to do that ASAP

Best

Gabriele

Thanks Gabriele for your confirmation.

I will look then forward to your feedback about the fix for this issue.

Kr,

Bertrand

Ok Bertrand, 

I'm sorry it does not work. I perfectly agree on not messing with src/main/resources during compile-time.
We definetely need to fix the code ASAP, I'll look to see if there is already a ticket for that or how we can manage it.
Best

Gabriele

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Hi Bertrand,

the feature has been merged in main branch last week.
This is an example demontrating it.
 

Thanks again for your input!

Best regards

Gabriele

Hi Gabriele,

Good news to read that it will be possible in the next releases of Drools and Kogito to auto-detect DMNs also in /target/generated-resources.

Could you confirm that it will work in a Springboot project but also in a Quarkus project ?

Please share with me your modified reproducer project on any sharing service (eg. Box).

Kr,

Bertrand

Hi Bertrand,

finally I've been able to open the PRs (currently on draft).

https://github.com/apache/incubator-kie-drools/pull/5765

https://github.com/apache/incubator-kie-kogito-runtimes/pull/3427

I've slightly modified your original reproducer, please let me know how I may send it, so that you may give it a try.

Best
Gabriele

Hi Bertrand,

FYI: https://github.com/apache/incubator-kie-issues/issues/847

I'm sorry I can not provide any given deadline, but I'll try to do that ASAP

Best

Gabriele

Thanks Gabriele for your confirmation.

I will look then forward to your feedback about the fix for this issue.

Kr,

Bertrand

Ok Bertrand, 

I'm sorry it does not work. I perfectly agree on not messing with src/main/resources during compile-time.
We definetely need to fix the code ASAP, I'll look to see if there is already a ticket for that or how we can manage it.
Best

Gabriele

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

You're welcome ;-)

From my understanding, is it available for Quarkus only or also for Springboot ?

Kr,

Bertrand

Hi Bertrand,

the feature has been merged in main branch last week.
This is an example demontrating it.
 

Thanks again for your input!

Best regards

Gabriele

Hi Gabriele,

Good news to read that it will be possible in the next releases of Drools and Kogito to auto-detect DMNs also in /target/generated-resources.

Could you confirm that it will work in a Springboot project but also in a Quarkus project ?

Please share with me your modified reproducer project on any sharing service (eg. Box).

Kr,

Bertrand

Hi Bertrand,

finally I've been able to open the PRs (currently on draft).

https://github.com/apache/incubator-kie-drools/pull/5765

https://github.com/apache/incubator-kie-kogito-runtimes/pull/3427

I've slightly modified your original reproducer, please let me know how I may send it, so that you may give it a try.

Best
Gabriele

Hi Bertrand,

FYI: https://github.com/apache/incubator-kie-issues/issues/847

I'm sorry I can not provide any given deadline, but I'll try to do that ASAP

Best

Gabriele

Thanks Gabriele for your confirmation.

I will look then forward to your feedback about the fix for this issue.

Kr,

Bertrand

Ok Bertrand, 

I'm sorry it does not work. I perfectly agree on not messing with src/main/resources during compile-time.
We definetely need to fix the code ASAP, I'll look to see if there is already a ticket for that or how we can manage it.
Best

Gabriele

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

For the moment being it has been implemented and tested specifically for Quarkus, since the issue was related to some Quarkus-specific inner implementation detail.

For the moment being, no test has been done with Springboot, AFAIK.

Best

Gabriele

You're welcome ;-)

From my understanding, is it available for Quarkus only or also for Springboot ?

Kr,

Bertrand

Hi Bertrand,

the feature has been merged in main branch last week.
This is an example demontrating it.
 

Thanks again for your input!

Best regards

Gabriele

Hi Gabriele,

Good news to read that it will be possible in the next releases of Drools and Kogito to auto-detect DMNs also in /target/generated-resources.

Could you confirm that it will work in a Springboot project but also in a Quarkus project ?

Please share with me your modified reproducer project on any sharing service (eg. Box).

Kr,

Bertrand

Hi Bertrand,

finally I've been able to open the PRs (currently on draft).

https://github.com/apache/incubator-kie-drools/pull/5765

https://github.com/apache/incubator-kie-kogito-runtimes/pull/3427

I've slightly modified your original reproducer, please let me know how I may send it, so that you may give it a try.

Best
Gabriele

Hi Bertrand,

FYI: https://github.com/apache/incubator-kie-issues/issues/847

I'm sorry I can not provide any given deadline, but I'll try to do that ASAP

Best

Gabriele

Thanks Gabriele for your confirmation.

I will look then forward to your feedback about the fix for this issue.

Kr,

Bertrand

Ok Bertrand, 

I'm sorry it does not work. I perfectly agree on not messing with src/main/resources during compile-time.
We definetely need to fix the code ASAP, I'll look to see if there is already a ticket for that or how we can manage it.
Best

Gabriele

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Good to know indeed!

Do you have any idea when this change will be available in IBM BAMOE 9 ?

For the moment being it has been implemented and tested specifically for Quarkus, since the issue was related to some Quarkus-specific inner implementation detail.

For the moment being, no test has been done with Springboot, AFAIK.

Best

Gabriele

You're welcome ;-)

From my understanding, is it available for Quarkus only or also for Springboot ?

Kr,

Bertrand

Hi Bertrand,

the feature has been merged in main branch last week.
This is an example demontrating it.
 

Thanks again for your input!

Best regards

Gabriele

Hi Gabriele,

Good news to read that it will be possible in the next releases of Drools and Kogito to auto-detect DMNs also in /target/generated-resources.

Could you confirm that it will work in a Springboot project but also in a Quarkus project ?

Please share with me your modified reproducer project on any sharing service (eg. Box).

Kr,

Bertrand

Hi Bertrand,

finally I've been able to open the PRs (currently on draft).

https://github.com/apache/incubator-kie-drools/pull/5765

https://github.com/apache/incubator-kie-kogito-runtimes/pull/3427

I've slightly modified your original reproducer, please let me know how I may send it, so that you may give it a try.

Best
Gabriele

Hi Bertrand,

FYI: https://github.com/apache/incubator-kie-issues/issues/847

I'm sorry I can not provide any given deadline, but I'll try to do that ASAP

Best

Gabriele

Thanks Gabriele for your confirmation.

I will look then forward to your feedback about the fix for this issue.

Kr,

Bertrand

Ok Bertrand, 

I'm sorry it does not work. I perfectly agree on not messing with src/main/resources during compile-time.
We definetely need to fix the code ASAP, I'll look to see if there is already a ticket for that or how we can manage it.
Best

Gabriele

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,

Hi Bertrand,

sorry, I can not give an estimate for that.
The backport could be not so straightforward, since there is a different version of Quarkus behind, but I have to verify.

Best

Gabriele

Good to know indeed!

Do you have any idea when this change will be available in IBM BAMOE 9 ?

For the moment being it has been implemented and tested specifically for Quarkus, since the issue was related to some Quarkus-specific inner implementation detail.

For the moment being, no test has been done with Springboot, AFAIK.

Best

Gabriele

You're welcome ;-)

From my understanding, is it available for Quarkus only or also for Springboot ?

Kr,

Bertrand

Hi Bertrand,

the feature has been merged in main branch last week.
This is an example demontrating it.
 

Thanks again for your input!

Best regards

Gabriele

Hi Gabriele,

Good news to read that it will be possible in the next releases of Drools and Kogito to auto-detect DMNs also in /target/generated-resources.

Could you confirm that it will work in a Springboot project but also in a Quarkus project ?

Please share with me your modified reproducer project on any sharing service (eg. Box).

Kr,

Bertrand

Hi Bertrand,

finally I've been able to open the PRs (currently on draft).

https://github.com/apache/incubator-kie-drools/pull/5765

https://github.com/apache/incubator-kie-kogito-runtimes/pull/3427

I've slightly modified your original reproducer, please let me know how I may send it, so that you may give it a try.

Best
Gabriele

Hi Bertrand,

FYI: https://github.com/apache/incubator-kie-issues/issues/847

I'm sorry I can not provide any given deadline, but I'll try to do that ASAP

Best

Gabriele

Thanks Gabriele for your confirmation.

I will look then forward to your feedback about the fix for this issue.

Kr,

Bertrand

Ok Bertrand, 

I'm sorry it does not work. I perfectly agree on not messing with src/main/resources during compile-time.
We definetely need to fix the code ASAP, I'll look to see if there is already a ticket for that or how we can manage it.
Best

Gabriele

Gabriele,

The configuration added to the pom.xml from my Quarkus project already led to the copy of the DMN files in "${project.build.directory}/classes" at build time and before the Kogito codegen is triggered.

So Having DMN files in "${project.build.directory}/classes" doesn't help unfortunately.

Kogito codegen lookups DMN files in "src/main/**" only. 

I could unpack the DMN file directly into "\src\main\resources" folder instead of "${project.build.directory}/generated-resources/dmn" folder.
But, it is a very bad practice to mess up Maven project (re)sources with generated (re)sources.
Moreover, when I will try to release my Maven project ("com.mainsysgroup.dmn:mainsysgroup-dmn-allocation-score-quarkus"), Maven release plugin will detect uncommitted changes and will refuse to do the release.

So it will generate other Maven issues because Maven best practices are not followed.

Kr,

Bertrand

Thanks Bertrand,

what I see is that based on configuration the files are extracted to "generated-resources" of the main project:
did you try extracting them to ${project.build.directory}/classes (IINW this is where the other dmn are copied) ?
I worked a bit with that code a lot of time ago, and while I absolutely agree it has to be improved, maybe that workaround could work (again, it could be just an attempt)

Thanks Gabriele for your input.

However, did you notice that I'm already using Maven dependency plugin to unpack DMN files from my Maven dependency ?

As you can see in the description of my issue, unpacking DMN files with Maven dependency plugin doesn't solve anything.

My issue seems to be a limitation of Kogito codegen... as explained in the first place. 

Kind regards,

Bertrand

Hi Bertrand.
While Kogito does not provide a solution OOTB, the issue you mention is actually a common one for Maven projects. In that case, you could use the unpack:dependencies goal from the dependencies-plugin. Here's a similar discussion (you have to use correct setup for your use-case). I hope this help.
Best

Gabriele

Hi,