[vote] Restructure Packaging for OSGi
Locked
[vote] Restructure Packaging for OSGi
 
|
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 |
Re: [vote] Restructure Packaging for OSGi
|
On Wed, Aug 17, 2011 at 8:22 PM, Igor Vaynberg <[hidden email]> 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. I'm not sure the custom plugin is needed. WicketStuff/wicket-bundle shows that it is possible to merge -util, -request and -core in one uberjar and set all needed OSGi manifest entries I see no problem to merge one more jar (the to be introduced wicket-osgi) into the uberjar > > 3) leave osgi support out of 1.5 > > vote ends saturday 8/20 at 10:30am gmt-7. > > -igor > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com |
Re: [vote] Restructure Packaging for OSGi
|
+1 for 2 (non-binding)
though I also agree with Martin that a ueber-jar wicket-osgi should be sufficient. deep inside I'm longing for a 1 but I fully understand that this is no real option for a 1.5 RC :-) regards, Achim Am 17.08.2011 19:53, schrieb Martin Grigorov: > On Wed, Aug 17, 2011 at 8:22 PM, Igor Vaynberg<[hidden email]> 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. > +1 for option 2) > I'm not sure the custom plugin is needed. > WicketStuff/wicket-bundle shows that it is possible to merge -util, > -request and -core in one uberjar and set all needed OSGi manifest > entries > I see no problem to merge one more jar (the to be introduced > wicket-osgi) into the uberjar >> 3) leave osgi support out of 1.5 >> >> vote ends saturday 8/20 at 10:30am gmt-7. >> >> -igor >> > > -- -- *Achim Nierbeck* Apache Karaf<http://karaf.apache.org/> Committer& PMC OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer& Project Lead blog<http://notizblog.nierbeck.de/> |
Re: [vote] Restructure Packaging for OSGi
|
In reply to this post by Igor Vaynberg-2
Thanks for putting this up, Igor. It's been hard to track what direction to go.
My (non-binding) vote is +1 for #1, +0 for #2, and -1 for #3. Developers on wicket.next are going to have to search and replace at some point, the amount of net pain is therefore the same for a developer that sticks with the framework. Brian On Aug 17, 2011, at 1:22 PM, 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 > |
Re: [vote] Restructure Packaging for OSGi
Administrator
|
In reply to this post by Igor Vaynberg-2
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 <[hidden email]> 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 |
Re: [vote] Restructure Packaging for OSGi
|
Administrator
|
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 <[hidden email]> 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 <[hidden email]> 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 |
|
In reply to this post by Martijn Dashorst
(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 <[hidden email]> > > 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 |
Re: [vote] Restructure Packaging for OSGi
|
In reply to this post by Martijn Dashorst
Non-binding:
I am very interested in long-term OSGi support, but the features being released into Wicket under the "release candidate" moniker is becoming a joke. If it's not a bug fix, it belongs on the other side of the line. -1 option 1 because it will annoy many people, +1 option 2 if it doesn't require a custom maven plugin, and +0 option 3 since 1.6 needn't be too far out. Regards, Dan On Wed, Aug 17, 2011 at 11:20 PM, Martijn Dashorst < [hidden email]> wrote: > 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 > <[hidden email]> 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 <[hidden email]> > 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 > |
|
In reply to this post by Igor Vaynberg-2
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 <[hidden email]>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 > |
Re: [vote] Restructure Packaging for OSGi
|
In reply to this post by Igor Vaynberg-2
For us personally i don't care, <1> could be done, we are not on 1.5
yet and if we do the package rename is easy to fix. But i agree with the rest that this is to big to do in such a late stage, and maybe also after that stage. Because for osgi the simppe fix is to make one big jar right? Thats really easy... I would think that solution could be for now even after 1.5 be the right solution. johan On Wed, Aug 17, 2011 at 19:22, Igor Vaynberg <[hidden email]> 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 > |
Re: [vote] Restructure Packaging for OSGi
|
I fully agree with Martijn!
My biggest concern is to keep our existing user base happy and productive... So... 1) -1 this will make happy a few developers and upset many. we are on a _release candidate_ and should concentrate on eliminating bugs. There's always a next version to add features. 2) +1 as this should not hurt much 3) +0 Cheers Peter Am 18.08.2011 um 09:38 schrieb Johan Compagner: > For us personally i don't care, <1> could be done, we are not on 1.5 > yet and if we do the package rename is easy to fix. > > But i agree with the rest that this is to big to do in such a late > stage, and maybe also after that stage. > Because for osgi the simppe fix is to make one big jar right? Thats > really easy... > I would think that solution could be for now even after 1.5 be the > right solution. > > johan > > > On Wed, Aug 17, 2011 at 19:22, Igor Vaynberg <[hidden email]> 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 >> |
|
non binding 1) -1 2) +1 3) +0
On Thu, Aug 18, 2011 at 5:39 AM, Peter Ertl-3 [via Apache Wicket] <[hidden email]> wrote: I fully agree with Martijn! JC |
Re: [vote] Restructure Packaging for OSGi
|
In reply to this post by Igor Vaynberg-2
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 > |
Re: [vote] Restructure Packaging for OSGi
|
|
The vote ended with 5 binding and 5 non-binding +1s for 2)
I'll apply the patch in https://issues.apache.org/jira/browse/WICKET-3976 On Thu, Aug 18, 2011 at 4:49 PM, Sven Meier <[hidden email]> wrote: > 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 >> > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com |
«
Return to Forum for Wicket Core developers
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |