[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Provisioning a profile without copying local artifacts

Thanks for the response Pascal, setting the cache extension property did the trick.  In fact it didn't require much in the way of code changes as I was already storing the list of local artifact repos so I could grab urls for the bundles after the provisioning was complete.

We will consider using a writable composite repository in the future, but the cache extension both works and makes a lot of sense.

Curtis


From: Pascal Rapicault/Ottawa/IBM@IBMCA
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
Cc: P2 developer discussions <p2-dev@xxxxxxxxxxx>, p2-dev-bounces@xxxxxxxxxxx
Date: 2010/01/18 09:39 AM
Subject: Re: [p2-dev] Provisioning a profile without copying local artifacts





At this point I could see this being done by setting the *non-API* property called org.eclipse.equinox.p2.cache.extensions to point at each repository that already has content (e.g. <property name='org.eclipse.equinox.p2.cache.extensions' value='file:/Applications/eclipse/.eclipseextension|file:/Applications/eclipse/configuration/org.eclipse.osgi/bundles/1035/data/listener_1925729951/'/>)
A cleaner way would be to create a writtable composite repository and use it as the bundle pool. this composite repo would then point to each repo with content and point to a writtable repo.



Inactive hide details for Curtis Windatt---14/01/2010 06:05:26 PM---PDE's newest target platform work involves using a p2 profiCurtis Windatt---14/01/2010 06:05:26 PM---PDE's newest target platform work involves using a p2 profile to collect and provision targets. This was somewhat possible in

From:

Curtis Windatt/Ottawa/IBM@IBMCA

To:

P2 developer discussions <p2-dev@xxxxxxxxxxx>

Date:

14/01/2010 06:05 PM

Subject:

[p2-dev] Provisioning a profile without copying local artifacts





PDE's newest target platform work involves using a p2 profile to collect and provision targets. This was somewhat possible in 3.5 with remote repositories, but it had severe limitations. I currently have code that gets metadata (or generated it) for different target locations (remote repos, local installations, directories of plug-ins). The target then 'resolves' (uses the slicer to determine the complete set of IUs in the target. Then the target 'provisions' which uses the engine to collect, download and install the IUs into a profile. We then use the artifacts to create a State.


The problem I'm having is that when the engine runs the download phase, it always grabs every bundle and puts it in the bundle pool, even if the artifacts are available in a local repository. For example, when my target contains the metadata from a local profile (another Eclipse installation), the engine copied the entire SDK into the profile's bundle cache. Hopefully there is some way to workaround this as I don't think people will appreciate getting that much data copied on their system. I also can't skip the download phase because some of the target may be from a remote repository.


Also, is there some code out there that can take a profile and a set of artifact repositories and get the uris of the artifacts in the profile? Our current code works with a single artifact repository and looks in that repo for each IArtifactKey.


On another note, I would like to say how satisfied I am working with the multiple agent API. It's simple, straightforward, documented well and very powerful for the PDE use cases.


Thanks!


Curtis
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/p2-dev

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev