Non-Binding: 1) Representing the jar structure in the package structure is a really good move. First of all this have nothing to do with OSGi at all but is rather good practice anyhow. Still, I'm with Emond (between RC this is simply to much) and with Martijn (about breaking existing projects). Although this would make things very beautiful, also (but not only) in an OSGi context I think this wont be worth the hassle. So looking rational about that one this is one step really should be done in Wicket 2.0 since this will break any existing wicket app anyhow, but not before... --> -1
2) I don't think that there will be a requirement for a custom plugin. In the worst case we have to use the bundle & assembly plugin to do this task but I'm sure we can go without any own Maven Plugin. I'll put up a prototype about that one by latest tomorrow. This one wont affect any existing projects. --> +1 3) In short: Wicket can be one of the best frameworks for OSGi. Putting this into Wicketstuff/Pax Wicket is NOT a question about the technical possibilities, but simply a statement if Wicket wants to be a framework to run in OSGi environments. And I think the answer should be yes --> -1. Kind regards, Andreas On Wed, Aug 17, 2011 at 19:22, 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 >
