Community
Participate
Working Groups
We're providing a testing tool that allows users to create a plugin project for testing other plugins. We're using our own wizard to create the plugin. The only easy way to create new Plugin projects programatically is hidden away in the goodness of NewProjectCreationOperation. NewProjectCreationOperation is the only class that has all the convinience API to create a plugin project given the parameters via the constructor. Would it be possible to open up this API, and the API injected via its constructors namely (PluginFieldData, IProjectProvider) ? I've willing to submit a patch if any cleanup is needed to make this API.
I can see how this could be useful as API, but am hesitant to add more API in an area where we need to adapt for any new features we add. Decoupling the creation from the UI using IFieldData or some such thing would be a good place to start. Reassigning to Ketan as he would like to look into it.
*** Bug 257949 has been marked as a duplicate of this bug. ***
It would be great if we could get closer to separating the UI/core components of plug-in creation. Any luck with this Ketan?
Ketan, so you know, the bug I reported for which this became an enhancement, is one for which I wanted the core components separated so I could create plug-in projects from the command-line.
The current operation talks to wizards, and all data structure objects are sitting in the UI project. I do not see how this operation can be made headless. I would end up replicating the same interfaces in core, that essentially expose the same interface as ui. Any bright ideas would be welcome. This is going to be one major change which I may not be able to perform without proper version control.
I wrote most of a version that did separate them correctly, with one exception that would have required a utility class of a sort for manipulating the required bundles string. It was a bit of a messy solution, what with the environment being new to me and a first run, but I have let it sit idle. So, here's the thing, then. If this feature request is not about providing a core API, then I would like to reopen the original feature request, and we can go with that. What do you think?
(In reply to comment #6) > So, here's the thing, then. If this feature request is not about providing a > core API, then I would like to reopen the original feature request, and we can > go with that. What do you think? Are you implying that you've created some form of a 'UI-API' ? Creating a UI-API is something that would be much simpler to do, as it would not involve much thought into API breakage. Curtis what do you think, given that bug 188795 refers to pushing this into core, while a lot of the models that assist in creating the plugins sit in UI. Do you think it is a good idea that these public interfaces be pulled up into core (mark the ones in UI as deprecated) and proceed from there ?
I didn't create a UI API. I abstracted those parts of converting a project to a plug-in project that were core only. It was a proof-of-concept, but it was clearly feasable. And what I did was most likely not worthy of an API, but if you read my comments about what I was looking for, it wasn't even a supported API, as I was willing to deal with a shifting API over releases. I mean, if you were to say that it was not possible to write a piece of code that converts a standard java project into a plug-in project unless we used plug-ins and classes that relied on the UI, I'd be shocked. Or maybe I'm misunderstanding you.
(In reply to comment #7) > Curtis what do you think, given that bug 188795 refers to pushing this into > core, while a lot of the models that assist in creating the plugins sit in UI. > > Do you think it is a good idea that these public interfaces be pulled up into > core (mark the ones in UI as deprecated) and proceed from there ? What I want to see is a better separation of the wizards and the operations that create the project. While I think the operations probably belong in core, just having them able to run programmatically from the ui plug-in would be a great start. As Ketan pointed out, making the separation isn't easy, especially since we cannot break any template providers (which are integrated into the operation), but it is doable. Unfortunately I don't have time in 3.5 to put towards this, but I will try to support any contributions.
Ok, so assuming that the UI API is written and no Core API is written, will this bug remain open?
(In reply to comment #10) > Ok, so assuming that the UI API is written and no Core API is written, will > this bug remain open? > If we split things up in the UI plugin and don't move anything into core, this bug will either remain open or another one created at that time to move things into core. Ketan, if the only thing keeping you from trying a rewrite is having to deal with one massive patch, I can branch pde and apply any patches to that branch.
(In reply to comment #11) > Ketan, if the only thing keeping you from trying a rewrite is having to deal > with one massive patch, I can branch pde and apply any patches to that branch. Thanks I never understood CVS at all, and the eclipse tooling does not make it better. I'll stay on trunk and manage. My problem is revision control for my ongoing work. I've blogged about this here: http://ketan.padegaonkar.name/2009/01/24/using-mercurial-with-eclipse-cvs.html in case someone else needs to make a one-big-patch for something like this.
Robert, You did mention in comment #6 that you had a working implementation of something similar, would it be possible to share that, and I could see how I can base my work off that. This would allow me to see what kind of API clients would expect, before adding it in.
FYI, I have lost track of this issue, and don't know where my code went. Weep!
I'm going to mark this as a dupilcate. *** This bug has been marked as a duplicate of bug 188795 ***
