Also, many folks already migrated their applications to 1.5. And many projects depending on wicket (wicket stuff) have done their migrations as well. I seriously doubt anyone will look fondly upon our project when we decide to move things around yet again. In fact it would be detrimental to our credibility and I seriously question why we even consider this in 1.5-rc6 stage...
Martijn On Thu, Aug 18, 2011 at 7:38 AM, Martijn Dashorst <[email protected]> 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 >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
