Sounds fine to me: If the sub-modules are relevant for wicket devs only, then we shouldn't bother our users with it, whether in osgi or non-osgi environments.
Sven On 08/18/2011 09:41 PM, Martin Grigorov wrote: > Andreas Pieber works on a patch for approach 2). > -util, -request and -core will be shaded in wicket.jar > A new module named wicket-osgi will be introduced with all OSGi > related impls of IClassResolver, ISerializer, etc... > -spring and -guice will receive some patches so they can be used in > OSGi environment as well > > -osgi, -spring and -guice will have Maven dependency 'org,osgi' with > scope 'provided' so they can be compiled. At runtime OSGi containers > will use header "Import-Package" to resolve the dependencies. > > On Thu, Aug 18, 2011 at 10:33 PM, Igor Vaynberg <igor.vaynb...@gmail.com> > wrote: >> brian's patch shades the artifacts under wicket-core instead of wicket... >> >> -igor >> >> On Thu, Aug 18, 2011 at 12:13 PM, Martin Grigorov <mgrigo...@apache.org> >> wrote: >>> Hi, >>> >>> This is related to the currently running vote about OSGi problem with >>> split packages in sub-modules (-util, -request and -core). >>> Sven Meier - today, James Carman - few months ago, and few other >>> people doubted about the decision to split wicket.jar in sub-modules. >>> I believe this is the way to go and I even want to propose "a >>> solution" which is closely related to approach 2) in the other thread. >>> With approach 2) these sub-modules will be merged/shared back into one >>> uberjar (wicket.jar) which will be the same as in Wicket 1.4. >>> Additionally I suggest to set 'skip=true' setting of >>> maven-deploy-plugin for the sub-modules. This way they wont be >>> deployed in Maven repos and will be something that only Wicket devs >>> know and care about. The users will see only the merged wicket.jar and >>> the other "normal" modules like -extensions. -ioc, -spring, etc. >>> We already discussed this in IRC and Brian Toppings patch contain >>> these changes but I'd like to have more opinions before doing it. >>> >>> -- >>> Martin Grigorov >>> jWeekend >>> Training, Consulting, Development >>> http://jWeekend.com >>> >> > > >
