| Blending Packages [message #1016995] |
Fri, 08 March 2013 14:16 |
 a platypus
Messages: 2
Registered: December 2012 |
Junior Member |
|
|
Hi gang!
Here's a quick overview of something I think the Eclipse project will need to consider eventually. Try to think about 'how' and 'when' rather than 'why'.
After I used the Upgrade function on Juno / JDT today, it crashed spectacularly. It won't run. Looks like I'm back to a fresh install, new package, etc. Downloading the 'extra' modules, etc. AGAIN.
In truth I don't really want a future where that's the only way to 're-boot' Eclipse. I haven't found too much on making my 'own' package either. This is interesting for people thinking about ways to avoid this cul de sac.
However, again, this isn't my idea of fun. For one thing I'd need to maintain the 'packaging' for as long as I needed and for another it isn't a general solution.
My Preferred Option
I'd like it if there was some way to 'share' components among the downloaded Eclipse packages. So for a simple illustration, I could download the Eclipse Modelling Tools package and the Eclipse IDE for Java and Report Developers, to name two.
These two have slightly different configurations. However they substantially overlap in many key areas, see: How to Combine Packages
So what I'd like to see is how I can keep the 'package' entity but share or reuse the components, plugins, etc. So if the modelling package updates the , then there would be no need for the JDT & Report Eclipse to update Mylyn as well.
That is because the components themselves would rest in a shared repository.
How do you do this? I'm not sure (yet); my outsider view is to use a different ".ini" or ".config" file to list the components that a package registers when it starts. That is kind of like a late binding of the Eclipse.exe runtime to one configuration or the other.
For example; everything uses the same folder structure as at present. The difference might be that there'd be an optional start-up parameter to choose a package configuration, like:
- Eclipse.exe --config JDT_Report.cnf
- Eclipse.exe --config MDT.cnf
The default would be as it works now or to look for "Eclipse.cnf". So the .cnf file is like an a la carte selection for the OSGi bundles to load. My expectation is that 99% of the plumbing to achieve this already exists. It could be as straightforward as reorienting the start-up sequence.
Anyway some discussion is worthwhile.  The main 'pro' for me is with two, three and more packages 'installed' I only need to update each component (e.g. Mylyn) the once. That will save me time.
I'm hopeful too that it is part-way to avoid crashes like today's event, and further avoid some clashes and conflicts I've had between components that don't need to be in the same Eclipse runtime package; they are just there as the next best option to having two or three Eclipse configurations and needing to update the same bits three times. Also the conflict thing ... With this '.cnf' idea, you can edit the file and snip suspect component bundles to identify conflicts. (Well, may be).
Let's see some pros and cons.
Cheers,
Will
|
|
|
Powered by
FUDForum. Page generated in 0.01831 seconds
Search
Help
Register
Login
Home
