Closed julian1 closed 7 years ago
Sounds like it could be a project configuration issue. edal-common should pull in joda-time v2.2, as required (and it looks like it works when you use that version) - where is version 2.8.1 coming from? I guess you are using another library which uses 2.8.1?
In my project pom I only included edal-cdm, and not edal-common. Maven didn't complain and unzipping the shaded jar shows it wasn't pulled in indirectly/transitively. I'm only using the dataset class and extracting variable metadata, grid bounds - no graphics etc. Everything works as expected (ignoring the joda issue).
If edal-common is required, then I can certainly add it. Otherwise just expressing the joda-time version explicitly is also fine for me.
That's very strange. edal-cdm depends on edal-common - if you depend on edal-cdm it should absolutely pull in edal-common as a dependency. Can you post a copy of your pom.xml on here?
There is a edal-common pom in the resultant jar, but no edal-common class files.
$ unzip -l target/s3-example-1.0-SNAPSHOT-shaded.jar | grep edal-common
0 2016-10-27 08:34 META-INF/maven/uk.ac.rdg.resc/edal-common/
2308 2016-10-27 08:34 META-INF/maven/uk.ac.rdg.resc/edal-common/pom.xml
111 2016-10-27 08:34 META-INF/maven/uk.ac.rdg.resc/edal-common/pom.properties
I think the issue is that aws-java-sdk-s3
is pulling in joda-time
. If I specifically exclude joda-time
from aws-java-sdk-s3
, and remove the joda-time
artifact, then I think it will pull it in as a dependency. I can't be sure, because it doesn't build on my machine (for some reason, the source compatibility level is set to 1.3 and it won't compile because you've used generics), but using mvn dependency:tree
suggests that's the case.
So this is an issue with your project configuration, which can be solved in multiple ways. However, it's probably worth me updating joda-time
to the latest version in EDAL anyway, which may fix things for you.
So this is an issue with your project configuration, which can be solved in multiple ways.
Yes. This is easily worked around.
For the most part, I just thought it was odd, that verifyValueBounds(DateTimeField field, int value, int lowerBound, int upperBound) which going by the signature is a very simple range check started to throw. So my concern was - that it was flagging some other logic issue somewhere (possibly in joda time).
Yeah, I tend to agree that it could be a warning flag. Hopefully the update to joda time 2.9.4 (just released) will fix any problems before they arise...
I've created a simple project following the NcDiag.java example and using DiscreteLayeredDataset to examine netcdf files.
If I don't specify joda-time dependency in the pom - then it defaults to 2.8.1. And running my example generates the following joda bounds check error,
Making a single change to the pom to specify version 2.2 joda dependency - to match https://github.com/Reading-eScience-Centre/edal-java/blob/master/common/pom.xml,
And no exception is thrown,
I'm not sure if it's a joda library or edal-java issue, but I thought it was worth noting here. Cheers.