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 >
