| Source plugins via url.zipped [message #549698] |
Tue, 27 July 2010 11:08  |
 Thorsten Meinl
Messages: 85
Registered: July 2009 |
Member |
|
|
Hi all,
I want to include a JRE in our RCP products. We currently support five
different platforms, so I created five features that specify the
corresponding JRE as rootfiles in their build.properties. However, I do not
want to add several hundreds of megabytes of binaries to our source code
repository. Therefore my idea was to put the five features an a web server
and fetch them via the url.zipped reader. However, this doesn't work as
expected.
If I put them as .zip files, Buckminster tries to find files such as
jre.x.y.z.zip/features/jre.x.y.z.jar
(the URI format in the reader is ".../{0}.zip" with {0} being a reference to
buckminster.component). If I rename them to .jar (and update the URI format
accordingly) Buckminster finds them but extracts all of them directly into
..buckminster/features (the feature name is lost somehow). What I want is the
url.zipped reader working similar to the svn reader in that it extracts the
zipped features and puts them into the workspace as if they were fetched via
svn. Setting the reader's source-property to true didn't help.
Is this possible somehow? Or is there a completely different best-practice
way of managing JREs? I don't want to rely on some fixed filesystem
location.
Best regards,
Thorsten
|
|
|
| Re: Source plugins via url.zipped [message #549772 is a reply to message #549698] |
Tue, 27 July 2010 18:06  |
 |
Thomas Hallgren
Messages: 3214
Registered: July 2009 |
Senior Member |
|
|
Hi Thorsten,
Try using the 'url' reader type instead of the 'url.zipped'. The latter assumes that you want to treat the zip as a
folder and will unpack it in order to find meta-data inside of it. That does not seem to be what you want. The component
type should be 'unknown'.
HTH,
- thomas
On 07/27/2010 05:08 PM, Thorsten Meinl wrote:
> Hi all,
>
> I want to include a JRE in our RCP products. We currently support five
> different platforms, so I created five features that specify the
> corresponding JRE as rootfiles in their build.properties. However, I do not
> want to add several hundreds of megabytes of binaries to our source code
> repository. Therefore my idea was to put the five features an a web server
> and fetch them via the url.zipped reader. However, this doesn't work as
> expected.
> If I put them as .zip files, Buckminster tries to find files such as
>
> jre.x.y.z.zip/features/jre.x.y.z.jar
>
> (the URI format in the reader is ".../{0}.zip" with {0} being a reference to
> buckminster.component). If I rename them to .jar (and update the URI format
> accordingly) Buckminster finds them but extracts all of them directly into
> ..buckminster/features (the feature name is lost somehow). What I want is the
> url.zipped reader working similar to the svn reader in that it extracts the
> zipped features and puts them into the workspace as if they were fetched via
> svn. Setting the reader's source-property to true didn't help.
> Is this possible somehow? Or is there a completely different best-practice
> way of managing JREs? I don't want to rely on some fixed filesystem
> location.
>
> Best regards,
>
> Thorsten
|
|
|
| Re: Source plugins via url.zipped [message #549895 is a reply to message #549772] |
Wed, 28 July 2010 07:38 |
Thorsten Meinl
Messages: 85
Registered: July 2009 |
Member |
|
|
Hi Thomas,
Thomas Hallgren wrote:
> Try using the 'url' reader type instead of the 'url.zipped'. The latter
> assumes that you want to treat the zip as a folder and will unpack it in
> order to find meta-data inside of it. That does not seem to be what you
> want. The component type should be 'unknown'.
That doesn't really solve my problems, since I want the features unpacked
but as source projects into the workspace (as if it were a checkout from
SVN). So their type is really eclipse.feature and not unknown. What I'm
thinking of is some kind of url.source.zipped reader that unpacks the found
ZIP.
For the time being I create a second SVN repos that only contains the four
features containing the JRE binaries. For now that works.
Cheers,
Thorsten
|
|
|
Powered by
FUDForum. Page generated in 0.03617 seconds
] 
Search
Help
Register
Login
Home
