IMHO the decision to split wicket into core, -util and -request should
be reconsidered after 1.5, so for now:
1) -1
2) +1 (if it's possible without a custom plugin)
3) +0
Sven
On 17.08.2011 19:22, Igor Vaynberg wrote:
a lot of energy has gone into discussing and prototyping wicket+osgi
in the past few days.
it seems the biggest obstacle is that there are split packages between
wicket-[core,request,util] jars. usually we wouldnt fix this now
because we are in RCs and it requires moving pretty much all classes,
for example all classes in core/o.a.w would have to move to
core/o.a.w.core, which is roughly 99% of all classes in Wicket. the
fix should be relatively easy, running fix imports on the project from
an IDE would fix all user-code, but like i said, i do acknowledge it
is pretty damn late in the game to do such a thing.
the alternative, however, seems also rather nasty. we would have to
shade (merge) util and request modules under core. we would also have
to maintain a custom maven plugin, that would be part of our build,
that can generate osgi manifests for the shaded jar. this would also
mean we would have to support the said plugin for all possible
versions of maven out there that people building wicket from source
use.
yet another alternative is to basically give the finger to the osgi
community and do nothing. they can repackage the jar to meet their
needs elsewhere, maybe in wicketstuff. i dont think this is really an
option given how much of people's energy and time went into even
discovering these options, but its here for completeness' sake.
so here are our options:
1) fix the split package problem now with a big
package-rename-refactor that will affect all existing code that
depends on 1.5.
2) introduce a custom maven plugin to shade/manifest wicket-core. fix
the split package problem in wicket.next.
3) leave osgi support out of 1.5
vote ends saturday 8/20 at 10:30am gmt-7.
-igor
