Community
Participate
Working Groups
In 1.0, we need to provide a command line application equivalent to what update manager is providing: http://help.eclipse.org/help33/topic/org.eclipse.platform.doc.isv/reference/misc/update_standalone.html Some concept may not apply, but that's ok. Also p2 has additional flexibility that need to be kept (e.g. targeted profile, agent.data.area operated on, ...)
I'm looking at the current director application implementation and comparing it with the update manager application. The latter is capable of adding/removing local sites and performing site mirroring. I assume that mirroring is out of scope for the director app since it will be managed by a separate application. What about adding/removing local sites? Would the equivalence of that be to add/remove sub-profiles to a profile? If so, is that in scope for M7?
p2 does not have a concept of sites or global addition as update was providing. The closest equivalent would consists in doing a provisioning operation using the site as a repo.
OK, but from a configuration standpoint, wouldn't adding a sub-profile be somewhat equivalent to adding a group of features? I.e. let's assume that I install Mylyn configured for Bugzilla and SVN into a specific profile. Would it then be possible to add that profile as a sub-profile to my IDE and later remove it again? I always had the impression that this was the way people used "local sites".
p2 does not have a notion of sub-profile (Yes, there is somewhere a method that says getParentProfile() but it is an old wart that should get removed). The notion of site only makes sense when you are capable of separating out the things into various sub-folders which in the p2 vision goes against the idea of bundle pooling. In p2, if you want to promote a group of things to be reused together, you create an IU for this. This gives you much more flexibility because you can share this group without having to give them the zip, etc.
In that case, how does the end user create his own IU's? Is that something that the director application should be able to do?
A user will have to author it by some other means (i.e. creating a feature grouping the things he wants to install). I don't want to turn the director application into an authoring/magic application.
I plan to start working on this today. I see some significant changes made to the director application on April 14. Please notify me if more changes are pending. I'm not a committer to this project so my addition will be more of a big-bang thing then minor commits.
I added some improved argument checking and a -list command. After that I wanted to test the application. That proved to be a bit of a challenge since various services needs to be registered for it to run. The only way I could make it work was to reference the o.e.p2.exeplarysetup.Activator class so that it initialized the p2 infrastructure but I guess that's not how it's intended. Copying selected parts from this activator didn't work either because the classes that it references have restricted access. I checked how this was done with the generator metadata.generator app and could conclude that a lot of friends declarations has been added to other bundles. Before I do the same thing to make the director run, I'd like to raise the question if this is the way it's intended. What if other projects want to use the p2 infrastructure? I know for sure the Buckminster will have such headless applications. Will such projects be forced to request a friend declaration in various p2 manifests? Another solution could be to provide an abstract IApplication implementation intended for p2 apps that took care of all service registration. Such an app could then be shared between the generator app, the director app, the planned mirroring app, etc.
I have no more changes coming. I was just fixing something and decided to do a bit of cleanup to make the code more clear. Including the exemplary setup is not the right direction going forward. Ideally we want to be good OSGi citizen and do proper service tracking and registration (see bug 225250). However doing such a thing now is likely to cause unnecessary disruption and will not help us ship. To test the director application, you should be able to run the provided director application launch configuration. For example I've been doing testing installing CT into a "remote" eclipse SDK with the following command line -console -consolelog -application org.eclipse.equinox.p2.director.app.application -metadataRepository file:d:/tmp/cdt/site.xml -artifactRepository file:d:/tmp/cdt/site.xml -installIU org.eclipse.cdt.feature.group -destination d:/tmp/remoteInstall/eclipse/ -profile SDKProfile and the following vm arg (where eclipse.p2.data.area points at the p2 folder contained in the install you are provisioning into) -Declipse.p2.data.area=d:/tmp/remoteInstall/eclipse/p2
(In reply to comment #9) > ... However doing such a thing now is likely to cause unnecessary > disruption and will not help us ship. > If I read you correctly the way to do it now is to declare the director.app as friend for the needed packages in the core, artifact.repository, metadata.repository and director bundles and then register the services like it's done in the generator app? I'm testing an implementation that does that now and that part works fine. > ... For example I've been doing testing > When you were doing the testing, where was it ensured that the needed services are registered?
I'm getting confused as to how / why you are encountering problems. All the services that you need should already be there. Friendship only has to do with packages visilibity. In the launch configuration, the exemplary bundle gets started automatically. It may be good for the director application to just start this bundle too.
(In reply to comment #11) > I'm getting confused as to how / why you are encountering problems. All the > services that you need should already be there. Friendship only has to do with > packages visilibity. > Well, yes. But take a look at the generator application and how it initializes the needed services. It does not rely on the exemplary bundle. > In the launch configuration, the exemplary bundle gets started automatically. > It may be good for the director application to just start this bundle too. > Now I'm confused. I thought you said that including that bundle was not the way to go?
Thomas, maybe this should be an enhancement request, but I wasn't sure which bugs you are watching. I wanted to let you know that Per bug #215560, we can now mark an IU as locked from an uninstall and/or update perspective. The director application may want to take arguments that allow locking of an IU, I'm not sure. We have the same issue in the installer. We probably want to mark all/some of the profile root IU's as locked for uninstall, so that the user can't uninstall the product from itself. Something like: profile.setInstallableUnitProfileProperty(iu, IInstallableUnit.PROP_PROFILE_LOCKED_IU, Integer.toString(IInstallableUnit.LOCK_UNINSTALL));
Created attachment 96815 [details] Functional director application This is my first take on a functional director application. It registers the needed services in much the same way as the generator application and hence, introduces new package export friends where needed. The patch will add better handling of missing but required arguments and a 'list' command that lists the id's of all UI's in the appointed metadata repo. I'd like this patch accepted before I proceed with implementing the things needed to manage locking.
Thomas, even though the revision of the files in the repo and the revisions that are listed in the patch match, the patch is unapplicable for John and I. Could you please re-issue a patch? Thx
To avoid any further back and forth, instead of providing a patch please attach DirectorTask, Application, and Messages. Thx
Created attachment 97303 [details] Application.java
Created attachment 97304 [details] Messages.java
Created attachment 97305 [details] messages.properties
Created attachment 97307 [details] DirectorTask.java I think the reason you cannot apply the original patch is that it was submitted before Pascals big merge. That's true for the submitted files as well.
Thanks for the patch Thomas. I have released it with the exception of the whole registration / unregistration code which could have turned to be problematic if the application is to be used in an already running application. I reverted to use the ugly exemplary setup. Surely uglier but safer. I have also fixed a bug that existed in my initial code wrt to updating the roaming profile. I have added Cloudsmith in the copyrights. Is this ok? Doc for the application is available at http://wiki.eclipse.org/Equinox_p2_director_application.
