Community
Participate
Working Groups
I just finished converting relatively large codebase to plugin projects and decided to share my experience and extensions to PDE I've made to make this job easier Our code used quite a few thirdparty labraries like log4j or jdom. New plugin from existing JAR is a nice wizard, but I found it annoying to look for JAR files on filesystem when I can see the JARs right in the Package Explorer view. I've added to action to invoke the wizard by right-clicking on one or several jar files from Package Explorer, Navigator or any other view. Another annoyance with New plugin from existing JAR wizard is that after importing say log4j.jar I had to manually update all projects that reference the jar and replace JAR-file reference with project reference. Really tedious. I've extented New plugin from existing JAR wizard with an option to do that automatically. After importing all my jars and converting all my projects to plugins, I've found that I had to manually add plugin dependencies even though this information was already available in .classpath files. Really, really tedious. To address this, I've introduced new "Update plugin dependencies..." action. After implementing these little enhancements, overall conversion was rather simple and quick job -- 1) created new plugins from jars which also established dependencies on the new plugins 2) converted projects to plugins 3) updated plugin dependencies 4) updated project classpath
Created attachment 27080 [details] proposed enhancements Hope you find it useful ;-)
thanks Igor. I have always wanted this functionality but never had the time.
Forgot to mention. I could not find API to manipulate list of dependent plugins and UpdatePluginDependenciesJob manipulates META-INF/MANIFEST.MF using java.util.jar.Manifest. Likewise, I could not find API to distinguish plugins from fragments and hacked something in isPluginProjectEntry method. I will update the patch if you show me appropriate API calls.
that is fine. I'll clean it up. It should make it into M2.
I really like this idea, lets see what we can do for 3.4.
Adam, if you get bored at quickfixes, you can take a look at this one. There's a starting patch to help get you started. I would consider this item a possible noteworthy as this is useful.
Bartosz... you think you can take on this one?
yes, sure :) I've browsed through the code.but I'll have time to go deep into it during the weekend. if it's ok for you assign it to me
ok Bartosz, you win ;)
Bartosz, I'm going to give this one back to Adam since he has "all the time in the world" now :) If you have a problem with this, let me know.
Actually Bartosz, this is yours again :D Adam is tasked with some other work. Sorry for the confusion.
Created attachment 77995 [details] Igor's patch converted to 3.4 I've converted Igor's patch to 3.4 small changes added to code, but it still needs some improvements. eg. some checks if there is already reference to project (for now it is possible to run "crate plugin..." action from jar that is not in the classpath) do you think that allowing exporting multiple jars to one plugin is reasonable. for now create plugin is enabled for single jar selection
Created attachment 77996 [details] mylyn/context/zip
I'll look at this one... I'm very excited to see this go in as this has great benefit for the community.
I'm fine with a single jar selection for now. I think we can make this patch a bit simpler as right now, it's hard to go through. I have found some problems also. How about this... 1) Let's remove the Update Plug-in Dependencies action contribution (along with wizard) to simplify things. This action should happen part of the "Update references to the JAR files" action within the wizard. 2) When updating references to the jar file, this should happen. * We update the classpath so the jar file is removed * We add a Require-Bundle on the project (we can invoke UpdatePluginDependenciesJob from here I believe) I didn't see this happening in my simple test case. But by doing this, we effectively wouldn't see the Update Plug-in Dependencies action contribution as it clutters the already confusing PDE tools menu. Does this make some sense?
(In reply to comment #15) > 1) Let's remove the Update Plug-in Dependencies action contribution (along with > wizard) to simplify things. This action should happen part of the "Update > references to the JAR files" action within the wizard. "Update Plug-in Dependencies" has to do with java project dependencies, if I remember correctly. For example, you have two java projects, testA and testB, and testB depends on testA, this dependency is NOT converted into bundle dependency by existing "Convert Projects to Plug-in Projects..." (just checked with 3.4M1).
Isn't that a crazy name for something for updates java classpaths only ;P? If you have a request for something like that, I would put it in the other bug, I don't see it fit within this use case. My scenario outline in 1) should cover the bases. Thanks for the patch, it helped us quite a bit to get started with this problem.
My use case was "Convert 200+ java projects into OSGi bundles" and I needed to deal with both referenced JAR files and inter-project dependencies. I agree these are two separate enhancements, but I believe both of them are equally important.
One step at a time :) Wow, 200+ jars, that's a daunting task ;d I'd be looking for the nearest COOP / intern :) It is my opinion that whatever the operation is, it should occur as part of the wizard's finish operation. I'm not a big fan of separating out different menu pieces within PDE Tools. Let's see if we can get everything done with one clean succint operation.
Correction, 200+ java projects and 50+ jars. I did have a coop to do the job but I did not want her to hate her job for the rest of her career. ;-) Besides, there would be too many mistakes if we did this manually. Seriously speaking, conversion of java project dependencies is kinda tricky because you do not know order/grouping in which projects are going to be converted. I agree it'd be nice not to introduce new actions (especially with such confusing names) but I could not find a nice&easy way to incorporate this conversion into any existing flow.
I'm thinking about one more wizard page. "update references in other projects". if we bulild project from plugin's lib only references within this project are updated. this option can be helpful if we have other plugins that have the same lib on the classpath and we want to update references in one shot manner. If we are talking about 200+ scenario. well still there is one question. can it be done in one wizard ? by now there new plugin wizard is used to build and *name* new plugin. should be this wizard fired 200 times during multiple selection (which is not allowed by now) ? there are two scenarios, when we take multiple selection into account. first is to build many one-jar plugins, second is to build one plugin containing many jars.
Created attachment 78695 [details] this is a gui illustration this is rather gui demonstartion than patch. most of function doesn't work jet. if you have gui comments, i'll glad to hear
Created attachment 79487 [details] this is latest patch proposal features: - multiselect on jars from many project (but only jars that are on classpaths in plugin projects) - project to update selection page - comparison on jar files level (content for jars is compared rather than its location) concerns: - problem when "externalising" jars that are exported in given plugin - warnings and error check is needed - better user iteraction (e.g. by monitor support) - clumsy code style (but this is only function illustration :D )
Created attachment 79488 [details] mylyn/context/zip
Created attachment 79545 [details] latest version (allows also for external jars) sorry for last tripe code. there was couple of issue to fix, this proposal has the same features and concerns that the last one ;)
well done!
Created attachment 84326 [details] job code part this is the first part of previous patch. content: creation operation code update
Created attachment 84328 [details] second part content: - PDEUIMessages + properties file for NewLibraryPluginCreationalPage - plugin.xml with the new action - ConvertJarsAction (part that starts wizard commented)
I committed the first wave of patches (patch #1). I will look at committing the second half of the patch later today. I noticed there were some gnarly ids like "com.ibm.tpm" in there Bartosz, you may want to fix those IDs to be more PDE compliant. Thanks Bartosz!
Created attachment 84335 [details] name convention fix sorry I don't know how that happend. i've never worked on tivoli :)
I committed more code to HEAD Bartosz, the contribution is currently disabled as we don't want to expose anything until it's completely ready. Feel free to continue work and post patches as you progress. It should be much easier to manage. Also, I will post another bug for you to handle regarding the creation of plug-in projects from JARS. I believe to make things easier, we should create a source folder and put the classes in that source folder, and export all the packages to really make it a true bundle. Currently, we don't do this.
Created attachment 84502 [details] last part of the patch wizard + wizard pages update to CovertJarsAction (feel free to remove commented part of the plugin.xml)
Created attachment 84503 [details] mylyn/context/zip
Thanks Bartosz for your hard work on this one. It's a great enhancement!
Created attachment 86041 [details] mylyn/context/zip
