just some side-node from someone who doesn't really know the internal structures of the project and just uses it :) maybe it should be considered to move packages that are clearly only for internal usage to a o.a.w.core.internal package structure, this way it's more clear that those packages should never be exported.
just my 2cents here ;) regards, Achim 2012/3/6 Martin Grigorov <mgrigo...@apache.org>: > 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 <anpie...@gmail.com> wrote: >> On Mon, Mar 5, 2012 at 14:04, Martin Grigorov <mgrigo...@apache.org> wrote: >>> On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <anpie...@gmail.com> 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 <anpie...@gmail.com> 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 <mgrigo...@apache.org> >>>>> 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 <anpie...@gmail.com> >>>>>> 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 <topp...@codehaus.org> >>>>>> > 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 -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/>
