-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for hidden dependencies #12
Comments
Let me try if the smart builder is considering the plugin dependencies when building the dependency tree. Adding |
I thought using the code in https://github.com/gnodet/mvnd/pull/13 and building with |
|
Yes, that's one of the problem with a parallel build: all dependencies must be explicitely defined, as we can't rely on the order in which modules are defined. |
Yes, but Quarkus extensions are a bit special in this respect. The deployment module is not declared as a dependency by design. It does not suit any of the traditional Maven scopes. It is actually only pulled by the Quarkus plugin to be run at built time. So declaring it as a dependency of the Quarkus plugin seems be closest to what it really is (although the plugin does not require that). I will try whether the smart builder will honor the declaration and schedule the deployment module before the itest. But anyway shouldn't mvnd offer an official way to adjust the build order? I can imagine many projects will have similar problems. E.g. a system property? Something like
|
|
Adding the deployment deps as plugin deps seems to solve the scheduling problem, but the effective result seems to be a corrupted local repo. Thinking so because the stock mnv is throwing the same errors in Steps to reproduce should be
|
The failures in the previous comment are caused by the fact that the Quarkus plugin does not like to have the deployment modules in its class path. So I tried to add the deployment modules as deps of another plugin see here https://github.com/ppalaga/camel-quarkus/commits/191003-hidden-deps.1 and it works! |
So adding the hidden deps to some plugin is a valid workaround, but the question is still open whether |
I agree we should provide a way to add dependencies for ordering purposes. Using properties definitely looks like a good way. However, I'd rather move such information in the parent pom rather than dispatched in the various modules. This would also enable to use wildcards to define those additional rules. This would also benefit camel which also has similar problems. |
I wonder what would it look like? Would those be honored also when not building from the root dir? Having it in the dependent module seems to have the following advantages:
|
I've added support for top level rules for now. The syntax is the following:
The The rules have to be defined as the |
A simple top level rule is
|
We could also add support for non top-level rules where the right part of the rule would be implied to the current |
Just added support for local rules defined using |
Out of a sudden, mvnd started building in parallel. You perhaps changed the defaults - no matter, I like it. Not sure why exactly this happens, but my spontaneous theory is that this is not a mistake of
mnvd
, but rather a mistake of how the deps are declared in Camel Quarkus. In particular, the itests do not directly or indirectly depend on the-deployment
modules andmnvd
is free to assume that the-deployment
modules do not need to get built before the itests.I wonder how this could be fixed in the Camel Quarkus source tree? Adding an explicit
-deployment
dependency to theitest
project would perhaps solve the problem, but I'd find that highly unidiomatic. Do you happen to have a better idea how to fix that?The text was updated successfully, but these errors were encountered: