[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Helios Features Mirror

Great, will give it a go, thanks!

On Mon, Apr 18, 2011 at 5:03 PM, Pascal Rapicault <pascal@xxxxxxxxxxxx> wrote:
> IIRC this should be in last week I-build: http://download.eclipse.org/eclipse
>
> If in the end you want one repo that contains everything, you can simply run the operation several times using the same destination repository. In this case the mirroring task will just append to the repo what is missing.
>
> On 2011-04-18, at 3:15 PM, David Erickson wrote:
>
>> Thanks gentlemen, sorry for the delayed reply these look like great options.
>>
>> Pascal:
>> -Where can I grab your released build supporting the new code?
>> -Is it possible to run your solution to create a repository for each
>> platform, then aggregate them into one repository?
>>
>> Thomas:
>> -Is it possible to use the aggregator to slice out just one feature
>> and all transitively required bundles?
>>
>> Thanks!
>> David
>>
>> On Mon, Apr 11, 2011 at 3:59 AM, Thomas Hallgren <thomas@xxxxxxx> wrote:
>>> Hi David,
>>>
>>> An alternative for you might be to use the b3 aggregator [1]. That is the
>>> tool that was used when creating the Helios and Indigo aggregations and it
>>> can be used for this type of use-case as well. It can be downloaded from our
>>> update site [2] and executed either as a freestanding headless product, or
>>> within your IDE complete with graphical editor.
>>>
>>> Since the aggregator performs a validation prior to mirroring there are two
>>> "flaws" in Helios that must be catered for. One is explained here:
>>>
>>>  https://bugs.eclipse.org/bugs/show_bug.cgi?id=342350
>>>
>>> and the other is that the feature org.eclipse.jwt.feature was renamed to
>>> org.eclipse.jwt.feature in a service pack release which in turn leads to
>>> conflicts since both are included when trying to resolve a "canonical"
>>> repository.
>>>
>>> This b3.aggr file will successfully create a validated, "as small as
>>> possible" mirror of Helios for three common environments (win32.win32.x86,
>>> linux.gtk.x86, linux.gtk.x86_64). You can add other environments using the
>>> editor.
>>>
>>> <?xml version="1.0" encoding="ASCII"?>
>>> <aggregator:Aggregator xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI";
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>> xmlns:aggregator="http://www.eclipse.org/b3/2010/aggregator/1.0.0";
>>> description="Used to test stuff that causes errors when added to the main
>>> repo model." label="Test Repo" buildRoot="build-test"
>>> packedStrategy="VERIFY">
>>>   <configurations/>
>>>   <configurations operatingSystem="linux" windowSystem="gtk"/>
>>>   <configurations operatingSystem="linux" windowSystem="gtk"
>>> architecture="x86_64"/>
>>>   <contributions label="Platform Repo">
>>>     <repositories location="http://download.eclipse.org/releases/helios/";>
>>>       <mapRules xsi:type="aggregator:ValidConfigurationsRule"
>>> description="Cater for bad filtering in the epp.package.linuxtools
>>> requirement for org.eclipse.epp.package.linuxtools.feature.feature.group"
>>> name="epp.package.linuxtools" validConfigurations="//@configurations.1
>>> //@configurations.2"/>
>>>       <mapRules xsi:type="aggregator:ExclusionRule" description="Exclude
>>> feature that has been renamed and hence causes conflicts."
>>> name="org.eclipse.jwt.feature.group" versionRange="[0.7.0,0.8.0)"/>
>>>     </repositories>
>>>   </contributions>
>>> </aggregator:Aggregator>
>>>
>>> [1] http://wiki.eclipse.org/Eclipse_b3/aggregator/manual
>>> [2]
>>> https://hudson.eclipse.org/hudson/job/emft-b3-build/lastSuccessfulBuild/artifact/b3.p2.repository/
>>>
>>> Regards,
>>> Thomas Hallgren
>>>
>>>
>>> On 2011-04-11 06:10, Pascal Rapicault wrote:
>>>
>>> Since there was no satisfying solution, I've just released code to the
>>> mirroring app that will perform the same resolution than the one performed
>>> at install time. This will be available in the next I build (Tuesday
>>> morning)
>>> This can be enabled by setting resolve="true" (see example below).
>>> Only one platform filter can be supported at a time (or none).
>>>
>>> <project name="Helios Mirror" default="mirror" basedir=".">
>>> <target name="mirror">
>>> <p2.mirror source="http://download.eclipse.org/releases/helios/";
>>> destination="${basedir}" verbose="true">
>>> <iu id="org.eclipse.equinox.sdk.feature.group"
>>> version="3.6.0.v20100601-7H7R-7v8rtGVR34XkO3kfH3DUO07" />
>>> <slicingOptions resolve="true" platformFilter="win32,win32,x86"/>
>>> </p2.mirror>
>>> </target>
>>> </project>
>>>
>>> On 2011-04-08, at 5:53 PM, David Erickson wrote:
>>>
>>> Hi all-
>>> I am trying to make the smallest mirror size as possible of two
>>> features from Helios.  I am using the following ant-task:
>>>
>>> <project name="Helios Mirror" default="mirror" basedir=".">
>>>  <target name="mirror">
>>>    <p2.mirror source="http://download.eclipse.org/releases/helios/";
>>> destination="${basedir}" verbose="true">
>>>       <iu id="org.eclipse.equinox.sdk.feature.group"
>>> version="3.6.0.v20100601-7H7R-7v8rtGVR34XkO3kfH3DUO07" />
>>>       <iu id="org.eclipse.pde.junit.runtime.standalone.feature.group"
>>> version="1.0.0.v20100610" />
>>>       <slicingOptions followStrict="true" includeOptional="false"
>>> includeNonGreedy="false"/>
>>>    </p2.mirror>
>>>  </target>
>>> </project>
>>>
>>> and the following target file:
>>>
>>> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
>>> <?pde version="3.6"?>
>>>
>>> <target name="Main Target">
>>> <locations>
>>> <location path="${resource_loc:/Libraries}" type="Profile"/>
>>> <location includeAllPlatforms="false" includeMode="planner"
>>> type="InstallableUnit">
>>> <unit id="org.eclipse.equinox.sdk.feature.group"
>>> version="3.6.0.v20100601-7H7R-7v8rtGVR34XkO3kfH3DUO07"/>
>>> <unit id="org.eclipse.pde.junit.runtime.standalone.feature.group"
>>> version="1.0.0.v20100610"/>
>>> <repository location="file:/path/to/libs_helios/"/>
>>> </location>
>>> </locations>
>>> </target>
>>>
>>> The result is a nice small sized mirror at ~31MB, however when I load
>>> the target in Eclipse that points to this folder and the two specified
>>> features I get resolution errors on needed packages that don't have an
>>> explicit version requirement listed, many of which are in javax.*. (To
>>> make this even more bizarre I've actually had it resolve happily once
>>> or twice then on all followups it fails to resolve).
>>>
>>> Now I can solve the resolution problem by changing followStrict to
>>> false, however then I end up with a mirror folder that is ~90MB,
>>> containing many duplicates of the same bundles but with separate
>>> versions, ie the folder has 3 commons logging bundles, 3 JFace
>>> libraries at 1MB a piece, 3 org.eclipse.ui.ide bundles, etc etc.
>>>
>>> How can I bridge the gap here by getting just the features I need
>>> using the requested versions and the small mirror size, but also have
>>> all the bundles I need so I don't get resolution errors?
>>>
>>> Thanks!
>>> David
>>> _______________________________________________
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>