[news.eclipse.technology.ecp] Re: What's the project status?

[Igor Shabalov <ishabalov@xxxxxxxxxx>]

De-facto current operational requirements are at least Java 5 and 
Eclipse 3.2. I think Alex or Nick can add more details there.

Let talk road map in separate discussion.


For JSR-291, I think we better follow Equinox position in that subject, 
and, frankly, I cannot speculate what it will be. Anyway, all this 
relationship between Java (Sun), Eclipse (IBM?) and OSGi are big unknown 
for me. Do anybody have strong opinion toward JSR-291?

Best,
Igor.


Wendell Beckwith wrote:
> This is a discussion I was hoping to have, however I wanted the final 
> proposal to see if things were different before opening a new can of 
> worms.  Nonetheless, the minimum operational environment for the ecp 
> needs to be specified.  Is it java 1.4 or java 5?  I saw the email that 
> Exadel had added more components.  Perhaps those additions (I admit I 
> haven't looked at them) are orthogonal and won't be affected by changing 
> the core framework except maybe at the activator and/or bundle listeners.
> But if that is not the case then we would be well served to focus on 
> specifying and then modifying/writing the core framework for java 1.4 or 
> 5.  Personally I'm all for java 5 because I like most of the features in 
> it, but general generic exposure to end users simply isn't one of them.
>
> Another issue is on road maps for milestones and releases.  I don't feel 
> we need to wait for project creation review to specify what we think 
> would be good additions for the ecp.
>
> And my final issue is JSR-291 and what that means for the ecp and well 
> as the equinox projects.  I believe our focus should be to follow this 
> spec. as it works its way through the JCP.  Key things that will affect 
> us is whether equinox will adopt it or do they plan to remain a 
> relatively "pure" OSGi implementation.
>
> Igor, Alex thoughts?
>
> Wb
>
>
> Jeff McAffer wrote:
>
> > Yes!  Actually, we avoid anything in Java 5 unless absolutely 
> > required.  The
> > problem is that it reduces the number of places that people can use the
> > plugins.  So unless the gain is significant, the loss is not outweighed.
> >
> > Jeff
> >
> > "Wendell Beckwith" <wbeckwith@xxxxxxxxx> wrote in message
> > news:e2lip9$kev$1@xxxxxxxxxxxxxxxxxxxx
> >  
> >
> > > Early last week and today I got time to dig into the core plugin and in
> > > an effort to understand what you all had done I started a new plugin and
> > > started rewriting it.  There are serveral inconsistencies where some
> > > interfaces begun with an 'I' and some didn't among other things.  And
> > > from having reimplemented nearly half the core plugin I truly question
> > > the utility of using generics in the core.  If you review the pdfs @
> > > http://www.oreillynet.com/pub/wlg/7202, you can see the almost utility
> > > of generics.  Our current code is java 5 so we use java 5 features, but
> > > generics really complicates the code more than it solves.  For my team
> > > the rule is that generics can be used in our own code internally but no
> > > generics are allowed in API classes that end users would see.
> > >
> > > Wb
> > >
> > >