Home » Eclipse Projects » Equinox » Equinox and the next Eclipse
| Equinox and the next Eclipse [message #23469] |
Thu, 24 April 2003 18:14  |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
As some of you will have read by now, there is some exciting news about the
next version of Eclipse. See the following link for some more information.
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/ecli pse-project-home
/plans/eclipse_after_2_1.html
To summarize, the next version of Eclipse will be 3.0 not 2.2.
Equinox was originally conceived in with the notion that we would do what we
could within the 2.2 timeframe and API constraints and the more "radical"
changes would go into a nebulous 3.0 Eclipse sometime after that.
This change is exciting and challenging for Equinox. The exciting part is
that more of the work here is more immediately relevant. The alternate
runtime work for example can have an impact right now. The dynamic plugins
work can be more aggressive in both breadth and depth of the problems
addressed.
The challenging part is that the timelines for the longer term work need to
be compressed. Work that requires significant/far-reaching API/model
changes (e.g., that which was previously slated for the nebulous 3.0
sometime late next year) now needs to be understood in the next few months
to allow for comment and adaptation. Conversely, some of the less radical
changes originally slated for 2.2 (i.e., end of this year) have a bit more
time.
This new model also means that more Eclipse developers will be
interested/participating in Equinox sooner. This is great news.
With this in mind, the broad brush schedule for the next 6 months looks
like:
May 30:
- Initial *prototype* for dynamic plugins: deactivation, enable, disable,
notification mechanism. Concrete line item plan for implementation.
- Complete investigation of directions for alternate runtime work. Commit
to one and produce line item plan for implementation.
June 30:
- Complete investigation of services models and commit. Produce line item
plan for implementation
- Complete investigation of roles/profiles. Begin work on prototype.
- Complete direction statement for security.
- Continuing work on dynamic plugins and alternate runtimes
July 30:
- Service model prototype
- Security prototype
- Continuing work on dynamic plugins and alternate runtimes
August 30:
- All implementations with basic function
- Work with early adopters for API acceptance (of course this will be going
on all along but around this time we should be exploring the remaining
fringes and ensuring completeness).
September 30:
- Commit to API for all changes (still room to move but big picture
solidified).
- Implementation good enough for non-laboratory use by early adopters
October 30:
- Work with early adopters to solidify API and commit to API across the
board
- Continue work on implementation
Summary: The intermediate dates are meant to project the intention.
Individual items may move but the overall intent will remain. Ultimately,
work items which have a significant or widespread impact must be API
complete and mostly functional by the end of October. This allows enough
time for upstream plugins to adapt and for us to react to bugs/issues.
Smaller or less traumatic changes can still be done after October but there
is a risk/reward factor that comes into play.
|
|
|
| OSGi questions.. [message #23512 is a reply to message #23469] |
Sat, 26 April 2003 00:13  |
| Eclipse User |
|
|
|
Ok, so I have some of my own. ;)
Is the way OSGi handles exporting 3rd party libraries the same as Eclipse?
Do you declare, via the manifest.mf file in the Bundle-Export (or whatever
its name is..) all libraries (.jar/.zip I presume are the only acceptable
formats?) that are allowed to be used by other bundles? If so, I am not
quite sure I understand how the whole version thing works. For example, if
there are two bundles that both export servlet.jar, how is it determined
which one is used? What if my bundle wants to use servlet.jar 2.0 and the
highest servlet.jar is 2.2? Do I have to specify a specific version? That is
assuming my bundle is old and was built around 2.0, for example.
Another thing, it appears all bundles are a single .jar file each. Java has
no built in mechanism to search within .jar files for embeded .jar/.zip
files. I am going to take a wild guess that because the spec indicates that
it can embed libraries in this manner, the ClassLoader must be implemented
in a manner that can scan a given bundles .jar file for embeded .jar files
and actually open them up to look for classes inside of them? I have tried
using the Class-Path portion of manifest.mf in my own .jar file to locate
/lib/xxx.jar that was embeded in the .jar file at that location. At runtime,
I always get the ClassNotFoundException. If I unjar the .jar file, then it
finds it, but while it is inside the .jar file only, it can not be found. IS
this in fact true? Or does Java actually open up .jar files, and open up
embeded .jar files? If not, then I have another question, how does this have
an effect on performance? I mean, if at runtime the JVM asks my bundles
loader to find a class, and it is inside of one of the say 8 .jar files I
embed in my bundle, won't that eat up some time looking for it? Not only
would the classloader have to open up the bundle .jar file, but then it
would have to look in the /lib path for any .jar/.zip files, open them up,
and scan every entry in there for the right class. I am assuming because the
files are on disk, this could eat away at performance, and that just begs to
ask, how well does OSGi scale in this situation? What if I have a complex
relationship of service dependencies that end up scanning several bundles
for various classes at one given method call in a given service. Won't this
hurt performance? Are there guidelines put in place that indicate few if any
embedding should be used? If someone could elaborate a bit I guess on how
this process works, how it effect performance and so forth, I'd appreciate
that.
Other than that, it appears OSGi basically has what we want to add to
Equinox. I also just read that apparently the next version of Eclipse will
be 3.0, and because of that, a lot more of what Equinox is going to do may
end up in Eclipse. So, is there any reason we would be working on a separate
branch from Eclipse? I am curious if it makes sense to build two separate
but what now appears to be very similar products because of the longer time
frame for the 3.0 release.
Thanks.
|
|
|
| Re: OSGi questions.. [message #23681 is a reply to message #23512] |
Sat, 26 April 2003 10:36 |
| Eclipse User |
|
|
|
I'm trying the Mozilla News viewer so please let me know if this
response isn't in the proper format.
I'm also not an OSGi expert but appreciate the opportunity to look up
the answers to your questions.
OSGi export/import is at a different level than Eclipse's require
clause. In OSGi the specification is in terms of packages rather than in
terms of plugins. E.g.,
Import-Package: javax.servlet;
specification-version="2.1"
Based on constraints, OSGi selects the package from one and only one of
the bundles which exports.
I'm not an expert on the versioning scheme but you are not required to
specify an exact verision. There's also a warning in the Spec that an
export is also an implicit import and it is possible that you could end
up using an older version than you export (e.g., export version 2.2 but
version 2.0 is selected by the Framework). OSGi follows the Java 2
Packaging Version Specification which requires upward version
compatibility (I remember reading that Eclipse does not require
compatible interfaces across major versions).
My reading of the OSGi spec is that the a bundle may not contain another
Jar file. I base this on Section 4.2 of the OSGi Version 3 Spec where it
says "A Bundle is a JAR file that:" and the wording "class files for the
Java programming language, as well as other data such as HTML files,
help files, icons, and so on".
I'm sure Jeff will have a clearer answer to your question regarding 3.0
but my take is that we're working on a Eclipse Technology Project and if
it is successful the good ideas (maybe actual code) are likely to be
incorporated into mainstream Eclipse.
Keith
Kevin wrote:
> Ok, so I have some of my own. ;)
>
> Is the way OSGi handles exporting 3rd party libraries the same as Eclipse?
> Do you declare, via the manifest.mf file in the Bundle-Export (or whatever
> its name is..) all libraries (.jar/.zip I presume are the only acceptable
> formats?) that are allowed to be used by other bundles? If so, I am not
> quite sure I understand how the whole version thing works. For example, if
> there are two bundles that both export servlet.jar, how is it determined
> which one is used? What if my bundle wants to use servlet.jar 2.0 and the
> highest servlet.jar is 2.2? Do I have to specify a specific version? That is
> assuming my bundle is old and was built around 2.0, for example.
>
> Another thing, it appears all bundles are a single .jar file each. Java has
> no built in mechanism to search within .jar files for embeded .jar/.zip
> files. I am going to take a wild guess that because the spec indicates that
> it can embed libraries in this manner, the ClassLoader must be implemented
> in a manner that can scan a given bundles .jar file for embeded .jar files
> and actually open them up to look for classes inside of them? I have tried
> using the Class-Path portion of manifest.mf in my own .jar file to locate
> /lib/xxx.jar that was embeded in the .jar file at that location. At runtime,
> I always get the ClassNotFoundException. If I unjar the .jar file, then it
> finds it, but while it is inside the .jar file only, it can not be found. IS
> this in fact true? Or does Java actually open up .jar files, and open up
> embeded .jar files? If not, then I have another question, how does this have
> an effect on performance? I mean, if at runtime the JVM asks my bundles
> loader to find a class, and it is inside of one of the say 8 .jar files I
> embed in my bundle, won't that eat up some time looking for it? Not only
> would the classloader have to open up the bundle .jar file, but then it
> would have to look in the /lib path for any .jar/.zip files, open them up,
> and scan every entry in there for the right class. I am assuming because the
> files are on disk, this could eat away at performance, and that just begs to
> ask, how well does OSGi scale in this situation? What if I have a complex
> relationship of service dependencies that end up scanning several bundles
> for various classes at one given method call in a given service. Won't this
> hurt performance? Are there guidelines put in place that indicate few if any
> embedding should be used? If someone could elaborate a bit I guess on how
> this process works, how it effect performance and so forth, I'd appreciate
> that.
>
> Other than that, it appears OSGi basically has what we want to add to
> Equinox. I also just read that apparently the next version of Eclipse will
> be 3.0, and because of that, a lot more of what Equinox is going to do may
> end up in Eclipse. So, is there any reason we would be working on a separate
> branch from Eclipse? I am curious if it makes sense to build two separate
> but what now appears to be very similar products because of the longer time
> frame for the 3.0 release.
>
> Thanks.
>
>
|
|
|
| Re: OSGi questions.. [message #23725 is a reply to message #23512] |
Sat, 26 April 2003 10:47 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Export
OSGi bundles export ONLY packages. These packages can come from the
Bundle's JAR file and/or from JAR files embedded in the bundle's JAR file.
If 2 bundles export the same package, the OSGi framework will pick one
and force both to use the same classloader to assure no
ClassCastExceptions happen. (I.e. an export implies an import). The
actual choice depends on version of the package.
One of the reasons this is done on package, is that JAR files are not
well defined entities and packages are.
So you would specify your dependency javax.servlet and
javax.servlet.http and not on servlet.jar (I have lots of different
versions of that one lying around!).
Bundle-Classpath
The header for using embedded JAR files is Bundle-Classpath ... and it
works very nicely! The Classpath header is from SUN and works ONLY with
external URLs and not the JAR file itself (which is a pity).
Performance is not an issue because most of this can be cached and can
be sped up during installation. Also, this embedding is only one level
deep. Also note that OSGi has a global namespace index for packages that
greatly reduces the search. Most of the time it knows exactly which
classloader should handle the actual loading. Class that are not in the
global namespace, must come from the system classpath or are private, in
which case the classloaders are know as well and not so much searching
is done.
So this is imho not a scaling issue.
Kind regards,
Peter Kriens
Kevin wrote:
> Ok, so I have some of my own. ;)
>
> Is the way OSGi handles exporting 3rd party libraries the same as Eclipse?
> Do you declare, via the manifest.mf file in the Bundle-Export (or whatever
> its name is..) all libraries (.jar/.zip I presume are the only acceptable
> formats?) that are allowed to be used by other bundles? If so, I am not
> quite sure I understand how the whole version thing works. For example, if
> there are two bundles that both export servlet.jar, how is it determined
> which one is used? What if my bundle wants to use servlet.jar 2.0 and the
> highest servlet.jar is 2.2? Do I have to specify a specific version? That is
> assuming my bundle is old and was built around 2.0, for example.
>
> Another thing, it appears all bundles are a single .jar file each. Java has
> no built in mechanism to search within .jar files for embeded .jar/.zip
> files. I am going to take a wild guess that because the spec indicates that
> it can embed libraries in this manner, the ClassLoader must be implemented
> in a manner that can scan a given bundles .jar file for embeded .jar files
> and actually open them up to look for classes inside of them? I have tried
> using the Class-Path portion of manifest.mf in my own .jar file to locate
> /lib/xxx.jar that was embeded in the .jar file at that location. At runtime,
> I always get the ClassNotFoundException. If I unjar the .jar file, then it
> finds it, but while it is inside the .jar file only, it can not be found. IS
> this in fact true? Or does Java actually open up .jar files, and open up
> embeded .jar files? If not, then I have another question, how does this have
> an effect on performance? I mean, if at runtime the JVM asks my bundles
> loader to find a class, and it is inside of one of the say 8 .jar files I
> embed in my bundle, won't that eat up some time looking for it? Not only
> would the classloader have to open up the bundle .jar file, but then it
> would have to look in the /lib path for any .jar/.zip files, open them up,
> and scan every entry in there for the right class. I am assuming because the
> files are on disk, this could eat away at performance, and that just begs to
> ask, how well does OSGi scale in this situation? What if I have a complex
> relationship of service dependencies that end up scanning several bundles
> for various classes at one given method call in a given service. Won't this
> hurt performance? Are there guidelines put in place that indicate few if any
> embedding should be used? If someone could elaborate a bit I guess on how
> this process works, how it effect performance and so forth, I'd appreciate
> that.
>
> Other than that, it appears OSGi basically has what we want to add to
> Equinox. I also just read that apparently the next version of Eclipse will
> be 3.0, and because of that, a lot more of what Equinox is going to do may
> end up in Eclipse. So, is there any reason we would be working on a separate
> branch from Eclipse? I am curious if it makes sense to build two separate
> but what now appears to be very similar products because of the longer time
> frame for the 3.0 release.
>
> Thanks.
>
>
>
|
|
|
| Re: OSGi questions.. [message #23767 is a reply to message #23512] |
Sun, 27 April 2003 13:15 |
| Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
> Other than that, it appears OSGi basically has what we want to add to
"basically" is indeed the problem.... It's like a famous drink: they
look the same (from a 10000 ft view),
they do the same, but they are not the same.
> Equinox. I also just read that apparently the next version of Eclipse will
> be 3.0, and because of that, a lot more of what Equinox is going to do may
> end up in Eclipse. So, is there any reason we would be working on a
separate
> branch from Eclipse? I am curious if it makes sense to build two separate
> but what now appears to be very similar products because of the longer
time
> frame for the 3.0 release.
There are several reasons to keep separate streams:
- Because equinox is not eclipse 3.0 (equinox contains more), and
merging the two would immediately cause the loss of people whose work is
exploratory.
- It gives a place for non eclipse commiter to share code. Becoming an
eclipse commiter is for short a long process built on commitment, trust and
code.
- We do not want to break core, before having something "stable".
P
|
|
|
Goto Forum:
Current Time: Mon Jun 02 18:07:27 EDT 2025
Powered by FUDForum. Page generated in 0.04197 seconds |
Home