This, and many other posts, suggest to change a pom to get it working, which is quite a bold demand as for a mere plugin. Is it possible to leave pom intact and still do not see those errors?
Best regards,Eugene.
Well, it's not possible. This in-POM mess is some kind of workaround if you don't want these errors. Unless your plugin somehow provide m2e connector, you don't have really choice. Sorry.
Related
I have a plugin's resource codes and I want to edit. Because I want to change plugin's prefix but it isn't possible unless edit plugin. I tried edit with Eclipse but I had a lot of errors.
If you have source codes of some plugins, there meight be a problem, that they are using some api for example WorldEdit api, but you don't have it added in your project. You have to look into code and find out what they use. Then download the api and add it in Build Path - Right Click the project->Build bath->add external Jars. I hope this will help.
You may be getting errors from imports, API's, etc.
The best way to change this is to contact the developer of the plugin, who has the project themselves. It's not a good idea to change code unless you have full permission; but I will still tell you some possible ways to fix it.
Your imports may be faulty, check those.
Actually REVIEW the code yourself– Don't mess around with things you don't know what they do.
CHANGE YOUR PACKAGE NAMES (This got me before, simple mistake)
If there are comments in the code, use those to your advantage
Google your errors.
If you are new to Java, don't skip to changing code already. TRUST ME. Learn all you can before skipping to other "higher level" developer styles.
Like I said, these are vague and simple ways to fix it; the best way to have your feature implemented is to contact the developer.
*I understand that this thread is old; I'm just saying this because there are currently no answers that describe this for other Google travelers of the internet.
Currently, I am working in a new project and it was difficult for me to understand since there is no comment. I wonder if it is possible to force team members(including me) to add more comments. I would like to automate this ject in jenkins later if possible.
You can run static code checks and their corresponding eclipse plug-ins to enforce comments being made in code.
For e.g. in CheckStyle javadoc can be enforced http://checkstyle.sourceforge.net/config_javadoc.html
Also checkstyle can be easily integrated with Jenkins.
You can also use eclipse java compiler settings for javadoc check.
Go to preferences->java->compiler->javadoc to enforce errors and warnings.
Compiler errors and warnings can be easily reported through continuous build
cheers,
Saurav
I can only recommend to be very, very careful with that. Of course, you may use tools like SONAR, Eclipse Settings and the like to enforce comments.
Buuuuuuuut:
You can easily generate comments (/w Eclipse) and -as you probably
know- generated comment is not use/helpful at all.
In case you add a useful comment and it relies too much on the actual implementation, you also have to maintain it. Whenever the code changes you need to validate if the comment does too. This is often overlooked and creates more confusion then by not having any comment at all. Even though you had a good intention in the first place.
"The Truth Lies In The Code"(tm): You can achieve good to understand and easy maintainable code by working very hard on it. This might help to avoid to need any comment at all. Its not easy (and not always possible), I admit that.
At least "public API" must be documented. That could be a rule of thumb and it seems managable in a large code base.
I would rather spend more time in having good understandable code instead of "forced comments". You may achieve the complete opposite by enforcing it.
Using Sonar/Eclipse Settings to enforce documentation of public API makes sense to me though.
This needs to be implemented at the source control level, not the IDE level.
If you're using git, you can look into git hooks http://git-scm.com/docs/githooks
This will let you write little scripts that will be run when you commit code. You can write a script to check if the commit includes a valid comment. You can also perhaps allow skipping of comments with a "-force" option or something like that.
for a while now, when I try to addDependency with m2eclipse, the only org.* dependency suggested is the one seen in the pic. A while ago, it would actually suggest a lot of possible dependencies to me. I have not changed anything that I know of, and now it doesn't work anymore. Anyone know what I can do to make this work again? Any cache I can clear?
Two cases I run into a lot:
This editor is great, I should add this plugin to my other Eclipse environments
This looks like a bug, where do I go for more information?
I don't even need the plugin explicitly identified -- just the full classname of the editor would generally be enough. It sounds like I could do this with PDE, but I feel like there must be an easier way.
PDE's Plug-in Spy (Alt+Shift+F1) is how you do it. If you think that's too hard, I'm not sure what to tell you.
Simple usecase: assemble an Eclipse product using simple scripts, just dumping bundles into the plugins dir.
This used to work with 3.3 - with 3.5 it's broken: my application doesn't start as the app plugin is not found.
Question: what's the easiest way to fix that? This seems to be the only pain in the whole upgrade process for me.
Attempts:
I guess this is a no-no for P2: it maintains the bundles.info file instead, which is probably very smart.. a bit too smart for me.
Some ideas I had:
can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
can I set up plugins dir as a 'watched directory'
looks like I need to use the p2.reconciler for that.. oh wait, it's deprecated already :-( bug 251561.. (thanks VonC for the pointer)
can this old setting in the config.ini still work? (which is now replaced with the 'simpleconfigurator') osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
should I call the (p2) director?
"please pick my plugins up" :)
I'd avoid the dropin folder for this - that's more for the
end-users.
I'd avoid messing with the bundles.info if possible.
I don't care about all those smart features in my product yet- actually the users don't use the built-in update mechanism at all.
So I'd like to KISS (ie: just to start up), and add more advanced support when needed.
I've asked this on Eclipse forums, but no answer yet, so would really be grateful for some enlightenment.
Also, feel free to correct me on the assumptions - I've just read the P2 docs, which seem confusing at times.
Thanks!
Answer: actually option 3 above seems to work after all - thanks Francis for confirming this! (it didn't work originally, but that was probably caused by some missing deps).
My only issue with that now is, some Eclipse bundles actually require simpleconfigurator. So I wonder if swapping it out will cause problems down the line.
You can alter your configuration/config.ini file to not use the org.eclipse.equinox.simpleconfigurator (which does the p2-based configuration) and instead use the org.eclipse.update.configurator which is the old-school way of just configuring whatever is in the plugins directory. This should give you what you want.
Even if it does not fully answer what you are after, you can specify in an eclipse.ini (like the one I describe here):
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
That does specify to p2 to monitor any directory of your choosing to detect plugins in it.
Another source of idea could be this article: Composing and updating custom Eclipse distros
It's not hard to create a feature based product that includes these things, and do a product build to end up with something like this:
Note: the concept of reconciliation is detailed in the eclipse Wiki.
For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server.
In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.
Part of this mechanism is the Dropins Reconciler setting. Although, as bug 251561 illustrates, it is not advised to put too many plugins in there.
Maybe this will help you (shot in the dark)? I found this when upgrading my Eclipse installation to Galileo and trying to keep my Flex Plugin install.