Maven codegen Mojo #5319
Maven codegen Mojo #5319
Conversation
You need a make your plugin an extension and define a custom packaging type for this to work, or you need to use |
@laeubi Thanks heaps. I will have a look. |
|
@rotty3000 @bjhargrave @timothyjward Guys, I need some help. I still have some issue with the problem from above. Here the TLDR of my initial issue for context:
@timothyjward gave me the advice to use the Now my problem:We use the My conclusion so far: The shade plugin and the flatten plugin are 100% incompatible and for some reason the share plugin causes a pom.xml that by the integration test can't be resolved and thus maybe maven in general (the it-respo it creates for the test seems valid). Right now, my only option to make this work is by searching for the generate plugin in the normal module dependencies, which works fine. This however is actually wrong, as this is a dependency which would fall under the plugin management and not the module dependencies. Before nothing works I would go for this solution, but only reluctantly. Any advice? |
maven plugins are open source so you probably want to propose a patch.
You most probably want to change execution order of the mojos then
I'm not sure if this is "typical" if you actually don't want ti on your mojos classpath, because the typical use for this is:
Your description of the problem sounds not that this is what you want, but I'm not completely sure why you need the additional things, but if you just want to analyze them in some way, or pass them to some code, it would be more suitable to mention them in the configuration section of your mojo and just use the Maven resolver (something along the lines like this: https://github.com/eclipse/tycho/blob/3d62159014ee3613b5e6e1c8337ce3521535dc9b/tycho-core/src/main/java/org/eclipse/tycho/osgi/configuration/MavenDependenciesResolverConfigurer.java#L62) you can even resolve transitive ones and then you can get the artifacts file and do whatever you want with it. |
|
I just noticed that the BND baseline mojo do something similar to look-up the basline artifact ... |
The generate plugin in and of itself will not do anything. It can execute code generators provided by third party libraries. After a night of sleep, I would provide the mojos plugins via the configuration with something like: |
juergen-albert
force-pushed
the
maven_codegen
branch
2 times, most recently
from
a123867
to
ed6d824
Compare
Signed-off-by: Juergen Albert <j.albert@data-in-motion.biz>
Signed-off-by: Juergen Albert <j.albert@data-in-motion.biz>
Signed-off-by: Juergen Albert <j.albert@data-in-motion.biz>
juergen-albert
force-pushed
the
maven_codegen
branch
from
a43a18e
to
969f2ad
Compare
|
@bjhargrave I have split the commits as discussed. I hope this works better now. Can you have a look and remove the draft Marker? Thanks |
|
okay, it seemed that I was able to remove the draft state myself... |
|
Replaced by #5385 |
This PR is meant to get some early feedback on this.
The Mojo provides support for the generate mechanism via external plugins. The general bnd generator mechanism reads the instruction and looks in the workspace if it finds a bundle that provides a properly named external plugin capability. Thus I need to provide a Repository containing the dependency with the generator.
At the moment I use the build dependencies as source for that similar to our Mojos that work on a bndrun. This seems a bit wrong, as this is actually a Plugin dependency and no direct dependency of my maven module. I tried another approach doing the same based on the plugin dependencies. There is a problem though. Plugin dependencies are part of the Mojos Classpath when bnd starts it. If I didn't read the code wrong, generate requires a repository and will load the resulting jar in a completly isolated classloader. This in theory should not cause any issues with the Mojos classloader, that already has this jar.
So much for the theory. Reality poses other issues however. The isolated nature of the external plugin requires an all in one jar, that packs every class it will ever need. In the case of my generator I use and thus package e.g. Promises in an older Version. Because my generator is now on the classpath, it can break the Mojo and causes:
The classloader hirachy looks as follows (my generator is
url[1]and the correct promise jar isurl{37]):Thus I decided to stick with the method of using the build depencies, even though this goes against the typical mechanism with the extended plugin classpath.
@rotty3000 @pkriens @bjhargrave
Any thoughts or ideas on that?
Additional things that are on the todo list: