Re: [epp-dev] Galileo Build Status

[Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>]

Yes.  Essentially all the features, command line args and other settings can be captured in a .product file. The package maintainer defines this and supplies it to the EPP build. The EPP build then publishes this using the p2 publisher.  The result is an IU in the relevant repo that can then be used to "install" using the director as Markus describes.  The rest of the information (website, ...) can stay the same.

For the list of features (whatever) in the package it depends on whether this intended to be a flat and complete list or a subset of the features (e.g., just the root that users would normally see say in the repo categories). For example, if it is the direct children of the .product file then its easy.  If there is a deeper relationship I'm pretty sure that we could put something together to gather the required/desired info but would need to know more about what that info is.

Jeff

Ian Skerrett wrote:

It seems like the following might work.   The package maintainer continues
to maintain the package configuration files that were specified for
Ganymede.  This will allow us to get the web site data that we need to build
the download page.  However we remove the feature listing from this file and
use the .product file, which Jeff is suggesting, to define the package
contents.

Ian


-----Original Message-----
From: epp-dev-bounces@xxxxxxxxxxx [mailto:epp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Jeff McAffer
Sent: Thursday, March 12, 2009 8:45 AM
To: Eclipse Packaging Project
Subject: Re: [epp-dev] Galileo Build Status

Awesome.  I'm very pleased to see this evolution.  some comments/suggestions

Markus Knauer wrote:
  

Hi *,

(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!
    

This likely related to the "product" that is being installed. Each 
package should be a product with its own settings etc.  These typically 
can be copies of the base one with more features and different 
config/laucher args.  In the new product files you should be able to 
describe pretty much everything with no need for config.inis etc.
  

(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.
    

Consider having package maintainers develop and contribute .product 
files.  The EPP team would vet these for consistency in the arguments 
etc and then simply deploy them as you have described. To generate the 
website data, whatever it is, we can put something together that looks 
at the metadata and extracts the info.  If that info is not directly 
extractable then perhaps the website info is more of a description and 
just needs to be hand crafted?
  

Comments? I will try to document it in the wiki during the next few days.
    

Jeff
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev

_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
  

-- 
Jeff McAffer | CTO | EclipseSource | +1 613 851 4644
jeff@xxxxxxxxxxxxxxxxx | http://eclipsesource.com