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
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 d...@stuq.nl wrote:
Op 27 apr 2011, om 09:43 heeft Daniele Dellafiore het volgende
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
On Tue, Apr 26, 2011 at 9:12 PM, Daan van Etten d...@stuq.nl 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
On Tue, Apr 26, 2011 at 11:48 PM, Eike Kettner n...@eknet.org 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,
Hi,
On Wed, Apr 27, 2011 at 10:43 AM, Daniele Dellafiore
dani...@dellafiore.net wrote:
On Tue, Apr 26, 2011 at 9:12 PM, Daan van Etten d...@stuq.nl 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
On Wed, Apr 27, 2011 at 8:57 AM, Martin Grigorov mgrigo...@apache.orgwrote:
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
On Wed, Apr 27, 2011 at 11:19 AM, Daniele Dellafiore
dani...@dellafiore.net wrote:
On Wed, Apr 27, 2011 at 8:57 AM, Martin Grigorov mgrigo...@apache.orgwrote:
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
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 wicket
On Tue, Apr 26, 2011 at 1:48 PM, Eike Kettner e...@eknet.org 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
On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner e...@eknet.org 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
Hi Danielle,
On Tue, Apr 26, 2011 at 2:19 PM, Daniele Dellafiore
dani...@dellafiore.net wrote:
On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner e...@eknet.org 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
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.
Wicket is not
Hi Daniele,
On [Tue, 26.04.2011 12:19], Daniele Dellafiore wrote:
On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner e...@eknet.org 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
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
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
On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore ilde...@gmail.com 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
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
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
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
dani...@dellafiore.net
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
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
On Mon, Apr 25, 2011 at 7:20 PM, Martin Grigorov mgrigo...@apache.orgwrote:
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
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
On Mon, Apr 25, 2011 at 9:29 PM, Daniele Dellafiore
dani...@dellafiore.net wrote:
On Mon, Apr 25, 2011 at 7:20 PM, Martin Grigorov mgrigo...@apache.orgwrote:
It is the same conversation.
You need uber-jar. At least one that combines -util, -request and
-core. Everything else is optional,
On Mon, Apr 25, 2011 at 8:00 PM, Martin Grigorov mgrigo...@apache.orgwrote:
On Mon, Apr 25, 2011 at 9:29 PM, Daniele Dellafiore
dani...@dellafiore.net wrote:
The idea of OSGi is to have interface and replaceable implementations.
You can use this to replace Hibernate with EclipseLink as JPA
26 matches
Mail list logo
