| Re: [january-dev] January core dependencies |
Hi Scott,
Answers inline.
On 26 Oct 2016 8:40 p.m., "Scott Lewis" <slewis@xxxxxxxxxxxxx> wrote:
>
> Congrats to the January project on it's 1.0.0 release!
On behalf of all the January contributors, thank you.
>
> I am interested in using the January dataset APIs in an IoT context and have a couple of observations that could be useful...and contributions if you would like. For reference the current manifest.mf from the core bundle (org.eclipse.january) is copied below.
>
> 1) The required EE is currently set to 1.8. Is there a reason it could not be 1.7? The Kura project, for example, currently doesn't run on 1.8...yet, and so if it could be 1.7 it would be usable in perhaps more environments.
Your timing on this is good, we're currently discussing BREE on a different thread. Your comments and concrete use cases are very valuable in this discussion: http://dev.eclipse.org/mhonarc
>
> 2) The commons.math3 lib:
>
> org.apache.commons.math3;bund
>
> a fairly new version range is required. Is it possible to use/include a version lower than 3.2?
3.2 isn't particularly new (2013), 3.5 is in Orbit (S builds for Oxygen as it is based on ebr) and math 2.x is not compatible. One of the issues is that some parts of the ecosystem still use 2.x and that needs to be resolved soon.
> Also, why does it reexport this lib?
Not sure, can't immediately see a reason for this, so it should be removed.
> 3) Would it be possible to use import package rather than require-bundle for commons lang, commons.math3?
Yes, I believe.
> I understand if not (there are certainly split package use cases where it's not, etc), but it might be helpful for some scenarios (more than one version is required).
DAWN, the current heaviest user of January Datasets will need to review this to ensure it doesn't cause a problem. As Diamond normally pushes for Import-Package, I don't know if this bundle if on purpose or not. There are problems already with numerous other bundles in January because of import package vs require bundle.
> 4) The slf4j version required is relatively new...could that be lowered as well?
The 1.7.2 version dates back to 2012, so also not new. This is the version in orbit, although someone ought to upgrade that as there are 19 newer releases :-)
> 5) The org.eclipse.january.metadata.i
It should be exported, but it is missing either an x-internal or x-friends (if there are some friends)
> 6) It would probably be a good idea to have version numbers for your each of your exported packages.
Yes. (Does the tooling do this automatically?)
> If you would like a contribution for any of these I would be happy to do so.
Contributions welcome.
> Thanks again for the work though...we are enjoying using it.
I think there is a lot we are learning and I really appreciate feedback from someone who has been contributing to the simrel for such a long time!
> Scott
>
> org.eclipse.january manifest
>
> Manifest-Version: 1.0
> Bundle-ManifestVersion: 2
> Bundle-Name: Eclipse January Datasets (Incubation)
> Bundle-SymbolicName: org.eclipse.january
> Bundle-Version: 1.0.0.qualifier
> Bundle-RequiredExecutionEnviro
> Export-Package: org.eclipse.january,
> org.eclipse.january.dataset,
> org.eclipse.january.io,
> org.eclipse.january.metadata,
> org.eclipse.january.metadata.
> Require-Bundle: org.apache.commons.lang;bundle
> org.apache.commons.math3;bund
> Import-Package: org.slf4j;version="[1.7.2,2.0.
> Bundle-Vendor: Eclipse January
>
>
>
> ______________________________
> january-dev mailing list
> january-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailma