|
Hi Jonah,
On 10/26/2016 12:35 PM, Jonah Graham wrote:
Hi Scott,
Answers inline.
<stuff deleted>
- The IDataset, originally part of the API plug-in was 1.7 or greater
since DAWNSci initial import, the 1.8 was put in place in April.
Although some other bundles had lower reqs, having any dep be 1.8,
this essentially meant that everything was 1.8 in practic
Ok. If there are parts that require java8 I guess you basically
have just a few choiced:
1) Go with java8 and leave org.eclipse.january as is;
2) Refactor org.eclipse.january (if possible) into multiple (2?)
bundles...one of which using EE 1.7 (or 1.6) and the other of which
uses 1.8.
I understand that things are moving toward 8 pretty quickly, but it
always surprises me how slow vm upgrades are in practice in many
environments.
>
> 2) The commons.math3 lib:
>
> org.apache.commons.math3;bundle-version="[3.2.0,4.0.0)";visibility:=reexport
>
> 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.
Yeah. Understood. For these libs that have been around a while
it can be difficult to get consumers to upgrade them (i.e. risk of
breaking things).
> Also, why does it reexport this lib?
Not sure, can't immediately see a reason for this, so it
should be removed.
Unless you would like me to open bugs, I'll leave that to the
January committers. Let me know.
> 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 :-)
I understand...both of my 'relatively new' comments were based upon
the fact that for the math3 and slf4j the Kura target platform is
currently using an older version. I expect this will change with
their next release also (hopefully something that fits in your
version ranges).
> 5) The org.eclipse.january.metadata.internal package
is exported...yet it's called 'internal'. Is that desired?
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?)
BND does I believe. I don't think PDE, Maven, Tycho do this
automatically but of course on the Runtime tab, the exported package
properties can set the version number (this just adds
mypackage;version="1.0.0" in the manifest).
> If you would like a contribution for any of these I would
be happy to do so.
Contributions welcome.
Ok, if you want help with any of the manifest bugs feel free to
assign to me or let me know how I can help otherwise.
Scott
|
