You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Andreas Pieber <an...@gmail.com> on 2012/03/05 12:00:57 UTC
Re: Wicket 6.0 status
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,
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 <an...@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 <mg...@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 <an...@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 <to...@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
>
>
Re: Wicket 6.0 status
Posted by Martin Grigorov <mg...@apache.org>.
Thanks, Andreas!
This will be tracked in https://issues.apache.org/jira/browse/WICKET-4439
On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <an...@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,
> 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 <an...@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 <mg...@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 <an...@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 <to...@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
Re: Wicket 6.0 status
Posted by Igor Vaynberg <ig...@gmail.com>.
this is a difference between a framework/library and a service. osgi
is really designed so people can expose services. a service has a
clear separation of what is public and what is private. a framework,
like wicket, on the other hand, has no such separation because the
user is meant to write their code "inside" it so the vast majority of
the api surface has to be exposed.
-igor
On Tue, Mar 6, 2012 at 7:23 PM, Andreas Pieber <an...@gmail.com> wrote:
> Well, on one hand Achim is right and everything not API should be made
> internal. This also has an advantage combined with semver.org since
> you can change anything in internal without to change the major
> version. Though, once you consider that ppl override a class even
> changing protected methods is a break in the contract and have to be
> considered therefore as an API break. The typical usage in OSGi is to
> make everything internal from the beginning and make the classes
> accessible as they're required/requested. Nevertheless I don't think
> this is true in that way for wicket. Since you can modify almost every
> aspect in wicket by providing "own" implementations of interfaces you
> end up pretty often changing various wicket default impls by
> overwriting only one or two methods to your needs. In addition wicket
> has the problem with it's 3 core bundles which would need to share
> internals then. This will result in even greater rebuildings of the
> structure.
>
> Therefore, especially if looking at semver.org, I would be really cool
> having a clear and neat public/private API. Nevertheless, looking at
> the current structure and how ppl are using wicket (at least in
> advanced use cases) I don't think it's a good idea to move classes
> into internal; at least not for now. 6.0 will be (from the size &
> number of breaks) rather a "classical" 1.5 release with API breaks
> (and therefore the required major release) and not that big
> refactoring/change release. Once there is a real internal change,
> touching almost every class; and therefore also every app using wicket
> (an "old style" 2.0) I think we should reconsider this and maybe split
> between api/impl bundles/jars instead of core/util/request. Until this
> moment I think it's better/easier to let it be as it is right now and
> only move those classes around which will produce split-package
> annotations in the MANIFEST.MF otherwise.
>
> my 0.02€
>
> Kind regards,
> Andreas
>
> On Tue, Mar 6, 2012 at 15:11, Martin Grigorov <mg...@apache.org> wrote:
>> Hi Achim,
>>
>> For me (as non-OSGi user) is hard to decide what should be considered internal.
>> IDataStore is an interface and is the API. DiskDataStore is the
>> default impl of this interface. One would say it should be in internal
>> but
>> what if an OSGi user wants to override just a single method of DDS
>> that is either part of the API or is not. For example to add some
>> logging. How he can get access to DDS in OSGi environment ?
>>
>> I guess the OSGi will just say "there is no DDS at all" and then the
>> user will come back to us asking to move this class out of internal.
>>
>> On Tue, Mar 6, 2012 at 4:04 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
>>> 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 <mg...@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 <an...@gmail.com> wrote:
>>>>> On Mon, Mar 5, 2012 at 14:04, Martin Grigorov <mg...@apache.org> wrote:
>>>>>> On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <an...@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 <an...@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 <mg...@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 <an...@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 <to...@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/>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
Re: Wicket 6.0 status
Posted by Andreas Pieber <an...@gmail.com>.
Well, on one hand Achim is right and everything not API should be made
internal. This also has an advantage combined with semver.org since
you can change anything in internal without to change the major
version. Though, once you consider that ppl override a class even
changing protected methods is a break in the contract and have to be
considered therefore as an API break. The typical usage in OSGi is to
make everything internal from the beginning and make the classes
accessible as they're required/requested. Nevertheless I don't think
this is true in that way for wicket. Since you can modify almost every
aspect in wicket by providing "own" implementations of interfaces you
end up pretty often changing various wicket default impls by
overwriting only one or two methods to your needs. In addition wicket
has the problem with it's 3 core bundles which would need to share
internals then. This will result in even greater rebuildings of the
structure.
Therefore, especially if looking at semver.org, I would be really cool
having a clear and neat public/private API. Nevertheless, looking at
the current structure and how ppl are using wicket (at least in
advanced use cases) I don't think it's a good idea to move classes
into internal; at least not for now. 6.0 will be (from the size &
number of breaks) rather a "classical" 1.5 release with API breaks
(and therefore the required major release) and not that big
refactoring/change release. Once there is a real internal change,
touching almost every class; and therefore also every app using wicket
(an "old style" 2.0) I think we should reconsider this and maybe split
between api/impl bundles/jars instead of core/util/request. Until this
moment I think it's better/easier to let it be as it is right now and
only move those classes around which will produce split-package
annotations in the MANIFEST.MF otherwise.
my 0.02€
Kind regards,
Andreas
On Tue, Mar 6, 2012 at 15:11, Martin Grigorov <mg...@apache.org> wrote:
> Hi Achim,
>
> For me (as non-OSGi user) is hard to decide what should be considered internal.
> IDataStore is an interface and is the API. DiskDataStore is the
> default impl of this interface. One would say it should be in internal
> but
> what if an OSGi user wants to override just a single method of DDS
> that is either part of the API or is not. For example to add some
> logging. How he can get access to DDS in OSGi environment ?
>
> I guess the OSGi will just say "there is no DDS at all" and then the
> user will come back to us asking to move this class out of internal.
>
> On Tue, Mar 6, 2012 at 4:04 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
>> 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 <mg...@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 <an...@gmail.com> wrote:
>>>> On Mon, Mar 5, 2012 at 14:04, Martin Grigorov <mg...@apache.org> wrote:
>>>>> On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <an...@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 <an...@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 <mg...@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 <an...@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 <to...@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/>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
Re: Wicket 6.0 status
Posted by Martin Grigorov <mg...@apache.org>.
Hi Achim,
For me (as non-OSGi user) is hard to decide what should be considered internal.
IDataStore is an interface and is the API. DiskDataStore is the
default impl of this interface. One would say it should be in internal
but
what if an OSGi user wants to override just a single method of DDS
that is either part of the API or is not. For example to add some
logging. How he can get access to DDS in OSGi environment ?
I guess the OSGi will just say "there is no DDS at all" and then the
user will come back to us asking to move this class out of internal.
On Tue, Mar 6, 2012 at 4:04 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
> 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 <mg...@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 <an...@gmail.com> wrote:
>>> On Mon, Mar 5, 2012 at 14:04, Martin Grigorov <mg...@apache.org> wrote:
>>>> On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <an...@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 <an...@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 <mg...@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 <an...@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 <to...@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/>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Wicket 6.0 status
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <mg...@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 <an...@gmail.com> wrote:
>> On Mon, Mar 5, 2012 at 14:04, Martin Grigorov <mg...@apache.org> wrote:
>>> On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <an...@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 <an...@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 <mg...@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 <an...@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 <to...@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/>
Re: Wicket 6.0 status
Posted by Martin Grigorov <mg...@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 <an...@gmail.com> wrote:
> On Mon, Mar 5, 2012 at 14:04, Martin Grigorov <mg...@apache.org> wrote:
>> On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <an...@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 <an...@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 <mg...@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 <an...@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 <to...@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
Re: Wicket 6.0 status
Posted by Andreas Pieber <an...@gmail.com>.
On Mon, Mar 5, 2012 at 14:04, Martin Grigorov <mg...@apache.org> wrote:
> On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <an...@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 <an...@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 <mg...@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 <an...@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 <to...@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
Re: Wicket 6.0 status
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Mar 5, 2012 at 3:04 PM, Martin Grigorov <mg...@apache.org> wrote:
> On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <an...@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 ?
Actually o.a.w.IClusterable is in -util.
>
> The script is not 100% accurate because it misses o.a.w.serialize
> which in both -util and -core. I'll improve it
>
>> 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 <an...@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 <mg...@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 <an...@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 <to...@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
Re: Wicket 6.0 status
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Mar 5, 2012 at 1:00 PM, Andreas Pieber <an...@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 ?
The script is not 100% accurate because it misses o.a.w.serialize
which in both -util and -core. I'll improve it
> 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 <an...@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 <mg...@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 <an...@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 <to...@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