1) -1 on moving packages around: little gain with maximum pain. I even -1 this for 1.6 or later without proper discussing and minimizing the effects of moving things around
2) +1 it appears not to require a special, self hosted and maintained plugin 3) well a lot of work has been put into cleaning out our closets as well. What people seem to forget is that OSGi web development is a nice to have, not an essential thing. While I appreciate the efforts that go into supporting OSGi better in Wicket, there are tens of thousands that don't care about OSGi, have been with us for the better part of our 7 year existence and have built thousands of existing projects that run in production. Shifting things around creates work for those tens of thousands with no benefit for them. Don't assume that moving core functionality to another package is a light thing: it touches all code, and nothing says a 8 letter word more than breaking stuff between releases. I don't mind supporting OSGi in Wicket, but I don't want us to loose track of our existing user base and sure as hell don't want to break all applications out there with little benefit. We already break enough API between releases. Martijn On Wed, Aug 17, 2011 at 7:22 PM, Igor Vaynberg <[email protected]> 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 > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
