Hey Martin, On Tue, Aug 16, 2011 at 19:07, Martin Grigorov <[email protected]> wrote:
> Sorry, but it is hard for me to understand what you mean in the three > points in your first mail. > Absolutely no problem. I'm quite deep into the entire osgi thing. Therefore I'm sometimes a little bit fast about some details. I present them here to take fears, not to add them. Please feel free to ask as much as you like. I know at least of Harald and Brian around here. Achim and Charles from the Apache Karaf project are also registered on the list. So quite a bunch of OSGi experts around right now :-) > I'll copy them here to make it easier to comment on them: > 1. OSGifying all three of them using split-package. > Without OSGi experience it is hard for me to imagine what this mean. > The problem is that the three packages use partly the same namespace. E.g. a.b.c in util and a.b.c in core. The "plan" in osgi is that this not happen. Still, since there are situations like this the split-package attribute had been introduced. Using this annotation osgi imports packages from more than one bundle (if a specific package is requested). Still this is a bit of a pain merging different packages together. Split package looks something like: Bundle-SymbolicName: b Export-Package: com.company.util;b=split;mandatory:=b Bundle-SymbolicName: c Export-Package: com.company.util;c=split;mandatory:=c This get's even funnier if you have to merge a package from three bundles. Still it is possible. > 2. Embed util and request into wicket-core. > Do you mean here to merge back the code from -util and -request back > in wicket-core/src/main/java ? > I hope you don't because I see this as a step back. What if my app > uses Guice - should I merge the code in -ioc and -guice into -core ?! > No. > Sorry for not being specific here. This is a "maven-only-thing". It is possible to merge different bundles during the build process. OSGi in addition allows a trick called Embedd-Dependencies. This allows you to include other jars into a bundle and use them e.g. only internal or re-export them if necessary. That way there will be only one wicket-core jar including util and request. I'm not sure here. Does util and request contain only "internal" dependencies? In that case this would be a quite interesting solution hiding all classes from util and request from the developer. Otherwise this could work out to be lot of work... > 3. Provide e.g. "apache-wicket" which repacks core, util and request into > one package. > Again: what is the difference with wicketstuff/wicket-bundle project ? > None. Except for (a) that the package is in wicket and not somewhere in Wicket-Stuff (or on OPS4J) and (b) that it will include additional packages. The repacked bundle from wicketstuff is not use-able standalone. Additions as done by wicket-osgi or pax-wicket need to be done to make it useful afterwards. > If the best solution is to deploy just one .jar in the OSGi container > than maybe wicket-bundle should merge -util, -request and -core from > Wicket distro and -osgi from wicketstuff/ops4j. > This has nothing to do with the OSGi container. I hope I was able to outline the problems above. For example, in case you had org.apache.wicket.core, o.a.w.util and o.a.w.request package structures in the three jars the first approach would be extremly easy to implement. There are approaches out there (like features and .kars in Apache Karaf or Applications like in Apache Aries) that allow packaging of all those bundles in one "ueber-unit". So no problem here. So in fact solution 1 is bit of a pain (but let this trouble us :-)) solution 2 could be quite interesting and solution 3 is very similar to the one on wicket-stuff; except that it includes the additional classes. > Start your work in wicketstuff/ops4j and when you have it done then we > can start a vote whether to add it in Wicket distro or not. I've a different idea. Since we would like to get this into wicket do you think we can maintain a fork of wicket trunk on wicket-stuff? We can merge backward here and provide patches via JIRA created by git squash. WDYT? > I cannot > decide that by myself. I have just a single vote. > Of cause; that's why we/I discuss this here in public to reach as many wicket devs as possible :-) > I personally don't like the approach "merge -util, -request and -core > into wicket.jar (as in Wicket 1.4) and put the additional OSGi related > code there too. > In that way I think the following solution might be more interesting for you: use the split-package approach to osgify all three jars and add an additional wicket-osgi package containing all the osgi specific code. I've already taken a quick look at guice and spring and although there are some additions required I think they can be included directly in those "side-projects". Does this sound interesting for you? > No matter what you decide I'll be glad to help you! > Thank you very much Martin! Kind regards, Andreas > > On Tue, Aug 16, 2011 at 6:51 PM, Andreas Pieber <[email protected]> > wrote: > > Hey Martin, > > > > I think this is more kind of a principle question. Yes, it is possible to > > keep this all in wicketstuff/pax-wicket. We can also fork wicket and > > implement osgi support there. Or I can use maven to adapt and > > overwrite/repack wicket in pax-wicket as required. > > > > So again, this thread isn't about what can be done, but rather what > should > > be done. What is the best for wicket and what is the best for osgi. > Wicket > > can become THE webframework for osgi. As long as we do not commit to the > > goal of making wicket a first class osgi framework (but rather work in > > pax-wicket/wicket stuff) people will always have the feeling that there > are > > only minor interests into supporting osgi and eg move on to vaadin. IMHO > > this could not be the goal of such a great framework as wicket. > > > > OK back to the main topic of this thread. I understand that wicket 1.5 is > > already on its way and that you do not want to add anything "new and > > possible dangerous" to the release. On the other hand i've collected tons > of > > experience in the past half year developing pax-wicket. As a karaf pmc > and > > technical architect of various other open and closed source osgi i've > > collected enough experience to be sure that we can also introduce osgi > > support in e.g 1.5.1. There will be extensions to the manifest.mf, > > activators, bundle and service listeners. Also changes to the class > loading > > at various places, but I promise that none of those changes will effect > > wicket runtime in a j2ee server. If this is not the idea we can also > start > > adding osgi support from the first 1.6.0-SNAPSHOT packages. > > > > I really want to do this in a public non-intrusive way presenting the > > possible options we have per move giving you the option to add all > concerns > > you have. > > > > From this point of view, if you want users to "reference" only > wicket-core > > option two is the way to go. In case you want them to reference > everything > > option one is the one to go. If you want to provide an all package anyhow > 3 > > is the right one. Depending on this we can provide an implementation in a > > fork on github and further discuss advantages/disadvantages. WDYT? > > > > Kind regards, Andreas > > > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com >
