Re[2]: Using OSG for Classpath

[Peter Kriens]

TT> I've seen the OSGi idea come up before, in particular on the Harmony
TT> list.  I still don't understand what concrete benefit it provides.
TT> Could you describe that?
The OSGi gives you modularization. Instead of one big chunk, you get
many smaller chunks with well defined dependencies. This is usually
considered a good thing. Not only for your customers, who can use just
what they need, but also easier development. You would also allow
others to develop part of the solution. For example, Eclipse uses this
model to allow thousands of developers to play together without having
integration hotspots. Additionally, the OSGi provides "private"
packages, which is an extra level of protection and helps future
change. And last but not least, small is beautiful!

I agree that the building of the JAR files should not require manual
work. I have a utility that can create the manifest headers from the
class files. I could try to build a number of JARs this way as an
example, if you're interested. I guess I need this anyway for my SLUG
project :-)

Kind regards,

     Peter Kriens






>>>>>> "Peter" == Peter Kriens <address@hidden> writes:

Peter>> 1/ Could classpath be split up in multiple, independent projects? I.e.
Peter>>    every javax should have its own JAR.

Peter>> 2/ Could you use the OSGi modularization headers for JAR files to
Peter>>    make these libraries deployable? These headers allow you to keep
Peter>>    implementation code protected from other JARs when running on an
Peter>>    OSGi system. These headers are ignored for other systems.
Peter>>    FYI, OSGi is used in Eclipse, Apache and in many commercial
Peter>>    projects. I would be more than willing to help to get these headers
Peter>>    in place.

Peter>> 3/ Cross dependencies should be absolutely minimized. I noticed
Peter>>    java.nio was used in several implementation packages.

TT> The idea of building subsets of Classpath has come up a number of
TT> times.  I think the fundamental problem is not that anybody is opposed
TT> to it in theory, but more that nobody has really taken the time to
TT> implement a workable solution.  Informally I would say that it seems
TT> like most current Classpath developers are interested in getting all
TT> of J2SE working and aren't, typically, super concerned about embedded
TT> applications.

TT> I think a workable solution has to consider not only deployment, but
TT> also development.  Any approach that can't be automated and, say,
TT> can't work directly in Eclipse, is probably not going to work out that
TT> well.  (E.g., look at the current class-dependencies.conf files, which
TT> afaics are hand generated and unmaintained.  This kind of thing
TT> doesn't scale...)

TT> I've seen the OSGi idea come up before, in particular on the Harmony
TT> list.  I still don't understand what concrete benefit it provides.
TT> Could you describe that?

TT> Tom


-- 
Peter Kriens                              Tel +33870447986
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599