I just attached a patch to WICKET-4439 that moves all classes which cause problems in o.a.w.core.** where ** is for example - util.io - util.lang - request.mapper ... The ones that don't cause problems are still at their old package. I.e. there are still some classes in o.a.w.util.xyz where xyz is a package name which doesn't exist in any other module.
Additionally I moved o.a.w.IClusterable to o.a.w.util.io.IClusterable (-util), o.a.w.serialize.ISerializer from -util to -core The patch is 360K so I don't expect anyone to review it completely. If there are no objections I'll commit it tomorrow in master. On Mon, Mar 5, 2012 at 3:37 PM, Andreas Pieber <[email protected]> wrote: > On Mon, Mar 5, 2012 at 14:04, Martin Grigorov <[email protected]> wrote: >> On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <[email protected]> wrote: >>> Finally I had the minutes to hack anything together. The script could >>> be found here [1] and shows the following conflicts (and I'm >>> positively surprised by the low number :-)): >>> >>> Package: org.apache.wicket.request.handler.logger in wicket-core, >>> wicket-request, >>> Package: org.apache.wicket.util.string.interpolator in wicket-core, >>> wicket-util, >>> Package: org.apache.wicket.request.mapper in wicket-core, wicket-request, >>> Package: org.apache.wicket.util.resource in wicket-core, wicket-util, >>> Package: org.apache.wicket.util.io in wicket-core, wicket-util, >>> Package: org.apache.wicket.request.handler in wicket-core, wicket-request, >>> Package: org.apache.wicket.util.file in wicket-core, wicket-util, >>> Package: org.apache.wicket.request in wicket-core, wicket-request, >>> Package: org.apache.wicket in wicket-core, wicket-util, >> >> The line above bothers me. >> o.a.w actually is in every module... I guess this is a problem only if >> two or more modules have classes in this package. Since only -core has >> classes there then I guess all is fine. Right ? > > Yep, the question is always: do we need to export a package/import a > package. For example if core has classes in o.a.w, but no other module > it's not a problem. > >> >> The script is not 100% accurate because it misses o.a.w.serialize >> which in both -util and -core. I'll improve it > > thx > > Kind regards, > Andreas > >> >>> Package: org.apache.wicket.util.string in wicket-core, wicket-util, >>> Package: org.apache.wicket.util.crypt in wicket-core, wicket-util, >>> Package: org.apache.wicket.util.lang in wicket-core, wicket-util, >>> >>> Kind regards, >>> Andreas >>> >>> [1] https://gist.github.com/1977817 >>> >>> On Tue, Feb 21, 2012 at 10:44, Andreas Pieber <[email protected]> wrote: >>>> not that I know of, but this should be a small and neat enough >>>> python/perl/shell script to extract the list. I can give it a shot later >>>> this week if you like. >>>> >>>> Kind regards, >>>> Andreas >>>> >>>> >>>> On Tue, Feb 21, 2012 at 08:37, Martin Grigorov <[email protected]> >>>> wrote: >>>>> >>>>> OK. >>>>> Is there any handy tool that automatically will check for these >>>>> problems and tell us how many packages need to be renamed ? >>>>> AFAIK there are no cyclic dependency between Wicket's modules. >>>>> >>>>> On Tue, Feb 21, 2012 at 5:12 AM, Andreas Pieber <[email protected]> >>>>> wrote: >>>>> > Hey, >>>>> > >>>>> > I second Brain on this one: As long as package names do not overlap and >>>>> > there are no circular dependencies between the bundles I see no reason >>>>> > to >>>>> > object. >>>>> > >>>>> > Kind regards, >>>>> > Andeas >>>>> > >>>>> > On Mon, Feb 20, 2012 at 22:57, Brian Topping <[email protected]> >>>>> > wrote: >>>>> > >>>>> >> >>>>> >> On Feb 20, 2012, at 2:53 PM, Martin Grigorov wrote: >>>>> >> >>>>> >> > - renaming for OSGi >>>>> >> > Does anyone have an idea how many packages should be renamed ? >>>>> >> > Some people say that a package should have its module name in it >>>>> >> > (e.g. >>>>> >> > o.a.w.core.**). Other people say that we should rename just the >>>>> >> > packages which exist in two or more modules. >>>>> >> >>>>> >> I didn't see an issue for renaming in Jira, apologies if that was an >>>>> >> oversight. >>>>> >> >>>>> >> There is a "Bundle-SymbolicName" and "Bundle-Version" in the manifest. >>>>> >> Many OSGi projects use the SymbolicName as the base name for the Maven >>>>> >> jar >>>>> >> (i.e. o.a.w.util). >>>>> >> >>>>> >> Then make sure that the Maven jar version complies to OSGi numbering >>>>> >> criteria and use it in both the manifest and the jar version. >>>>> >> http://semver.org/ is compatible with the OSGi numbering, so if that's >>>>> >> still the plan, all is good. >>>>> >> >>>>> >> As far as packages go, having the bundle SymbolicName as the package >>>>> >> root >>>>> >> for the bundle is a good convention (by eliminating package naming >>>>> >> conflicts), but not required. >>>>> >> >>>>> >> If package names do not overlap and circular dependencies between >>>>> >> bundles >>>>> >> are removed, the requirements for OSGi should be satisfiable. >>>>> >> >>>>> >> Brian >>>>> >>>>> >>>>> >>>>> -- >>>>> 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
