(non-binding) 1) -1 Breaking the API in such a drastic way is simply not done between RCs. It's not as easy as simple reorganizing imports, because a lot of classes have name clashes with classes in other packages, which require manual interaction. It will take me about a day I guess to fix just our app again after such a change, not to mention to the other apps we have that use Wicket 1.5.
2) +1 This seems to have the least impact and still allow OSGi users to use Wicket. 3) -1 Emond On Thursday 18 August 2011 07:38:44 Martijn Dashorst wrote: > 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
