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 > >>> > >> > >
