Oi vey! Sorry if I missed this! wicket-core cannot depend on wicket-osgi for the sake of J2EE users....
On Aug 16, 2011, at 4:46 PM, Andreas Pieber wrote: > 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 >>>>>>> >>>>>> >>>> >>>> >> >>
