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

["Shawn O. Pearce" <spearce@xxxxxxxxxxx>]

Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:
> On Dec 9, 2009, at 15:27, Chris Aniszczyk wrote:
>> - Message Bundles. Projects must use Eclipse message bundles unless
>> there are technical reasons not to.
>> We need to work on this.
>
> JGit needs to be able to depend on non-JGit stuff. So we probably need  
> to have the translation/I18N layer done in EGit, and use specific  
> exception classes to be able to realise/translate into an appropriate  
> format for Eclipse's purposes. That's a legal, rather than technical,  
> reason.

I'd actually prefer to just write our own micro NLS class in JGit.
Seriously.  Its got to be like 50 lines of code: Scan the public
static fields, loaded a standard ResourceBundle through java.util
API and inject it via reflection.

Someone please code this and contribute it.  It should be an
easy one evening project.  We don't need massive cability here for
localization, most of JGit message formatting is about error messges.
Standard MessageFormat and some strings loaded from a localized
ResourceBundle should be Good Enough.

>> - 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 :)
>
> Well ... we've already gone past Java5 EOSL;

Despite that, we still target Java 5.

> the only thing I can think 
> of is that neither PPC or Intel Mac OS X 32-bit doesn't have Java6 (so 
> any 32-bit Macbooks or minis are going to be wiped out by that 
> requirement. Are we happy to do that? My (64-bit) PPC mac has Java 6 
> installed, but for some reason, only for the x86_64 architecture, so I 
> can't even run it there. So my personal preference would be for a Java 5 
> minimum.

I agree.  That has always been the target for both JGit and EGit,
and I have no interest in changing that anytime soon.

>> - Re-use and share common third party jars.
>> We need to make sure we do this.
>
> Not sure EGit has any dependencies other than JGit, which itself is  
> independent of others (provided that we don't introduce the args4j or  
> other type dependencies).

Our depedency chain is:

  EGit -> JGit -> JSch
   |
   \
    +-> other Eclipse APIs (JFace, SWT, Resources, ....)

We will soon have JGit depend on javax.servlet due to the HTTP server
code, but this will be an optional additional plugin.  Unless your
IDE also has an HTTP server like Jetty there is no good reason to
include that plugin in our core EGit feature.

-- 
Shawn.