Fair enough, but there's no reason for a fourth artifact. Anything can be done with the third one.
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 >>>>> >>>> >> >>
