Java Module System
Submitted by birkey on Wed, 06/15/2005 - 07:37.
Hi,
Take a look at JSR 277, Java Module system
http://jcp.org/en/jsr/detail?id=277
This seems a good candidate format for JNode plugin's deployment unit, so we may base our Installer on this. It almost includes all what we want about the deployment framework of JNode:
o A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources.
o A versioning scheme
o A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.
o Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
o A set of support tools, including packaging tools as well as repository tools to support module installation and removal.
-Birkey
- Login to post comments
OSGi R4 and the Java Module System
There is already a mature and active community around a module system for Java. This is the OSGi Alliance.
o Many of the companies supporting JSR 277 are already supporters of the OSGi Alliance.
o In the JSR Review Ballot for JSR 277 you will see that most of the EC member comments include the statement that OSGi R4 should form the basis for JSR 277.
http://www.jcp.org/en/jsr/results?id=3238
It would be a tremendous benefit to the Java community if JNode supported such a strong and mature framework as OSGi. For example, the Apache Directory project has OSGi-compliant components for such services as LDAP, Kerberos, and DNS. Being able to have these services plug into JNode using the OSGi standard would be very powerful.
OSGi is not free
Patents, royalties etc. allowed to be included in specifications/licenses
Response from an OSGi executive
I got this response from an OSGi executive:
"Richard Hall implemented OSCAR before he became a member. Eclipse
was run by IBM, but now is an independent organization that is not a member.
It has always been the intention that the specification was as widely
implemented as possible.
Joining the compliance program is, however, exclusively for members
and associated with a fee (at least for R3). Members can perform the
compliance testing on behalf of others. So if JNode or Apache wanted
to have the compliance certificate, they would need a member to run
the test suites."
No questions about certificates
There is no questions about certificate compliance
JNode (IMHO of course) would NOT include any code covered by license _incompatible_ with root license (read LGPL)
Excerpts from osgi "specification license"
==========================================
Q. Can the OSGi Member which submitted copyrighted material pursuant to an RFC charge end users of the Final Specification a copyright royalty?
A. No. However, any Member which has patent claims which are incorporated into the Final Specification may, pursuant to Section 5.3 of the Member Agreement, charge a reasonable royalty for a license to such patent rights.
==========================================
Java Plugin Framework (JPF) project
Hello,
I'm a developer of the Java Plugin Framework (JPF) project - a small library to help building plug-ins based applications. Maybe you'll find it interesting for JNode.
To be shortly, JPF is inspired by Eclipse plug-in architecture and thus is very close to it. Actually I've tried to "reinvent" Eclipse's plug-ins "micro kernel" to make it usable separately in any Java project (note that this is NOT the modified Eclipse code but completely independent implementation).
The project site is available at http://jpf.sourceforge.net You'll fine there documentation, tutorial and a small demo application. Feel free to ask your questions in the project forum.
//Dmitry
Interesting
Yes, the JSR sound promising. But you should also have a look at section 3 of the JSR. It doesn't list any existing documents - i.e. the JSR only specifies requirements right now. Also the schedule (point 2.13) says public review will start in 2007 (if its not delayed).
Nonetheless you're right: the project is worth keeping an eye on it. I also emailed the spec lead to point him on another project of mine, the codehost system (http://codehost.jini.org/) that is related to the same topic. The system is mainly based on the convention to use domain names as prefix of Java package names and based on this conventions is able to download classes when only the name of the class is given. BTW this project is also the reason why I'm not too fast in continuing the Jini & Jnode efforts - however I still have it in mind and will continue working on it.
Sebastian
Now...
Hi, I am new here, but I have some good experience in writting netbeans modules and I am starting at writting eclipse plug-ins.
If you read the last paragraph of the JSR, you will see that the links point to ready-to-use modular systems.
For those that never took the time to look at the netbeans platform module, give it a deep read. The effective code that does the boostrap and the protected, herachichal classloader for every module is really small. It supports all the features wishes mentionned in the JSR (except some restrictions for JNI code). Also, it permits to declare within an xml file called "layer", early access information needed at runtime without having to effectivly load the class in memory (like module name, menu entries, extensions to other modules) thus improving the overall memory footprint.
The major problem is to find this code within the netbeans source code....Searching for the Main and NonGui classes will help to jump into the bootstrap code.
Hopes it will prevent anybody of reinventing the wheel....
Cedric
Re: Now ...
Hm, seems like I missed the last part with the additional information ...
Also NetBeans seems to support (un-)installation of modules in the sense that custom code is executed on installation/uninstallation of a module, that the codehost system doesn't address. Further it became apparant to me that the codehost system even avoids the creation of modules as additional to-be-managed entities. Maybe I should emphasize this difference more stongly ...
Sebastian