When I make one plugin extend another it normally inherits the properties from the parent. Sometimes it doesn't work though.
When the plugin is loaded up, the properties from the parent are all null
What might I be doing wrong? I package my project as a maven-plugin and it builds ok.
I've seen this myself and it drove me mad until I debugged the Plexus internals. I'm guessing the properties are not inherited when the parent is in another plugin?
If that is the case, the explanation below will help. If it is not, it might be a typo in the Javadoc annotations. Maven will skip any tags it doesn't recognise without warning.
If it's neither of these, can you post a little more detail? perhaps an example of the failing Mojo?
If the parent is in another project, here's the reason why you're having problems.
Maven plugins use Javadoc annotations to define the dependencies, goal declarations, and other configurations (Maven 2.1 introduced proper Java annotations but hardly any plugins use them yet). Once the plugin has been installed/deployed the Javadoc is lost, so any plugin that extends a plugin in another jar won't have access to the plexus-defined properties in the parent.
There is a workaround though. The plugin metadata is output to META-INF/maven/plugin.xml. There is a third-party plugin that reads the information from the parent Mojo's plugin.xml and merges the local plugin metadata with it. Your plugin should then work as normal.
Related
The official Kotlin documentation states:
Add kotlin.code.style=official property to the gradle.properties file at the project root.
I'm trying to understand how kotlin-gradle-plugin handles this property.
Which gradle task uses it?
When running gradle build, I don't see my code being reformatted, even if I format my code badly on purpose.
I went through the Github source code of the plugin but couldn't properly get to understand it.
Thanks for your help.
Kotlin Gradle plugin doesn't use this property, as it's not responsible for reformatting the code. Instead, this property is used by Gradle importer of Kotlin plugin for IntelliJ IDEA.
This facade provides access to Gradle properties defined for the project:
https://github.com/JetBrains/kotlin/blob/v1.4.10/idea/idea-gradle/src/org/jetbrains/kotlin/idea/configuration/GradlePropertiesFileFacade.kt
It checks local.properties first in case user wants to override this value in the local configuration (this file is usually added to .gitignore for VCS to skip it during it's operations), then in usual gradle.properties.
Then the property gets consumed to configure the project here:
https://github.com/JetBrains/kotlin/blob/v1.4.10/idea/idea-gradle/src/org/jetbrains/kotlin/idea/configuration/KotlinGradleSourceSetDataService.kt#L158-L159
Same thing goes for Maven-based projects. These are the only two places the property is used throughout Kotlin repository apart from tests right now.
I would like to use the "deploy"-phase of maven to deploy some files to my appliance (using a custom maven plugin), but I don't need the maven-deploy-plugin.
There are several answers on stackoverflow and the rest of the web on how to avoid a plugin being run, for example:
maven exclude plugin defined in parent pom
Disable a Maven plugin defined in a parent POM
I have tried setting <phase>none, <skip>true and <inherited>false. However, the plugin is still configured, which fails with message:
failed to configure plugin parameters for org.apache.maven.plugins maven-deploy-plugin 2.4
because there is no distributionManagement-element in my pom.
Is there a way to completely remove the dependency-plugin from the maven lifecycle?
In my opinion, this is unlikely to work even with those workarounds simply because the maven-deploy-plugin is a core plugin, like it or not.
Therefore, here's another hack:
Create a profile.
Define your plugin in it and attach it to the install phase.
Trigger the deployment, by invoking your profile.
Not as fancy as you would have hoped for, but it should do the trick. If anyone has better ideas, I would also like to hear them, as I've faced this sort of issue as well.
I am trying IntelliJ 12 and one thing is really disappointing.... this is the maven integration.
I am missing following functionality:
effective pom view
search for particular jar trough dependency hierarchy
classpath should be derived directly from maven pom, and not in some crazy random unknown way. I have the case now, where some dependencies are just omitted, and I can see them when executing mvn dependency:analyze
changes is pom.xml are sometimes not reflected in project (classpath does not change, or has still old dependency and new one), also when I click "reimport"
Does anyone know some other maven plugin? Something like m2e would be really nice ;)
As #tieTYT noticed, there is a 'Dependency popup' (Ctrl+Alt+U, Ctrl+F works there).
Idea can automatically detect changes made to your pom.xml and apply them to project. To enable this, press Ctrl+Shift+A, type 'maven auto', choose "Importing", checkbox "Import Maven project automatically";
See https://stackoverflow.com/a/19582120/417846 for my answer. It at least provides a relatively easy way to get the effective pom.
I just moved from eclipse and my idea was, that there are many different plugins for single technology, well not in this case - case closed.
I use a project layout like the first one described in the accepted answer to this question. If my parent-pom is managed, built and deployed separate from my project POMs, how can I ensure the pluginManagement section of my parent-pom is valid?
Maven only checks plugins that actually get used in the build as far as I can tell. Since most of the plugins I'm declaring in pluginManagement don't get used when I build the parent-pom, I have no way of knowing if I have an invalid entry until a child project tries to use a plugin it expects to be managed by the parent-pom.
I've tried the versions plugin, but it seems to ignore plugins that don't exist (ex: typos). I've tried declaring the plugins in my parent-pom with inherited=false, but then I have to tie every declared plugin to a phase. Plus, I don't necessarily want to run those plugins against my parent-pom.
I know lots of people use a parent-pom or a super-pom of some type, so there has to be something I'm overlooking.
In your parent pom module create a set of test maven projects, all inheriting parent pom, using some or all of the plugins defined there, and have parent pom run and verify build success of test maven projects. maven-invoker-plugin can help you in accomplishing all this. This plugin is used a lot for testing maven core plugins so you can find more usage examples in sources of maven core plugins.
Another advice is to add plugins to parent pom pluginManagement only when you need them, then you will have opportunity to test it as well. So steps are, start building a project which uses a given plugin not yet present in parent pom, add plugin to parent pom, release parent pom snapshot, make use of that snapshot in new project, if all OK release parent pom, and adjust reference to parent pom in new project. Later for another or same project if you need additional plugin or newer version of plugin already specified in parent pom, adjust parent pom, release new parent pom snapshot, check if it works for the given project, and if it does release parent pom, and adjust parent reference to newly released parent pom.
I currently have an existing plugin, which references a class from a required plugin. I have replaced this code with a reference to a class which is part of my fragment.
I am facing two issues.
If I import my fragment as a jar file, I am not able to see the changes I have made as the plugin running as an eclipse application results in a ClassNotFoundException
To overcome this, I link an additional source (of fragment) to the existing plugin project. However, the link uses an absolute path, and makes it unfit for deployment.
I want to be able to package the plugin with the code modification and be able to "depend" on my fragment code. Is there a way I can add my fragment as a dependency?
For example:
Plugin Project I am changing : org.eclipse.*.editor
it depends on org.eclipse.*.edit
I have a fragment mydomain.*.edit which has org.eclipse.*.edit as host plugin
I want org.eclipse.*.editor to pick up mydomain.*.edit
instead of org.eclipse.*.edit
ps: I have also tried packaging the jar file for the mydomain.*.edit in the plugins directory and try and pick it up from there, it doesnt show up on the list when I click add required plugins on the dependency tab on the plugin.xml file of the org.eclipse.*.editor
Please let me know if I am not clear enough, I will try and rephrase it.
Thanks in advance!
If I understand correctly what you want to do, I don't think that it's possible. You will have to try some other way.
Plugins have dependencies on other plugins. Fragments don't exist as separate runtime entities, but only as extensions of a plugin. So your plugin can only refer to the 'editor' plugin.
Classes provided by a fragment can't (and shouldn't) be accessed directly. They can be returned by the original plugin (A) if they are implementing an executable extension provided by plugin A.
If you refer to the fragment's code from another plugin (B), the classes will be loaded by plugin B's classloader and be different from the ones that are loaded by plugin A.
What is the purpose of your fragment? Do you want to get access to internal code in plugin A? Do you want to extend an eclipse editor?
If you want to extend functionality that the original plugin is not exposing as extensible, I think the only way is to write a plugin, extend the editor class from the original plugin, register it alongside the original one and use it instead.
[Edit] Maybe this link will explain better: Eclipse FAQ
Hope this helps,
Vlad
Thanks Vlad,
Your explanation was very helpful. Unlike the extension based architecture that is truly intended for fragments, I had to modify a certain component in the editor that was not exposed as part of the extension. This modification referred to an external project I created as an fragment but could have been a normal java project packaged a jar file that I could place in the classpath of the editor.
I was able to resolve the dependency issues by placing the jar file in class path, however when I export the plugins and related plugins as jar files and place it in the dropin directory, it does not install correctly. (Nor does placing the jar files in the plugins directory)
The eclipse editor that I am trying to modify uses the EMF project. I have kept the EMF project in the workspace inorder to resolve dependencies of the editor. However when I replace the EMF jar files bundled with eclipse with the one in the workspace, the files that I want to edit are not correctly recognized.
Is there another way of doing this?