On Tue, Aug 16, 2011 at 21:22, Martin Grigorov <[email protected]> wrote: > > 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. >
This could be also done in one pom. Still one option would be to still deploy them AND repackage them (into e.g. wicket.jar). I think this is the same (or at least very similar) to what Brian has in mind :-) > 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. > No we're not :-) I just want to name all options. If it is really only the problem of repackaging we can add wicket-osgi and pack wicket-osgi, core, request and util into one wicket.jar. This one can deploy without any problem (and although there are (optional) osgi deps to any j2ee server AND on any osgi environment. If someone is really caring about the ten additional osgi classes never used he can still use core, util and request; otherwise the repacked wicket.jar will also do. The reason why I would like to work in a fork is NOT core util and request. We do not have to change anything there. BUT for e.g. spring we'll have to. And I don't think that we want to play the same game there again (additional package and repacking). This sounds ways overpowered for about 2-3 additional classes. > 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 ?! > No discussion about this. While pax-wicket might not have the highest unit-test coverage I've about 87% coverage by integration tests. Pax-Exam in combination with Tiny-Bundle and HTML-Unit is extremly useful such situations. So there will be enough tests that you know immediately if any change breaks the osgi integration :-) I'm a little bit busy tomorrow morning but I'll start tomorrow evening providing first ideas in a wicket fork based on Brian's implementation. Kind regards, Andreas > > > > > >> 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 >
