| bundles expanding upon materialization [message #385378] |
Mon, 18 May 2009 07:29  |
Eclipse User |
|
|
|
Hi
How do I tell the 'eclipse.import' reader or the 'filesystem' materializer
reader to NOT unpack/unjar the downloaded bundles. E.g. bundles downloaded
via the 'url' or 'maven' readers (some materializer) are not expanded.
Thanks & Regards
Alex
|
|
|
|
|
|
|
|
|
|
| Re: bundles expanding upon materialization [message #385480 is a reply to message #385479] |
Wed, 20 May 2009 02:18  |
| Eclipse User |
|
|
|
Alex Chatziparaskewas wrote:
> Hi Thomas
>
> Ok, now I understand. So let me slightly rephrase my questions then:
> What is then the proposed way of materializing a binary plugin for a
> target platform from a download site like
> http://download.eclipse.org/eclipse/updates/3.4? Would I need to convert
> all 'eclipse.import' reader usages to 'url' readers?
>
No, you keep the 'eclipse.import' but you use an MSPEC to declare that some components should end up in your target
platform rather then in the workspace.
Alternatively, if your target platform is fairly static and you don't want to set it up for each build, you can create
such a platform once and for all in your IDE and then appoint it from Buckminster using the command "setpref
targetPlatformPath=/path/to/your/TP"
Regards,
Thomas Hallgren
> Thanks & Regards
> Alex
>
>
>
> Thomas Hallgren wrote:
>
>> I think we talk about different things when we say 'expand'. The
> org.apache.commons.logging jar file is not expanded.
>> When the bundle is 'imported' a project is created that contains the jar
> file of the bundle. That project is named after
>> the component ID. That results in a collision when you import several
> versions.
>
>> There is a current limitation in Buckminster that will prevent you from
> importing several bundles with the same name
>> since the mspec node selection is based to name and component type
>> only. In
> order to fix this you would either need to
>> differentiate on version or include the version in a
> bindingPatternReplacement. Neither is possible right now I'm afraid.
>
>> A solution to your problem could be to define a target platform that
> contains the bundles instead of importing them into
>> your workspace.
>
>> - thomas
>
>
>
>> Alex Chatziparaskewas wrote:
>>> It is simply org.apache.commons.logging from the ORBIT website
>>> ( http://download.eclipse.org/tools/orbit/downloads/drops/I200 90504052954/)
>>>
>>>
>>> searchPath looks like this (3rd provider is for ORBIT):
>>>
>>> <searchPath name="3rd.party">
>>> <provider readerType="local"
>>> componentTypes="osgi.bundle,eclipse.feature,buckminster"
>>> mutable="true" source="true">
>>> <uri format="file:///Q:/target-platforms/components/{0}">
>>> <bc:propertyRef key="buckminster.component" />
>>> </uri>
>>> </provider>
>>> <provider readerType="local"
>>> componentTypes="osgi.bundle,eclipse.feature,buckminster"
>>> mutable="true" source="true">
>>> <uri format="file:///${CC_LIBS_HOME}/3rd-party2/{0}_{1}">
>>> <bc:propertyRef key="buckminster.component" />
>>> <bc:replace pattern=".*([0-9]+.[0-9]+.[0-9]+).*"
>>> replacement="$1">
>>> <bc:propertyRef
>>> key="buckminster.version.designator" />
>>> </bc:replace>
>>> </uri>
>>> </provider>
>>> <provider readerType="eclipse.import"
>>> componentTypes="osgi.bundle" mutable="false" source="false">
>>> <uri
> format=" http://download.eclipse.org/tools/orbit/downloads/drops/I200 90504052954/updateSite"/>
>
>>>
>>> </provider>
>>> <provider xsi:type="mp:MavenProvider" readerType="maven2"
>>> componentTypes="maven,osgi.bundle" mutable="false" source="false">
>>> <uri format="http://repo1.maven.org/maven2"/>
>>> <mp:mappings>
>>> <mp:entry name="jcl.over.slf4j" groupId="org.slf4j"
>>> artifactId="jcl-over-slf4j"/>
>>> <mp:entry name="jul.to.slf4j" groupId="org.slf4j"
>>> artifactId="jul-to-slf4j"/>
>>> <mp:entry name="org.apache.activemq.core"
>>> groupId="org.apache.activemq" artifactId="activemq-core"/>
>>> <mp:entry name="slf4j.api" groupId="org.slf4j"
>>> artifactId="slf4j-api"/>
>>> <mp:entry name="slf4j.log4j12" groupId="org.slf4j"
>>> artifactId="slf4j-log4j12"/>
>>> </mp:mappings>
>>> </provider>
>>> </searchPath>
>>>
>>>
>>>
>>>
>>> Thomas Hallgren wrote:
>>>
>>>> That sounds very odd. What is the name of the unexpanded jar file?
>>>> And why
>>> is org.apache.commons.logging expanded? It
>>>> shouldn't need to be since it doesn't contain nested jars and such.
>>>
>>>> - thomas
>>>
>>>> Alex Chatziparaskewas wrote:
>>>>> Hi Thomas
>>>>>
>>>>> Actually I now ran into a problem with the eclipse.import reader
>>>>> expanding the bundles. The problem is that the version information
>>>>> is not retained as part of the expand process. I.e. I have a
>>>>> dependency for commons.logging versions 1.0.4 and 1.1.1. The
>>>>> commons.logging bundle is expanded into a directory
>>>>> org.apache.commons.logging and not something like
>>>>> 'org.apache.commons.logging_1.0.4/1.1.1'.
>>>>>
>>>>> Regards
>>>>> Alex
>>>>>
>>>>>
>>>>>
>>>>> Thomas Hallgren wrote:
>>>>>
>>>>>> Hi Alex,
>>>>>> The import reader will unpack bundles that needs to be unpacked in
>>>>>> order to
>>>>> function. There's
>>>>>> currently no way of turning that off. However, most bundles will
>>>>>> not need to
>>>>> be unpacked.
>>>>>
>>>>>> What problems do you see with this approach?
>>>>>
>>>>>> - thomas
>>>>>
>>>>>> Alex Chatziparaskewas wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> How do I tell the 'eclipse.import' reader or the 'filesystem'
>>>>>>> materializer reader to NOT unpack/unjar the downloaded bundles.
>>>>>>> E.g. bundles downloaded via the 'url' or 'maven' readers (some
>>>>>>> materializer) are not expanded.
>>>>>>>
>>>>>>> Thanks & Regards
>>>>>>> Alex
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.11627 seconds
Home