Hi Phillippe,
Thanks for the input.
After further consideration (and some more sleep) I think that
requiring 1.5 as soon as November would be a mistake. I know I
suggested end of November in an earlier posting, but I'm now thinking
it would be better to stay with requiring only 1.4 JRE for at least
another 6 months in order to keep EE options as open as possible...at
least into 2007. I think that staying with 1.4 for at least 6 months
will help keep the barriers to entry low, and ease ECF adoption during
a transition out of incubation.
I would like to use generics and other 1.5 features in ECF provider
implementations, but admittedly this is more programming convenience
than requirement. If a given provider requires 1.5 then so be it, but
I don't want to require 1.5 in the core and API plugins (e.g. presence,
datashare, fileshare/filetransfer, discovery, etc).
Thoughts about collab plugin in response to Erkki's
posting...forthcoming.
Scott
Philippe Ombredanne wrote:
Remy:
But, just what EE should the core ECF stand at? If you think we should
stick to 1.4 "for now", just how long is "for now" though?
+1 for using ME as EE, if possible. Beyond the fact that a framework
should impose as minimal depdencies as possible, and the fact that 1.5
is NOT linux distro friendly, it would also make general use of ECF
easier, including possible use for things like provisioning in the
platform.
ME being for sure a better option than 1.4.
Or more precisely to match the Eclipse platform core plugins:
Bundle-RequiredExecutionEnvironment: CDC-1.0/Foundation-1.0,J2SE-1.3
Now that's always a bummer when you code not to have the laest
goodies...
Yet, imho the benefits of wider portability far outweights missing bits
of the latest goodies.
Which point to one important thing: the EE SHOULD always be specified in
the manifest.
That's the case for ECF, yet not the case for the Jxta implementation @
OSUOSL.
And that's valid regardless of the the EE chosen of course.
+1 for refactoring the collab plugin and exposing as an examplary
implementation rather than an example.
The same way the JDT is an examplary -- not an example-- implementation.
Just my +2 cents :-)
|
