Re: [egit-dev] Participation in Helios build?

[Chris Aniszczyk <zx@xxxxxxxxxxxxxxxxx>]

On Wed, Dec 9, 2009 at 8:47 AM, Sohn, Matthias <matthias.sohn@xxxxxxx> wrote:
> Chris Aniszczyk <caniszczyk@xxxxxxxxx> wrote:
>> Once we have a build going, we can add ourselves to the Helios build.
>
> For that we need maven 3.0-alpha-5 or newer installed on Hudson to get
> the Tycho build running there, do you know if that's already available ?
>
> Anything else you see missing here ?

As long as we do signing, I think we will be OK. There is also some
things around us including "incubation" in the bundle / feature names.

>> There's also quite a bit of groundwork for us to do to become part of
>> the train in terms of signing and localization (and other things).
>
> Could you provide some pointers on what's ahead here ?

Yes, here is a brief summary of what needs to be done. Let me try to
separate things out to what I think we have already and what we don't.

STUFF WE NEED TO DO

- Message Bundles. Projects must use Eclipse message bundles unless
there are technical reasons not to.
We need to work on this.

- Execution Environment.
We should make make sure that we have a
Bundle-RequiredExecutionEnvironment (BREE) set for our bundles. Now
that I think about... what version of Java are we targetting? This
should be reflected in the BREE. We should also use PDE API Tools'
execution environment validation to make sure we don't call any Java
6.0 methods if we are targetting Java 5.0 :)

Signing. Projects must use signed plugins using the Eclipse certificate.
- We need to make sure that we do this as part of our build.

Optimization. Projects must optimize their p2 repositories to reduce
bandwidth utilization and provide a better install and update
experience for users.
- We should ensure that we could run pack200 against our build... not
sure if Tycho supports this out of the box.

STUFF WE ALREADY DO

- Communication: Build team members (or their designated alternates)
from each project may be asked to provide direct communication
channels: phone, mail, IM, IRC and at least one build team member must
be "on call" during the milestone integration periods.
We do some of this. I sent an email about this earlier this year. I'm
not sure how to improve on this given people's attitudes.

- API. Projects should leverage only published APIs of dependencies.
We do this already from what I've seen. We just should be careful
about what we declare API and mark other things as x-internal.

- Version Numbering. Projects must use 4-part version numbers.
We do this already.

- OSGi bundle format. All plug-ins (bundles) must use the true bundle form.
We already do this :)

- Jarred Bundles. Projects must use jarred plug-ins (with
unpack=false) unless authorized by the planning council for technical
exceptions.
We already do this.

- Re-use and share common third party jars.
We need to make sure we do this.

- Provide p2 repository.
We will do this as part of our build.

- Branding. Each major project (as determined by participating PMCs)
must have an 'About' dialog icon with hover text that displays the
provider name.
We do this already

- Do No Harm. Projects must work together in any combination of any install
We should meet this requirement already :)

License text consistency. Use standard forms of license documents so
it is displayed in the most usable
- We should meet this already :)

We should open bugs for things that we don't have.

Cheers,

-- 
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource | http://twitter.com/caniszczyk