It's not about JavaEE users. It's just that -osgi classes will implement interfaces from -core.
On Tue, Aug 16, 2011 at 11:51 PM, Brian Topping <[email protected]> wrote: > 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 >>>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
