On Tue, Aug 16, 2011 at 22:42, Brian Topping <[email protected]> wrote:
> Fair enough, but there's no reason for a fourth artifact. Anything can be > done with the third one. > Sorry, but there is :-( wicket-osgi will need a dep to wicket-core --> if wicket-core likes to include wicket-osgi (as planed) than there is a cross-reference :-( Kind regards, Andreas > > On Aug 16, 2011, at 4:33 PM, Andreas Pieber wrote: > > > No, but if you can surpess two, you can also supress all three and adding > a > > forth only logical component putting all others together and add the > > required osgi headers. > > > > Kind regards, > > Andreas > > > > On Tue, Aug 16, 2011 at 22:30, Brian Topping <[email protected]> > wrote: > > > >> Why is that? There are still problems with the first three artifacts > being > >> uploaded to maven central. > >> > >> On Aug 16, 2011, at 4:21 PM, Andreas Pieber wrote: > >> > >>> I think it will be better to integrate them into a forth artifact > >>> wicket.jar. This will make it easier to integrate wicket-osgi tomorrow > >> :-) > >>> On Aug 16, 2011 10:18 PM, "Brian Topping" <[email protected]> > wrote: > >>>> There are definitely a number of ways to go about it. What I am > >>> considering at the moment is that the build will proceed normally for > >> -util > >>> and -request, but set the deploy plugin to not deploy for those first > >> two. > >>> Then -core will integrate the contents of the other two (from local > >>> repository only) and allow the deploy plugin to operate normally. > >>>> > >>>> On Aug 16, 2011, at 4:05 PM, Martin Grigorov wrote: > >>>> > >>>>> On Tue, Aug 16, 2011 at 10:54 PM, Andreas Pieber <[email protected] > > > >>> wrote: > >>>>>> 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. > >>>>> Not sure what Brian has in mind but the idea is to not deploy -util, > >>>>> -request and -core in Maven Cental repo. > >>>>> Those should be something which stays in Wicket's kitchen. Maven will > >>>>> use them to build the uber jar (wicket.jar) which will be deployed > >>>>> with the proper OSGi headers in Maven repos and used by users. > >>>>> Only Wicker devs will know about -util, -request, -core, > >>>>> -whatever-we-split-later... > >>>>> > >>>>> The same can be achieved with CheckStyle but this is a different > topic. > >>>>>> > >>>>>> 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 > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Martin Grigorov > >>>>> jWeekend > >>>>> Training, Consulting, Development > >>>>> http://jWeekend.com > >>>>> > >>>> > >> > >> > >
