[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [epp-dev] Galileo Build Status
|
This is like a dream come true! Thx!
I believe that the problem you are encountering is that the tweaking you use to do was directly done by bashing some files in the org.eclipse.platform plug-in (see 241596). p2 renders that impossible because it enforces content immutability by verifying the signature and/or MD5 hashing.
Instead you now need to have each package have a "customization" plug-in that will deliver the values needed. This plug-in needs to be referred to from your product.
Note that I don't know what is happening when several plug-ins are providing a "customization" plug-ins. It may be that for this to work successfully some tweaking of the platform feature will be required (e.g. taking the org.eclipse.platform out of the feature into the SDK product), so please don't hesitate to tell us by bug to platform / releng.
Thx
PaScaL
Markus Knauer ---03/12/2009 07:09:52 AM---Hi *, a 'brief' overview of the current build status of the EPP packages for the
![]()
From: | ![]()
Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx> |
![]()
To: | ![]()
EPP Developer Mailing List <epp-dev@xxxxxxxxxxx> |
![]()
Date: | ![]()
03/12/2009 07:09 AM |
![]()
Subject: | ![]()
[epp-dev] Galileo Build Status |
Hi *,
a 'brief' overview of the current build status of the EPP packages for the next Galileo release:
(1) I am using the p2 director to build the packages. No ant scripts, no PDE build, no PDE packager, just the plain p2 director application. I am convinced that this is the best way to build packages these days and my experiences (apart from some minor exceptions) are really good!
(2) All packages are building, except one x86_64 architecture problem that needs to be fixed upstream in the Galileo repo, but this is just a question of 'doing', not a serious problem. Some of the package may contain too much - I'll see what dependencies are causing this and will update you on this.
(3) Currently the build output is based on the Galileo staging repo and can be found here: http://build.eclipse.org/technology/epp/epp_build/35/download/ - YES, this is a raw directory listing, but I am sure you will find the packages. I will change this into something smoother as soon as possible and will try to integrate it into the Hudson build.
(4) All packages are building, but... okay, while the package quality with the p2 based approach should be higher, there is one known regression compared to the old Ganymede packages: They are all starting with the Resource Perspective and with the standard JVM settings. I need to figure out how to solve this in a p2-compatible and easy way. Comments and ideas are welcome!
(5) p2 makes EPP really simple. And that's what I like it to be. EPP creates another metadata repository and uses this together with the Galileo repo and the Eclipse Platform repo to build a package. Everyone can do that on his/her own computer. But what happens to those ominous EPP configuration files that were used in the past by the package maintainers? I'd like to get rid of them but those files are consumed by the Eclipse website which generates websites from them. My idea is that a package maintainer states in a bug report which installable units should go into the package and we (EPP) are looking for a way to create the necessary information for the website. It depends on the webmasters if we (EPP) recreate such old xml config files or if we can find another easier way to create the web pages.
Comments? I will try to document it in the wiki during the next few days.
Regards,
Markus_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
![GIF image](gif7wcha3pHJI.gif)
![GIF image](gifg81Ci435u7.gif)