replying inline again :) All in short. Current branch 4.x.y are working with wicket 8. Secondly I will take a look in jira to align bug / features to the current source.
On Sun, Feb 26, 2017 at 2:55 PM, 'Christoph Läubrich' via OPS4J < [email protected]> wrote: > Hi, > > > As for now there should be no api breaks for us. BUT wicket itself have > made a API breaks between 6 and 8 > This doens't matter for pax-wicket, since the user then can choose for one > of the supported Wicket-Version. So if no changes are required only version > range should be ajusted! Also Wicket deps does not matter at all at least > if they are not also pax-wicket dependencies and ther are changes needed. > You can think of Pax-Wicket as an operationg system and Wicket as an > application. An operation system can support different versions of > applications as long as the OS-API remains the same, only if the > Application uses new OS-API (e.g Win7 versus WinXP APIs) you are required > to upgrade your OS in order to run it. > > > > I simply have no knowlegede on howto use wrap outside karaf > You can always install the pax-wrap URL provicer in any OSGi framework. > For the itest take a look at the *wrappedBundle() *Option > Great thanks :) > > > > Yes I have corrected some stuff and done... > Check if your changes work with wicket 6, 7, 8 then no version change is > required (see above) otherwise a 4.0.0 should be fine. > As you wrote "some stuff" it would be nice to create a JIRA issue for each > semantic change (e.g. adjust XYZ class to work with ne Wicket 8 ABC feature) > code for wicket 8 will not work with wicket 7 and 6, there where api breaks.And as such wicket 8 are incompatible with 6 and 7. > > > > Please elaborate on what you mean by dynamic-import feature and what I > have done to break it? > Take alook at https://ops4j1.jira.com/browse/PAXWICKET-483 you disabled > the weaving-hooks in your last commits. > For any changes they were only done in order to make injection work again.. There where major issues when I began on the project and most of the the injection samples where not working.. I cant remember specifically why the dynami c import were disabled. > > > Am 25.02.2017 20:37, schrieb nino martinez wael: > > Hi Christoph > > In short all samples and tests are passing for the karaf integration test. > The felix ones are failing. > > Replying inline.. > > On Fri, Feb 24, 2017 at 1:25 PM, 'Christoph Läubrich' via OPS4J < > [email protected]> wrote: > >> WHat do you mean by "apparently the Wicket devs have included non valid >> bundles namely" If the bundle itself is invalid (e.g. missing imports, >> invalid manifest) you should open an issue at the coresponding projekt. >> If the Bundles itself have no OSGI_header information you should be able >> to use the wrap protocol or open an ehancement-request at the coresponding >> project. >> > As I wrote the two dependencies can be fixed using the wrap protocol.. I > simply have no knowlegede on howto use wrap outside karaf, in order not to > break felix and eclipse compability.. I agree that there should be tickets > opened for these things in the relevant places.But as always time are > scarce. > >> >> Beside this, Pax Wicket Version number should not be aligned to an Wicket >> versioning for the following reasons: >> - Depending on the changes made Wicket Pax Wicket 4 (as an example) might >> be able to work with Wicket 6 to 8 by just ajusting the version import range >> - If we do API-Breaking changes we must bump up the major version for Pax >> Wicket without the need to wait for a new Wicket release >> > As for now there should be no api breaks for us. BUT wicket itself have > made a API breaks between 6 and 8. Also there's changes for some of the > dependencies of wicket. I am also looking into websocket support. > >> >> Of course, if Pax-Wicket needs to be changed to support a newer Wicket >> version the Major version should be upgrade. But this has nothing to do >> with Wicket or vice versa. >> > Yes this is the case here so it will at least be called 4.x.y.. > Potentially 4.0.0 > >> So if you are unvertian, please ask on the mailing list, your last >> changes have already broken the dynamic-import feature of Pax Wicket :-( >> > Please elaborate on what you mean by dynamic-import feature and what I > have done to break it? > >> >> So the general process for upgrading to the next Wicket-Version is: >> - Increase the Version-range to the new Wicket-Version >> > Done, but since wicket 6,7 and 8 are not compatible and contains api > breaks for the new release the only supported major version will have to be > 8. This is normal procedure in the wicket community. > >> - Upgrade Wicket-Version to latest one >> > Done > >> - Check if there are any changes necessary >> > Yes I have corrected some stuff and done... > >> >> If yes bump up major version, if no keep major but increase minor version. >> >> Am 24.02.2017 12:46, schrieb nino martinez wael: >> >> Hi guys >> >> I have successfully upgraded to Wicket 8.0.0 M4 for the karaf part. But >> are stuck on the felix integration tests, apparently the Wicket devs have >> included non valid bundles namely: >> >> org.danekja/jdk-serializable-functional/1.8.2 >> >> com.tdunning/json/1.8 >> >> For the karaf tests I can just use the wrap protocol and everything works >> again. However I don't know what todo for felix? Since there are no tests >> for equinox, I have not tested on that. >> >> >> <bundle>wrap:mvn:org.danekja/jdk-serializable-functional/1.8.2</bundle><bundle>wrap:mvn:com.tdunning/json/1.8</bundle> >> >> I have also pondered about aligning PAX Wicket's versioning numbering to >> Wicket so that we follow their trail of numbers. And as such the new PAX >> Wicket version would become 8.0.0 M4, whats your opinion on this? >> >> Anyhow there are several major changes in this release of wicket, namely >> the dependency on servlet api 3.x and the optional inclusion of websockets >> (I have not yet made an integration test for this). >> >> Any help will be highly appreciated.. >> >> GIT hub url: https://github.com/ops4j/org.ops4j.pax.wicket.git >> >> Branch: v4.x.y >> >> regards Nino >> >> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - [email protected] >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OPS4J" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - [email protected] >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "OPS4J" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/ops4j/Y8OKNSbgTpw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Best regards / Med venlig hilsen > Nino Martinez > -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- > You received this message because you are subscribed to a topic in the > Google Groups "OPS4J" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/ops4j/Y8OKNSbgTpw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Best regards / Med venlig hilsen Nino Martinez -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
