A quick look in the patch shows two code duplications but otherwise looks
OK.
I'd like to ask other OSGi users to take a look as well and add a comment.
On Tue, May 24, 2011 at 12:23 PM, Daan van Etten wrote:
> Op 27 apr 2011, om 09:43 heeft Daniele Dellafiore het volgende geschreven:
> > This i
Op 27 apr 2011, om 09:43 heeft Daniele Dellafiore het volgende geschreven:
> This is also my main point to conversation. We're talking about being
> somewhere really close to a nice out of the box OSGi support. Why not take a
> little effort to make it complete? Also, having packages that span thro
its too late to be doing this for 1.5.
i agree we should not have package namespaces split across the jars,
but fixing it in 1.5 would touch almost every single file and a lot of
user code would be broken as a result. a good example is IDetachable
which is in wicket-util but i left it in the wicke
On Wed, Apr 27, 2011 at 11:19 AM, Daniele Dellafiore
wrote:
> On Wed, Apr 27, 2011 at 8:57 AM, Martin Grigorov wrote:
>
>
>> I'm not against improving the current state. I'm saying that it want
>> last long without your help.
>> I said several times that the community can create the uber-jar
>> pr
On Wed, Apr 27, 2011 at 8:57 AM, Martin Grigorov wrote:
> I'm not against improving the current state. I'm saying that it want
> last long without your help.
> I said several times that the community can create the uber-jar
> project in wicketstuff but so far no one wanted to do it.
> I can do it
Hi,
On Wed, Apr 27, 2011 at 10:43 AM, Daniele Dellafiore
wrote:
> On Tue, Apr 26, 2011 at 9:12 PM, Daan van Etten wrote:
>
>> Op 26 apr 2011, om 16:41 heeft Martin Grigorov het volgende geschreven:
>>
>>
>> Not doing anything now because it can break in the future is not a really
>> good argumen
On Tue, Apr 26, 2011 at 11:48 PM, Eike Kettner wrote:
> Hi Daniele,
>
> >
> > This is not as bad as having to package the uber-jar with the war, sure.
> > Better than keeping a separate wicket codebase, at least :)
> >
> > Anyway it's still a custom solution that I, and all wicket developers,
> h
On Tue, Apr 26, 2011 at 9:12 PM, Daan van Etten wrote:
> Op 26 apr 2011, om 16:41 heeft Martin Grigorov het volgende geschreven:
>
>
> Not doing anything now because it can break in the future is not a really
> good argument..?
> Anything can break, that's why there are unit tests, release candid
Hi Daniele,
On [Tue, 26.04.2011 12:19], Daniele Dellafiore wrote:
> On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner wrote:
>
> > the "uber-jar" is only concerning wicket, not any war bundle. while it
> > would be of course "nicer" to have all wicket jars as separate bundles
> > available out of t
Op 26 apr 2011, om 16:41 heeft Martin Grigorov het volgende geschreven:
>> [..]
>> Wicket bundles are some sort of raw jars+metadata that can be assemled in a
>> custom way to become a usable OSGI bundle. Whatever you consider the
>> uber-jar solution to go good or not, this is a flaw.
>>
> Wic
Hi Danielle,
On Tue, Apr 26, 2011 at 2:19 PM, Daniele Dellafiore
wrote:
> On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner wrote:
>
>> the "uber-jar" is only concerning wicket, not any war bundle. while it
>> would be of course "nicer" to have all wicket jars as separate bundles
>> available out o
On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner wrote:
> the "uber-jar" is only concerning wicket, not any war bundle. while it
> would be of course "nicer" to have all wicket jars as separate bundles
> available out of the box. but one solution I find quite ok is creating
> one bundle out of core
On Tue, Apr 26, 2011 at 1:48 PM, Eike Kettner wrote:
> the "uber-jar" is only concerning wicket, not any war bundle. while it
> would be of course "nicer" to have all wicket jars as separate bundles
> available out of the box. but one solution I find quite ok is creating
> one bundle out of core,
the "uber-jar" is only concerning wicket, not any war bundle. while it
would be of course "nicer" to have all wicket jars as separate bundles
available out of the box. but one solution I find quite ok is creating
one bundle out of core, request and util. this will then be a uber-jar
that brings wic
On Mon, Apr 25, 2011 at 8:00 PM, Martin Grigorov wrote:
>
> On Mon, Apr 25, 2011 at 9:29 PM, Daniele Dellafiore
> wrote:
>
> The idea of OSGi is to have interface and replaceable implementations.
> You can use this to replace Hibernate with EclipseLink as JPA
> implementation, or one JMS implemen
On Mon, Apr 25, 2011 at 9:29 PM, Daniele Dellafiore
wrote:
> On Mon, Apr 25, 2011 at 7:20 PM, Martin Grigorov wrote:
>
>> It is the same conversation.
>> You need uber-jar. At least one that combines -util, -request and
>> -core. Everything else is optional, depending on your app needs.
>>
>
> Ok.
I would reverse the question and ask: why was wicket broken into multiple
packages in the first place? I assume there are use cases where:
- someone would need only the content of wicket-core and none of the extras
- someone would need only wicket-core + wicket-request
- someone would need only
On Mon, Apr 25, 2011 at 7:20 PM, Martin Grigorov wrote:
> It is the same conversation.
> You need uber-jar. At least one that combines -util, -request and
> -core. Everything else is optional, depending on your app needs.
>
Ok. As you see I read and answered to that.
>
> Can you describe what i
It is the same conversation.
You need uber-jar. At least one that combines -util, -request and
-core. Everything else is optional, depending on your app needs.
Can you describe what is the problem to use the uber-jar? Or what are
the benefits to deploy these three jars separately in the OSGi
conta
Are you referring to this conversation?
http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html
If so, I read it and answered that I'm not interested in any solution that
involves the uber-jar. I do not see any advantage in that solution over a
normal wa
Hi Daniele,
Me and later Eike explained to you in the other thread you started few
months ago how to solve exactly this problem.
It seems you didn't read it at all. Please read again the part
mentioning Wicket 1.5 RC1.
On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore
wrote:
> I did it. Yes, t
I did it. Yes, the tough way but I did it.
Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the
1.5-SNAPSHOT I built.
Basically I renamed the .util and .request packages in -core bundle to be
.core.util and .core.request.
I had to make a class public in another package under -reques
it is not.
I'm hacking on the trunk to make that work.
Maybe a quick solution is just change org.apache.wicket to
org.apache.wicket.core in the -core bundle.
Of course there are some default scope classes that works through different
packages but I can just make them public for now.
On Mon, Apr
On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore wrote:
>
> I think that the wicket package layout should be changed now that -util and
> -request bundles have been detached from -core.
>
>From an OSGi perspective, we should probably try to make sure that
packages don't span jar files. Every
Again, org.apache.wicket.IClusterable is in the -util bundle but the webapp
looks for it in the -core bundle.
There's not workaroiund for this.
I think that the wicket package layout should be changed now that -util and
-request bundles have been detached from -core.
On Mon, Apr 25, 2011 at 2:51
I've "solved" this removing
org.apache.wicket.request
from Export-Package in wicket.core bundle jars.
This works only because I'm not using request.ClientInfo class.
Probablhy during runtime there will be other problems.
>From the OSGI perspective, having duplicate packages exported by different
Hi.
Whe I try to start my wicket webapp from Karaf, I receive a
NoClassFoundException agains Request.
The problem is that my app imports the package org.apache.wicket.request
from wicke.core bundle that have the package, but not the class.
The fact that the same package is exported from two bundle
27 matches
Mail list logo
