OSGi joda import does not allow joda upgrade #34

rgilles · 2014-03-17T11:09:02Z

Hi,
We are using a more uptodate version of joda time. And we love to use jackson!
But the current Import-Package header of your jackson-datatype-joda bundle prevent us to upgrade.

Import-Package: ...
 ...
 ...,org.joda.time;version=
 "[2.1.0,2.2)",org.joda.time.format;version="[2.1.0,2.2)"

As you can see your restriction is strong you only support the current minor version: 2.1 and related micros.
At this point of time the latest release from joda time is the 2.3.
Maybe, an option could be to relax your upper bound like this:

Import-Package: ...
 ...
 ...,org.joda.time;version=
 "[2.1.0,3)",org.joda.time.format;version="[2.1.0,3)"

What do you think?

Thanks,

Romain.

The text was updated successfully, but these errors were encountered:

cowtowncoder · 2014-03-17T18:31:52Z

I think that would make sense, and can change the declaration.

cowtowncoder · 2014-03-17T18:36:48Z

... but it looks like I'd need some help in figuring out how to actually change this.
Currently OSGi import section does not specify version ranges, so I am guessing it derives these from Maven dependency (of 2.1). Question then is how to override this. Use of Maven version is something I have had bad experiences with earlier (didn't seem to play nice with builds), but maybe that has changed.
Or alternative maybe including version straight in <osgi.import> would prevent derivation from Maven dependency?

rgilles · 2014-03-18T11:18:12Z

Ok I will try to provide you a pull request with an update of on this Import-Package.

Romain

cowtowncoder · 2014-03-18T17:49:06Z

That would be great!

rolanddb · 2014-08-26T18:18:06Z

Hi,
Is there any update on this issue? Because I'm facing the same problem as rgilles.

I have tried to upgrade from joda time 2.2 to 2.4 by editing the pom.
MVN test fails on two tests in JodaSerializationTest, the two tests relating to DateMidnight.
Since that one is deprecated, I've tried commenting them out and building.
This seems to work fine deployed with my OSGi application.

I feel a bit irresponsible doing this :) Do you maybe have an idea why those tests are failing?

cowtowncoder · 2014-08-27T03:29:40Z

@rolanddb I could use some help on OSGi manifest (as per above).

But I am not able to reproduce the issues you see locally. I tried with Joda 2.4, and using both JDK 7 and 8, but tests for both pass. This is on MacOS FWTW.

rolanddb · 2014-08-27T07:24:21Z

@cowtowncoder Sorry I am not very knowledgable on OSGi. I did not modify the manifest manually, I only changed the pom.xml. Maven updated the joda-time version in the manifest. I understand that you had bad experiences before with this process. I'll monitor how it goes, so far it seems to work fine.

I updated the joda-time artifact to 2.4, and then the manifest looks like this.

Import-Package: com.fasterxml.jackson.annotation;version="[2.4.0,2.5)",c
om.fasterxml.jackson.core;version="[2.4.2,2.5)",com.fasterxml.jackson.c
ore.util;version="[2.4.2,2.5)",com.fasterxml.jackson.databind;version="
[2.4.2,2.5)",com.fasterxml.jackson.databind.deser.std;version="[2.4.2,2
.5)",com.fasterxml.jackson.databind.introspect;version="[2.4.2,2.5)",co
m.fasterxml.jackson.databind.jsontype;version="[2.4.2,2.5)",com.fasterx
ml.jackson.databind.module;version="[2.4.2,2.5)",com.fasterxml.jackson.
databind.node;version="[2.4.2,2.5)",com.fasterxml.jackson.databind.ser;
version="[2.4.2,2.5)",com.fasterxml.jackson.databind.ser.std;version="[
2.4.2,2.5)",org.joda.time;version="[2.4.0,2.5)",org.joda.time.format;ve
rsion="[2.4.0,2.5)"

My only problem was those two failing tests.
I run Java 1.7.0_67 on Osx. So I cannot really explain why those tests failed for me, and not on your machine.

rgilles · 2014-08-27T15:03:03Z

Hi all,
I'm sorry I didn't work on this subject. I will try to provide a pull request next week. The issue comes from the parents' pom.
So to fix this issue I will have to push on more than one repos that's why I gave up last time.
Can somebody give me the process to follow to push on more than one repos?

Thanks,
Romain

cowtowncoder · 2014-08-27T18:25:22Z

@rolanddb Could you share fail message or line numbers for fails you see? I am just hoping to see what could explain the differences here.

@rgilles I am not sure what you mean by parents' pom here.
But as to push, I don't think you can combine pull requests over multiple repositories, so you'd need to create one PR per repo. That should be ok by just linking PRs from this issue.

rgilles · 2014-08-27T18:56:01Z

When I'm talking about what I have to do; I'm not talking about the issue with joda 2.4 and the jdk. I'm just talking about issues in maven-bundle-plugin configuration.
By the way I'm in vacations right now so I can't share anything sorry.

Romain

cowtowncoder · 2014-08-27T20:28:56Z

@rgilles No problem, did not mean to rush you -- I just ask questions whenever I notice something I don't understand because otherwise I'll forget to ask. I am not expecting to get all the answers right away. :)

rgilles · 2014-08-27T21:09:25Z

No problem, I will try to give you an explanation of the issue before the push.

rolanddb · 2014-08-29T14:22:12Z

@cowtowncoder

Failed tests: testDateMidnightSerWithTypeInfo(com.fasterxml.jackson.datatype.joda.JodaSerializationTest): null expected:<...Midnight","2001-05-2[5]"]> but was:<...Midnight","2001-05-2[4]"]>
testDateMidnightSer(com.fasterxml.jackson.datatype.joda.JodaSerializationTest): null expected:<"2001-05-2[5]"> but was:<"2001-05-2[4]">

Both in JodaSerializationTest. Both relate to the deprecated class DateMidnight.

* change the `osgi.versionpolicy` to generate version range import from a given major.minor.micro to the next major. By the way this is the default bnd lib behavior. * remove extract version property in the export statement as it is just the default bnd lib behavior and therefore does not add value except make it explicit * remove the `osgi.import` properties has the default bnd lib behavior provide exactly the same and also ensure that the import statement will be always in sync with the dependency usage.

Fix issue #34: OSGI import statement version range management

Loki-Afro · 2014-10-03T17:12:07Z

@rolanddb @rgilles

The tests still fail on my Mac same lines.
My setup:

Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
Maven home: /usr/local/Cellar/maven/3.2.3/libexec
Java version: 1.8.0_05, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.9.5", arch: "x86_64", family: "mac"

marx-freedom · 2014-10-07T07:19:29Z

@rolanddb @rgilles

I've got same issue with failing tests for DateMidnightSerializer

Maven version

Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e; 2014-06-17T17:51:42+04:00)
Maven home: C:\bin\local\apache-maven-3.2.2
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: C:\bin\local\jdk7-latest\jre
Default locale: en_US, platform encoding: Cp1251
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

I've installed latest tzdata

tzupdater version 1.4.7-b01
JRE time zone data version: tzdata2014g
Embedded time zone data version: tzdata2014g

Print TimeZone.getDefault() to System.out

sun.util.calendar.ZoneInfo[id="Europe/Moscow",offset=10800000,dstSavings=0,useDaylight=false,transitions=79,lastRule=null]

cowtowncoder · 2014-10-07T17:04:10Z

Ok; at this point this issue is only for OSGi updates -- it is not clear that test failures are directly related.

So: it would be good to create a separate issue for test problems.
I just can not reproduce the problem on MacOS, with JDK that says java version "1.7.0_25".

However, perhaps the difference is not OS or JDK version, but default local timezone?

cowtowncoder · 2014-11-14T22:33:34Z

Note: issue #49 deals with test failure.

Still hoping for a patch for pom.xml to help with ability to specify a later Joda version, leaving this issue open.

cowtowncoder · 2015-05-27T18:02:47Z

Since OSGi ought to be handled now, #49 is the part regarding timezone dependency of the test.

rgilles mentioned this issue Sep 3, 2014

Fix issue #34: OSGI import statement version range management #47

Merged

cowtowncoder added a commit that referenced this issue Sep 4, 2014

Merge pull request #47 from javabits/34

d3136f5

Fix issue #34: OSGI import statement version range management

cowtowncoder closed this as completed May 27, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OSGi joda import does not allow joda upgrade #34

OSGi joda import does not allow joda upgrade #34

rgilles commented Mar 17, 2014

cowtowncoder commented Mar 17, 2014

cowtowncoder commented Mar 17, 2014

rgilles commented Mar 18, 2014

cowtowncoder commented Mar 18, 2014

rolanddb commented Aug 26, 2014

cowtowncoder commented Aug 27, 2014

rolanddb commented Aug 27, 2014

rgilles commented Aug 27, 2014

cowtowncoder commented Aug 27, 2014

rgilles commented Aug 27, 2014

cowtowncoder commented Aug 27, 2014

rgilles commented Aug 27, 2014

rolanddb commented Aug 29, 2014

Loki-Afro commented Oct 3, 2014

marx-freedom commented Oct 7, 2014

cowtowncoder commented Oct 7, 2014

cowtowncoder commented Nov 14, 2014

cowtowncoder commented May 27, 2015

OSGi joda import does not allow joda upgrade #34

OSGi joda import does not allow joda upgrade #34

Comments

rgilles commented Mar 17, 2014

cowtowncoder commented Mar 17, 2014

cowtowncoder commented Mar 17, 2014

rgilles commented Mar 18, 2014

cowtowncoder commented Mar 18, 2014

rolanddb commented Aug 26, 2014

cowtowncoder commented Aug 27, 2014

rolanddb commented Aug 27, 2014

rgilles commented Aug 27, 2014

cowtowncoder commented Aug 27, 2014

rgilles commented Aug 27, 2014

cowtowncoder commented Aug 27, 2014

rgilles commented Aug 27, 2014

rolanddb commented Aug 29, 2014

Loki-Afro commented Oct 3, 2014

marx-freedom commented Oct 7, 2014

cowtowncoder commented Oct 7, 2014

cowtowncoder commented Nov 14, 2014

cowtowncoder commented May 27, 2015