Home » Archived » EPP » Pascal: Packager doesn't honor order given in maps
| Pascal: Packager doesn't honor order given in maps [message #3821] |
Fri, 16 February 2007 09:33  |
Eclipse User |
|
|
|
Originally posted by: ureupke.innoopract.com
Pascal,
as I wrote elsewhere, I am assisting Markus with the packaging component.
Thanks for suggesting the PDE Packager as a basis for EPP.
The tool performs most of the required tasks as required by this
project, but just now, I have come across a problem I believe I cannot
solve by pre- or post-processing.
I am assembling the packages from three components - the Eclipse RCP
drops provided on the downloads page as "root" files, the requested
features downloaded from an update site, and a user-specified config.ini.
A custom config.ini is required, since the RCP drops come unconfigured.
To this end, I am creating a map file referencing the root files, a .zip
of the downloaded features, and another zip containing nothing but the
configuration file.
Packager then should take those files and work its magic, but alas, it
succeeds only in part. The FetchFileGenerator reads the contents of the
map file to a Properties object, which is essentially a HashMap, and
thus the order of iteration is not the order of insertion - which leads
to some root-file-archives being extracted after the config.ini-archive,
thus overwriting the custom file.
Could you advise me as to whether there is a more appropriate approach
to the custom config problem or whether we could change the packager so
that it honored the order given in the map file?
Thanks a lot
-Urs
|
|
|
| Re: Pascal: Packager doesn't honor order given in maps [message #3828 is a reply to message #3821] |
Fri, 16 February 2007 14:46  |
 Pascal Rapicault
Messages: 333
Registered: July 2009
Location: Ottawa |
Senior Member |
|
|
Hi Urs,
This can be solved by setting the following properties in the
packaging.properties file
unzipOrder=<prefixToZipFileToUnzipFirst>,
<prefixToZipFileToUnzipSecond>, ...
Please also post these questions on pde-build-dev as I only check the
newsgroup once a day
PaScaL
"Urs Reupke" <ureupke@innoopract.com> wrote in message
news:er3tph$sus$1@utils.eclipse.org...
> Pascal,
>
> as I wrote elsewhere, I am assisting Markus with the packaging component.
>
> Thanks for suggesting the PDE Packager as a basis for EPP.
> The tool performs most of the required tasks as required by this project,
> but just now, I have come across a problem I believe I cannot solve by
> pre- or post-processing.
>
> I am assembling the packages from three components - the Eclipse RCP drops
> provided on the downloads page as "root" files, the requested features
> downloaded from an update site, and a user-specified config.ini.
> A custom config.ini is required, since the RCP drops come unconfigured.
> To this end, I am creating a map file referencing the root files, a .zip
> of the downloaded features, and another zip containing nothing but the
> configuration file.
> Packager then should take those files and work its magic, but alas, it
> succeeds only in part. The FetchFileGenerator reads the contents of the
> map file to a Properties object, which is essentially a HashMap, and thus
> the order of iteration is not the order of insertion - which leads to some
> root-file-archives being extracted after the config.ini-archive, thus
> overwriting the custom file.
>
> Could you advise me as to whether there is a more appropriate approach to
> the custom config problem or whether we could change the packager so that
> it honored the order given in the map file?
>
> Thanks a lot
> -Urs
|
|
|
| Re: Pascal: Packager doesn't honor order given in maps [message #3841 is a reply to message #3828] |
Mon, 19 February 2007 08:01 |
| Eclipse User |
|
|
|
Originally posted by: ureupke.innoopract.com
Pascal Rapicault wrote:
> This can be solved by setting the following properties in the
> packaging.properties file
> unzipOrder=<prefixToZipFileToUnzipFirst>,
> <prefixToZipFileToUnzipSecond>, ...
Thanks a lot, problem solved.
Is this information documented somewhere outside the source code?
-Urs
|
|
| |
| Re: Pascal: Packager doesn't honor order given in maps [message #573512 is a reply to message #3821] |
Fri, 16 February 2007 14:46 |
Pascal Rapicault
Messages: 440
Registered: July 2009 |
Senior Member |
|
|
Hi Urs,
This can be solved by setting the following properties in the
packaging.properties file
unzipOrder=<prefixToZipFileToUnzipFirst>,
<prefixToZipFileToUnzipSecond>, ...
Please also post these questions on pde-build-dev as I only check the
newsgroup once a day
PaScaL
"Urs Reupke" <ureupke@innoopract.com> wrote in message
news:er3tph$sus$1@utils.eclipse.org...
> Pascal,
>
> as I wrote elsewhere, I am assisting Markus with the packaging component.
>
> Thanks for suggesting the PDE Packager as a basis for EPP.
> The tool performs most of the required tasks as required by this project,
> but just now, I have come across a problem I believe I cannot solve by
> pre- or post-processing.
>
> I am assembling the packages from three components - the Eclipse RCP drops
> provided on the downloads page as "root" files, the requested features
> downloaded from an update site, and a user-specified config.ini.
> A custom config.ini is required, since the RCP drops come unconfigured.
> To this end, I am creating a map file referencing the root files, a .zip
> of the downloaded features, and another zip containing nothing but the
> configuration file.
> Packager then should take those files and work its magic, but alas, it
> succeeds only in part. The FetchFileGenerator reads the contents of the
> map file to a Properties object, which is essentially a HashMap, and thus
> the order of iteration is not the order of insertion - which leads to some
> root-file-archives being extracted after the config.ini-archive, thus
> overwriting the custom file.
>
> Could you advise me as to whether there is a more appropriate approach to
> the custom config problem or whether we could change the packager so that
> it honored the order given in the map file?
>
> Thanks a lot
> -Urs
|
|
| | |
Goto Forum:
Current Time: Thu Apr 25 00:52:22 GMT 2024
Powered by FUDForum. Page generated in 0.03354 seconds |
] 
Search
Help
Register
Login
Home
