I am using Eclipse 3.4 (ganymede official, not the service pack).
I have an update site that organizes features into categories; everything looks great in the editor and in the XML.
Once the site is online, accessing it in the usual manner tells me that all the features are "uncategorized". I've tried from multiple computers running 3.4 and the same problem persists.
What is curious is that I used Eclipse 3.3, and it saw the categories well, though of course it wasn't able to instlal the plugins which are made from 3.4.
Am I doing something wrong or is this a known problem?
It appears to be a known problem, due to the new 'p2' provisioning system.
See this discussion, and this bug. What it seems to say is... "stay put until 3.5M3, and then try it again".
This solution works for me:
Use the PDE update site project to create the site.xml and build your plugins. Make sure you set the category here.
Delete the artifacts.xml and content.xml created by the update site build.
Use the P2 Metadata Generator to generate your artifacts and content files. I use the compress option so I'm getting jars.
The update site should include: the site.xml, content & artifacts jars, features and plugins folders.
If you follow this procedure, it will work just fine in Eclipse 3.3 and 3.4. Naturally, you should automate this process with Ant.
Important notes:
I never got the metadata generator Ant task to work, so I invoke it in its' Java form (the second example in the link above).
Make sure you clear the artifacts and content xmls before the generation
Inputs: site.xml and built plugins/features folders
Specify the metadataRepositoryName which is the update site title (shown to the user in some cases)
I'll do my best to blog about it soon...
Let me know if you have any questions.
What seems to work for me is to put the tag, defining the category in the site.xml, before the tag including the other category tag. If you add the category with eclipse's editor after adding the feature, it'll have messed that up...
A no-brainer for most..but it can be a problem for newbies on Eclipse update sites: be sure to add your feauture as a child under the category:
See http://ekkescorner.wordpress.com/2010/04/18/who-eats-the-categories-from-update-sites/
Related
Is it possible to embed code coverage results (stored in SonarQube) into Github projects as one of those embeddable icon gadgets (not sure what their name is; it would be great if somebody to tell me that as well)...? I'm referring to the ones that show the build status, for example.
The only thing currently available is this under-development plugin, which was first discussed in this Google Group thread. Note that this project appears to be in its infancy.
EDIT
This plugin has since been released, and can be installed directly from the Update Center
EDIT 2
With SonarQube 7.1, badges become a native feature.
Using a plugin in no longer needed, as some new APIs are now added that will do what you want. You can use this snippet in your .md files:
[](https://{domain}/component_measures/metric/coverage/list?id={projectName})
Note that you have to replace parameters inside {}s with your own values. If you are using on-premise version, the domain will be your own domain and if you are using cloud version, it will be sonarcloud.io.
Also note that this will work only for public projects. For private ones, I could not find any solution.
And finally as a side note, the metric parameter takes some values other than coverage and gives other fantastic badges that you may find helpful:
bugs, code_smells, coverage, duplicated_lines_density, ncloc, sqale_rating, alert_status, reliability_rating, security_rating, sqale_index, vulnerabilities
In order to modify an eclipse plugin, what are the steps to find its editable code ?
I read and debug source provided with eclipse distribution but to try a fix in org.eclipse.jdt.internal.corext.codemanipulation behavior I need to make it editable.
Well, the source repository is available at eclipse.org, the plugin compiled with the source should be available from the standard eclipse update site.
I'm guessing you are considering changing the source, recompiling and using your plugin instead of the standard one? There is a different way to change functionality, its with fragments. For example, look at a question I asked earlier, follow the links in my text and Andrews answer for more information.
I have some external libraries that are showing 'warnings', I want to stop validation of this part of my project because it is interfering with actual warning messages from my source code. Is this possible?
I am using Zend Studio but it is based on eclipse so I think the same method will apply on both applications.
You can try to go to Preferences/Validation/HTML syntax validator for PHP files/ click on settings. Add first an exclude group and then add a rule with your library folder. This will work at least with pure PHP warnings. I have a similar question concerning DLTK warnings and also posted this question to ZS forums, but I have not too much hope from there.
I was having the same issue with a dependency we were pulling in and the previous answer didn't help (maybe because it changed in the last 7 years). I found a solution on the Zend Forums.
Word of caution: if your files are having errors, you probably should NOT preform these steps!
To summarize:
Right-click on the folder.
Click "User As Library Folder"
I am newbie to Eclipse, I am planning to use it for AVR development with WinAVR and gcc.
The feature I am looking for is the grouping of different files in the project, like all headers together, all source files together and all files excluded from the build together etc.
I tried AVR Studio from Atmel, it has this grouping feature but it lacks several other features which Eclipse supports. Any help to configure Eclipse Project explorer to display the project files in this way would be appreciated and helpful for me to decide the IDE to use.
Note: I know that I can manually add different folders for each of these groups and move the files, but that moves the physical files, and breaks the relative path in the code, and other comilers/IDE's. I am looking for logical grouping of files.
Unfortunately there is no general way for a user to configure the grouping in the Project Explorer, the grouping is setup based on the code that controls the content (i.e. CDT, JDT, etc). I think it would be interesting to have this feature, but it's not clear the UI that can be used to specify it. You are welcome to submit an enhancement request to add this to the Eclipse Platform UI project. And giving an example of how it's done in another product would be helpful.
Thanks Francis, looking at your profile I think I found the right person to solve my issue :)
I have opened it as a bug (as I could not find a feature request in bugzila) Bug 296514 - Logical Grouping Files in Project Explorer in Eclipse
I have attcahed screenshots of both AVR Studio and Eclipse project explorer. That should give you an idea of what kind of UI features I am requesting. I can difinetely provide more information if you want.
I think what you are looking for can be done with Working Sets.
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.