Well, bundle-izing does ultimately become more difficult with R4 since
you have to consider the fact that there are possibly multiple versions
in memory at the same time. In the future, it will be greatly
recommended that you use a tool like mangen to create your
headers...although the exact feature needed is not yet implemented.
In essence, bundles need to declare their intra-bundle package
dependencies so that the framework can ensure consistent class spaces.
So, if I import foo and export bar that contains a class that exposes
foo.SomeClass in a method signature of bar.OtherClass, then I need to
inform the framework of this dependency...this is called a "uses"
dependency. It effectively creates like a private or public import as
well as an export grouping mechanism.
-> richard
Timur Mehrvarz wrote:
Yeah, I can see bundle hell already ,-)
Seriously, any regular jar file can be an OSGi bundle at the same
time. So I think, the first step should be, to manage all the jar
files Wicket depends on, to become OSGi bundles (have the proper
manifest file be created for them - this won't hurt anyone). Then it
would be possible to create a Wicket OSGi manifest file with only
java package names being listed as imports (without 'static' jar
files listed on the Bundle-Classpath). When you create such a
manifest file, it would be very nice to know, where the resulting
bundle file will be hosted publicly (in the future). That would allow
easy updating and deployment for OSGi users.
Timur
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
