| 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
| Jörn Guy Süß
Registered: July 2009
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
Write update site
Deploy via P2 (if you want it to work)
100% increase on the development cycle steps.
Who came up with this madness?
[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
| Paul Webster
Registered: July 2009
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?
|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
Registered: July 2009
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
|Although p2 will detect plug-ins added directly to the plugins folder (with an associated startup performance cost),|
then it also says:
|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
Powered by FUDForum
. Page generated in 0.03323 seconds