PAX Wicket upgrading to Wicket 8

[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

[Christoph Läubrich]

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.

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

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. So if you are unvertian, please ask on the mailing list, your last changes have already broken the dynamic-import feature of Pax Wicket :-(

So the general process for upgrading to the next Wicket-Version is:
- Increase the Version-range to the new Wicket-Version
- Upgrade Wicket-Version to latest one
- Check if there are any changes neccessary

If yes bump up major version, if no keep major but increase minor version.

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---
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 ops4j+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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 <op...@googlegroups.com> 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 - op...@googlegroups.com

---
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 ops4j+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com

---

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 ops4j+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Best regards / Med venlig hilsen 

Nino Martinez

[Christoph Läubrich]

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

> 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)

> 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.

To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.

[nino martinez wael]

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 <op...@googlegroups.com> 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.