On Tue, Aug 16, 2011 at 8:54 PM, Andreas Pieber <[email protected]> wrote: > 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. OK. Let drop this as an option. > > >> 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... No, both -util and -request can be used by apps/libraries/frameworks.
Indeed it is Maven problem. We (Wicket devs) want to keep the code clean and that's why the old wicket.jar from 1.4 has been split in three modules. The goal is that -util classes are just utilities, they should not know about Application, RequestCycle, Session, etc. -request can use the classes from -util but again should not see Application, RequestCycle, Session, etc. The best solution for both devs and users I think would be if Maven supported the scenario where you have several modules which depend on each other but should not be installed/deployed in local/remote repos. If this was/is possible then we can merge those sub-modules at install time in wicket.jar again and everything will be the same from user perspective. But AFAIK it is not possible to tell Maven to not install/deploy modules. Maybe we can solve that with a second pom.xml - one pom.xml for developers and another for official builds. > > >> 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. In my previous mail I suggested the following: wicket-bundle will add additional dependency on wicket-osgi and will pack it with -util, -request and -core. This way it will produce a bundle which is use-able in OSGi container. > > >> 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. This is easy to fix but we found the issue in RC builds and it was late to fix it because it will make quite big compile breaks for the RC with the fix. Though it is easy to solve with "Optimize Imports"... > 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? We have different understanding about "get into wicket" :-) You want to put the new classes in wicket-core and I prefer to put them in o.a.w:wicket-osgi:jar which still will be part of Wicket distro and will be used only by users who deploy apps in OSGi containers. So you can develop in wicketstuff/wicket-osgi and when ready we can just adopt it in Wicket. But I guess it is a matter of 10 files or so, so there is not big difference. In both cases I'd like to have some tests which will verify that OSGi stuff still works for the next release. Maybe integration tests ?! > > >> 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 >> > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
