Open maxandersen opened 4 years ago
/cc @geoand /cc @quarkusio/devtools
cc @iocanel
remove kubernetes and it does not complain. i think its just a matter of understanding what dekorate are looking for and if its just a question about jbang/quarkus spi makes a builditem available with a directory it can write to to mimic target
from maven ?
Yeah, it should be easily fixable :)
I pinged Ioannis since he is the dekorate internals master and would definitely be able to fix this much faster than I could
Will have a fix probably today or tomorrow
On Tue, Sep 8, 2020, 2:52 PM Georgios Andrianakis notifications@github.com wrote:
Yeah, it should be easily fixable :)
I pinged Ioannis since he is the dekorate internals master and would definitely be able to fix this much faster than I could
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/quarkusio/quarkus/issues/11971#issuecomment-688816764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADCEWEGYNKK4S7IECRAOLTSEYLGHANCNFSM4Q73VTJA .
@maxandersen: Do I remember correctly that you mentioned its not a TCCL issue after all?
Hmmm, with jbang we don't have a pom.xml, build.gradle, etc, so this is why the project
can't be properly detected.
We have two options here:
@maxandersen @geoand: Thoughts?
@iocanel the TCCL issue was a false alarm - could still occur but latest fix in how quarkus integrates with jbang ensures you shouldn't get affected by classes loaded by jbang itself which turned out was the case earlier.
I can add some jbang.* properties for sure if that is deemed helpful - but I would imagine best isolation/decoupling is that quarkus is the one taking that info together with what it needs and drive dekorate rather than direct coupling between jbang and dekorate (at least in case of via quarkus) ?
What is the module root you are after exactly ? what corresponds to /target
or the source /
project or /target/classes
? what is dekorate specifically looking for ?
Is there any way dekorate could operate without that information?
When used outside of quarkus, dekorate tries to detect things like the module root (the dir that contains src
the pom.xml
etc).
It needs those so that it gets to the application.properties
, detect things like project name, version, build tool etc and in some cases to use the directory from which builds will be triggered, etc.
When used with Quarkus, most of the information is provided by quarkus, but only to enrich what dekorate didn't figure on its own. I think that the module root is one of them. Let me try and see if we can work around it and I'll get back to you.
Is there any way dekorate could operate without that information?
Technically, it should be possible. But it might need some touches to the upstream project.
There are: 1) CurateOutcomeBuildItem.getEffectiveModel() that returns AppModel which contains the root plus all its deps (from the workspace or the repo) 2) ApplicationArchivesBuildItem.getRootArchive(). Is that insufficient?
I recently added io.quarkus.kubernetes.spi.CustomProjectRootBuildItem
for the purpose of supporting the @QuarkusProdModeTest
, but it might be useful in this case as well.
Basically, we just need to customize the build chain to add this build item when augmentation from JBang takes place
Describe the bug similar to #11888 but this time not about class loading issues but about dekorate assuming 'stuff' we'll need to fix/adapt to.
run that with
jbang --verbose -Dq.v=999-SNAPSHOT quarkusjib.java
and you get: