Home » Eclipse Projects » Eclipse Platform » how to force p2 automatically update the bundles.info in **simpleconfigrator dir
|
Re: how to force p2 automatically update the bundles.info in **simpleconfigrator dir [message #336487 is a reply to message #336485] |
Wed, 17 June 2009 08:47 |
Eclipse User |
|
|
|
Originally posted by: aurelien.pupier.esial.net
Ben Xu a écrit :
> I am currently upgrade eclipse from 3.3 to 3.5 for many related tools
>
> p2 is quite different and useless for me. I JUST WANT the old
> way,eclipse automatically detect plugins every time. BUT i never succeed
> on such little demand for all this week.
>
> Any body know how to force eclipse automatically detect every plugin and
> update the bundles.info correctly.
>
> OR the best is don't use the bundles.info file and stupid P2.
>
>
>
Hi,
What do you mean by detect every plugins every time?
They are detected at each start...don't they?
If you want to check for update at each start see :
Window->Preferences->Install/update->Automatic updates
|
|
| | | |
Re: how to force p2 automatically update the bundles.info in **simpleconfigrator dir [message #488502 is a reply to message #336492] |
Mon, 28 September 2009 23:19 |
|
Paul,
While I may object to the wording of the previous post, I also find P2 quite unmanageable. I am observing the same behaviour of P2 being unable to detect altered or added plugins within the structure defined by the documentation. The detection behaviour is sporadic and I had to resort to hacking the bundles.info file.
Frameworks are good, but P2 is a major impediment to development. It should have been tested and more importantly, documented, much more thoroughly than it is.
I am a lecturer in software engineering. P2 is next to impossible to explain. If something cannot be explained in simple terms, its design is bad. Ask Bauhaus.
In the end people will not bother putting there implementations in plugins, because the effort of reuse in prohibitative. I know what I am talking about. In my industry work, practicability and learning effort are the MAJOR hurdles to adoption.
Think about it: "Deploy a plugin" process
Before:
Write library
Write plugin
Drop
Now:
Write library
Write plugin
Write feature
Write update site
Drop
Deploy via P2 (if you want it to work)
100% increase on the development cycle steps.
Who came up with this madness?
JGS
[Updated on: Mon, 28 September 2009 23:22] Report message to a moderator
|
|
|
Re: how to force p2 automatically update the bundles.info in **simpleconfigrator dir [message #488645 is a reply to message #488502] |
Tue, 29 September 2009 15:06 |
|
I concur about the documentation, there definitely needs to be more to explain how to handle the different cycles.
p2 does support at least 3 modes.
Generating features as well as plugins, p2 metadata repositories, and updating the eclipse install (using either the director, installer, or p2 ui) is the most powerful, flexible, and hence far and away the most complicated. It's designed for installing and updating RCP apps, products, as well as the ability to install many artifacts along with a feature that wasn't possible using the old update manager/install handler paradigm. This involves the paradigm you've labeled "now". But when I'm developing, unless my task is Build and deploy I don't do this.
But for development or trying out plugins, there are the other 2 ways of doing it:
1) use dropins ... it's a different location, but allows you to just drop stuff in. I like the added benefit that it supports subdirectories so that I can keep unrelated plugins separate. Plugins can be added with no features, and it even reconciles new or removed plugins on startup without the needs for a -clean
2) if you're developing, you can deploy from eclipse directly into your hosting environment (from File>Export...>Deployable plug-ins and fragments). This is also done with no features involved, and will even correctly patch an SDK feature.
But once again, without documentation how can you guess?
PW
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
Re: how to force p2 automatically update the bundles.info in **simpleconfigrator dir [message #496144 is a reply to message #488645] |
Mon, 09 November 2009 04:51 |
Gergely Nagy Messages: 17 Registered: July 2009 |
Junior Member |
|
|
Hi,
I'm also struggling with upgrading 3.3 to 3.5 of my product just because of P2. Everything else worked fine within the self hosting and my command line build - I really expected more roadblocks. Now I got it:(
We have a fairly simple (stupid?) command line build solution - not using Eclipse to assemble the product, just packaging all bundle jars with their manifests, and dumping them in the target location using an installer.
Before P2, plugins were just simply detected by this line in config.ini:
osgi.bundles=org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start
Now, this is replaced by the simpleconfigurator - which must be the simplest (stupid?) thing in P2: it works on a fixed list of bundles.
Instead, I'd just like to say 'pick all bundles from the plugin folder' - and don't be forced to rework my build system just to please P2.
While the drop-in folder looks nice from the end-user-perspective (yes, nicer than the old way of mixing all plugins together) - as a developer I don't want to ship stuff there just to get the automatic detection.
About docs: the situation might better nowadays. But Getting Started says Quote: | Although p2 will detect plug-ins added directly to the plugins folder (with an associated startup performance cost),
|
then it also says:
Quote: | bundles.info contains a list of all the plug-ins ... Any extra plug-ins in the plugins directory or elsewhere are ignored
|
Which one is true then?
Is there a way to turn on autodetection? Maybe setting the plugins dir as a 'watched directory' ?
Thanks in advance,Gergo
|
|
|
Goto Forum:
Current Time: Fri Dec 27 18:00:16 GMT 2024
Powered by FUDForum. Page generated in 0.02921 seconds
|