Nathan Beyer wrote:
Felix has a nice Maven 2 plugin for generating OSGi manifests -
http://cwiki.apache.org/FELIX/osgi-plugin-for-maven-2.html.
We are looking at modifying Felix' maven plugin to use Peter's new bnd tool.
- richard
-Nathan
On 10/27/06, Richard S. Hall [EMAIL PROTECTED
Tim,
Peter Kriens created a tool to generate/verify manifests. I am not sure
if it will work for your situation, but you can check it out here:
http://www.aqute.biz/php/tools/bnd.php
- richard
Tim Ellison wrote:
FYI I'm just playing at a new tool to check the manifests in the
classlib
Dalibor Topic wrote:
Thanks for the explanation, Richard. One last question: are the
bundles/packages made for R4 loadable with R2/R3, i.e. do osgi
implementations ignore attributes they don't understand, for example?
Bundles for R2/R3 will run on R4. It is possible to make an R4 bundle
Dalibor Topic wrote:
Tim Ellison wrote:
Dalibor Topic wrote
Finally, we'd need to have our own, ASLv2 licensed OSGi implementation.
I am not sure if there is one, but I hope Geir knows more.
We are in luck:
http://incubator.apache.org/projects/felix.html
Yay!
and
Dalibor Topic wrote:
In terms of using a minimal OSGi environment for partitioning and
management of class library parts, what differences would be relevant
between R2/R3/R4?
Between R2 and R3, not much...you can pretty much consider those two
equivalent.
R4 adds some considerable
Geir Magnusson Jr. wrote:
I assume that what we really need is two kinds of component export,
the public app level API (java.util.*) and a public-yet-not-for-app-
but-fellow-traveler API, such as what other conspiring modules would
export to each other to provide the full public API.
Tim Ellison wrote:
So in OSGi R4 you can export/import individual classes as well as entire
packages?
No, but you can include/exclude classes from a package, sort of like
selecting files in Ant.
What do you mean by 'mandatory attributes'? Is this a conditional
export/import?
Stefano Mazzocchi wrote:
do you plan to add support for class versioning?
how does this impact service frameworks like OSGi and friends?
That is a good question. So far, the JSR does not comment on OSGi R4,
which basically addresses all of the issues raised. Perhaps it is not
mentioned
Enrico Migliore wrote:
All new releases of the OSGi framework are, by design, back
compatible with
the previous versions. Therefore, as far as the OSGi framework is
concerned,
the adoption or not of the JSR277 by Sun will be a problem of the
OSGi consortium.
Well, it could be
Rodrigo Kumpera wrote:
AFAIK the term extension classloader is used for application created
classloaders. The application classloader handles classpath and
installed extends (the dreaded /lib/ext directory).
Well, just writing a simple program that prints the class loaders, I get:
. :-)
- richard
geir
On Jun 8, 2005, at 3:01 PM, Richard S. Hall wrote:
Apparently, only you and I agree. ;-)
Dalibor Topic wrote:
Richard S. Hall wrote:
To me, this is the point. I would like to see all of the libraries
built on to of the JVM to be packaged in a more module- like
fashion
/9/05, Richard S. Hall [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
Heh. I agree. I just was too busy in the VM/class library fire-
fight :)
Yes, perhaps you have just signed the death notice for this discussion
too. ;-)
So, given that my foray into architecture
Apparently, only you and I agree. ;-)
Dalibor Topic wrote:
Richard S. Hall wrote:
To me, this is the point. I would like to see all of the libraries
built on to of the JVM to be packaged in a more module-like fashion,
so that their exports and imports are explicit. There would be many
Jeroen Frijters wrote:
You are correct, but why take the performance and complexity hit to
solve a non-existing problem?
The simpler solution is to just use class loaders as a modularization
mechanism. It is possible (since I have done it in my OSGi framework) to
create a class loader
Jeroen Frijters wrote:
No, that does not solve the problem of getting access to the internals
of public classes. For example, java.lang.VMThread needs to access
package private methods in java.lang.Thread.
You are correct, if your design is such that you need private access
both ways,
Ulrich Kunitz wrote:
On Fri, 27 May 2005, Geir Magnusson Jr. wrote:
(Tomcat : I'd bet they fixed that (or will fix...))
Well, can't the VM just prevent non-kernel code from using them? Maybe
overhead too high?
You could play class loader games, however those could be
circumvented
Dmitry Serebrennikov wrote:
Well, I can think of one thing I would like, some way for the
packages contained in a JAR file be able to inform the underlying
runtime not only its external dependencies, but also what it provides
(or what it exposes). Due to limitations in the Java
Peter Donald wrote:
What you are asking for here is new language extensions - effectively
an assembly or jar access specifier to go along with private,
protected, public and package access. This would be very useful -
particularly if different jars/assemblies were of higher importance in
Humberto S. N. dos Anjos wrote:
Just to add a little note: C# (I'm not sure about the other .NET languages)
deals with this issue by adding a new access modifier, internal, that makes
the class/method/field/property visible by all classes in the same assembly.
Could this behavior be emulated
Tom Tromey wrote:
* com.sun.*. Those pesky java programmers often end up using unfree
APIs. I'm not sure what Harmony could do here; maybe pressure Sun
into make it much more difficult to do this?
Just to raise the point about class library modularity again, since it
is related to this
Tom Tromey wrote:
Some of the tasks here involve ways to better integrate the class
libraries with other free software projects:
http://www.peakpeak.com/~tromey/free-java.html
I think adding OSGi implementations to that list would make sense too.
I think the idea of a configurable, modular VM
21 matches
Mail list logo
