You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@edgent.apache.org by Christofer Dutz <ch...@c-ware.de> on 2017/06/18 12:04:55 UTC
Java7 compatability issue in analytics/sensors
Hi,
While fine tuning my maven migration, I stumbled over a problem in the analytics/sensors modules.
As part of the build I am validating the classes for Java7 against the signatures of the Java 7 SDK. Here my plugin found an issue I thought was worth reporting.
In the class org.apache.edgent.analytics.sensors.Range almost at the end in the method toUnsignedString we are using Byte.toUnsignedInt, which is only available in Java 8 … there is no back-port for java 7 for this code. Eventually we should replace this with code that works on Java 7 too.
Chris
Re: Java7 compatability issue in analytics/sensors
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
So, I just pushed the finished andoid platform support.
What I did, was to move the android module from the root into the android platform. After that I had to refactor the code to be directly compilable with Java7.
Also, I ensured that as soon as someone wants to build the android platform he is informed that he also has to enable the java7 platform for it to work.
Next (and probably the final big step) would be to create assemblies for the 3 versions (java8, java7, android) which create binary distributions for all platforms.
Chris
Am 20.06.17, 08:22 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi Dale,
Ok … so to me it sounds like I should simply move the android directory to the android platform part of the build - So it’s only built, when building the android distribution. Then to remove it from the java7 platform. That should be all from a build point of view. I could duplicate the pom-only modules of java7 in android to give them a matching groupId, but the artifacts should be identical from the ones in java7 and they would add a lot of additional time for running the tests twice for java7. I think we shouldn’t do that.
What’s still missing is the (binary-) distributions themselves. While with Maven we would be ready to go to start building Edgent applications, when using Ant or other - more manual tools – a regular distribution package, bundling jars and scripts is probably preferable. This is handled by so-called “assemblies” … I would handle building android, java7 and java8 distributions with dedicated assembly modules.
Chris
PS: By the way … are there any other Edgent developers? It seems quite quiet here on the list, if you subtract my email-spam ;-)
Am 19.06.17, 22:58 schrieb "Dale LaBossiere" <dm...@gmail.com>:
> On Jun 19, 2017, at 4:20 PM, Christofer Dutz <ch...@c-ware.de> wrote:
> ...
> If you could write down exactly what the difference is between java8/7 and android, then I could probably finish that tomorrow.
Android is our j7 platform release with these changes:
- will not support due to no JMX support (ideally exclude artifacts for these)
edgent.api.developent
edgent.runtime.jmxcontrol
edgent.console.servlets
edgent.console.server
- adds
android.topology.jar
android.hardware.jar
— Dale
Re: Java7 compatability issue in analytics/sensors
Posted by Dale LaBossiere <dm...@gmail.com>.
> On Jun 21, 2017, at 8:06 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Ok I changed the android stuff to build with Java8 and to use retrolambda to produce a java7 version and ensure it’s valid java7 using the animalsniffer plugin. So that should be ok.
I noticed that. Thanks!
> The thing with empty jars is that if for example I would be building some application with maven targeting android, the application will contain one and the same artifact name twice … it would be edgent-connectors-common-1.2.0-SNAPSHOT.jar (the one from android) and edgent-connectors-common-1.2.0-SNAPSHOT.jar (the one from java7) … this will definitely cause problems.
Woops, I forgot the detail that they’ll have the same file names :-)
> I think I’ll go down the path of repacking the java7 jars as android jars and to deploy them with the android groupId. I know that we will be providing technically the same content twice, but I guess the benefits of this approach overweigh the disadvantages of the other options.
Sounds good.
At one point someone suggested that perhaps there should only be a single Edgent “runtime” (or core) jar for everything that’s currently in the binary release bundle’s “lib” directory - edgent.api, edgent.providers, edgent.runtime, edgent.spi. I don’t know if we’ll want to head in that direction at some point but I’ll ask: how possible / disruptive that would be later on with the mvn tooling?
— Dale
Re: Java7 compatability issue in analytics/sensors
Posted by Christofer Dutz <ch...@c-ware.de>.
Ok I changed the android stuff to build with Java8 and to use retrolambda to produce a java7 version and ensure it’s valid java7 using the animalsniffer plugin. So that should be ok.
The thing with empty jars is that if for example I would be building some application with maven targeting android, the application will contain one and the same artifact name twice … it would be edgent-connectors-common-1.2.0-SNAPSHOT.jar (the one from android) and edgent-connectors-common-1.2.0-SNAPSHOT.jar (the one from java7) … this will definitely cause problems.
I think I’ll go down the path of repacking the java7 jars as android jars and to deploy them with the android groupId. I know that we will be providing technically the same content twice, but I guess the benefits of this approach overweigh the disadvantages of the other options.
Chris
Am 20.06.17, 19:29 schrieb "Dale LaBossiere" <dm...@gmail.com>:
I ask things without understanding some of the implications/consequences :-)
> On Jun 20, 2017, at 11:03 AM, Christofer Dutz <ch...@c-ware.de> wrote:
> ...
> Well I could move the module back outside of the android module. The problem with this is, that as far as I understood it, it won’t work in the Java8 version and it is only used in the android distribution – which must be java7. The current version will definitely mislead people to try to use it with java8. I agree the workflow would be easier leaving it the way it was, but it’s more ambiguous.
Your understanding is correct and I also like it in its new location under platforms/android. I was hoping that under platforms/android, the build for .java files could be like what used to happen for j7 before you reworked things - i.e., in platforms/android for -Pplatform-android, inject retrolambda into the compile flow and then just compile as usual with j8. (generating things under target/android)
> Same with the “fake artifacts” which simply reference the java7 version … in this case you would have to use the “type” of “pom” for every artifact or we would be creating a load of empty jars that have a dependency to the java7 version. I don’t really like both cases … I’ll leave things as they are in the PR for now and keep that in mind. Who knows which solution will pop my mind when I’m doing something completely different ;-)
:-) I think I now understand the need for a fake-artifact to support use of dependency declaration like o.a.e.android:edgent-provider-iot
Hmm… my initial reaction is that “empty” o.a.e.android jars maybe don’t seem all that terrible in order to present that usage model to the user. It feels a bit better than having a copy of the j7 jar in the repo (with a different name/coordinate).
> I was calling the module “android.android” because it’s the android distribution and the android module of that. It does sound strange – I agree – eventually we could rename the module to make it sort of “android.sensors” or whatever would make sense.
>
> We could create convenience poms that contain all the dependencies to the platform they belong to … then all you would need to do, would be to create one pom-dependency to that and you would immediately get all jars that belong to that pulled in. But, as I said, I’ll let it hang for a little while … mabe I’ll come up with a different solution.
I can imagine such a total-platform-pom might be useful for a different use case, but I think for building apps, users will be better off declaring fine grained dependencies. Then when it comes time for them to create some minimal “bundle” needed to get their app&dependencies to a “device” where it can be run, mvn can help pull together only the needed pieces.
— Dale
Re: Java7 compatability issue in analytics/sensors
Posted by Dale LaBossiere <dm...@gmail.com>.
I ask things without understanding some of the implications/consequences :-)
> On Jun 20, 2017, at 11:03 AM, Christofer Dutz <ch...@c-ware.de> wrote:
> ...
> Well I could move the module back outside of the android module. The problem with this is, that as far as I understood it, it won’t work in the Java8 version and it is only used in the android distribution – which must be java7. The current version will definitely mislead people to try to use it with java8. I agree the workflow would be easier leaving it the way it was, but it’s more ambiguous.
Your understanding is correct and I also like it in its new location under platforms/android. I was hoping that under platforms/android, the build for .java files could be like what used to happen for j7 before you reworked things - i.e., in platforms/android for -Pplatform-android, inject retrolambda into the compile flow and then just compile as usual with j8. (generating things under target/android)
> Same with the “fake artifacts” which simply reference the java7 version … in this case you would have to use the “type” of “pom” for every artifact or we would be creating a load of empty jars that have a dependency to the java7 version. I don’t really like both cases … I’ll leave things as they are in the PR for now and keep that in mind. Who knows which solution will pop my mind when I’m doing something completely different ;-)
:-) I think I now understand the need for a fake-artifact to support use of dependency declaration like o.a.e.android:edgent-provider-iot
Hmm… my initial reaction is that “empty” o.a.e.android jars maybe don’t seem all that terrible in order to present that usage model to the user. It feels a bit better than having a copy of the j7 jar in the repo (with a different name/coordinate).
> I was calling the module “android.android” because it’s the android distribution and the android module of that. It does sound strange – I agree – eventually we could rename the module to make it sort of “android.sensors” or whatever would make sense.
>
> We could create convenience poms that contain all the dependencies to the platform they belong to … then all you would need to do, would be to create one pom-dependency to that and you would immediately get all jars that belong to that pulled in. But, as I said, I’ll let it hang for a little while … mabe I’ll come up with a different solution.
I can imagine such a total-platform-pom might be useful for a different use case, but I think for building apps, users will be better off declaring fine grained dependencies. Then when it comes time for them to create some minimal “bundle” needed to get their app&dependencies to a “device” where it can be run, mvn can help pull together only the needed pieces.
— Dale
Re: Java7 compatability issue in analytics/sensors
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Dale,
Well I could move the module back outside of the android module. The problem with this is, that as far as I understood it, it won’t work in the Java8 version and it is only used in the android distribution – which must be java7. The current version will definitely mislead people to try to use it with java8. I agree the workflow would be easier leaving it the way it was, but it’s more ambiguous.
Same with the “fake artifacts” which simply reference the java7 version … in this case you would have to use the “type” of “pom” for every artifact or we would be creating a load of empty jars that have a dependency to the java7 version. I don’t really like both cases … I’ll leave things as they are in the PR for now and keep that in mind. Who knows which solution will pop my mind when I’m doing something completely different ;-)
I was calling the module “android.android” because it’s the android distribution and the android module of that. It does sound strange – I agree – eventually we could rename the module to make it sort of “android.sensors” or whatever would make sense.
We could create convenience poms that contain all the dependencies to the platform they belong to … then all you would need to do, would be to create one pom-dependency to that and you would immediately get all jars that belong to that pulled in. But, as I said, I’ll let it hang for a little while … mabe I’ll come up with a different solution.
Chris
Am 20.06.17, 16:34 schrieb "Dale LaBossiere" <dm...@gmail.com>:
> On Jun 20, 2017, at 2:22 AM, Christofer Dutz <ch...@c-ware.de> wrote:
> ...
> Ok … so to me it sounds like I should simply move the android directory to the android platform part of the build - So it’s only built, when building the android distribution. Then to remove it from the java7 platform. That should be all from a build point of view. I could duplicate the pom-only modules of java7 in android to give them a matching groupId, but the artifacts should be identical from the ones in java7 and they would add a lot of additional time for running the tests twice for java7. I think we shouldn’t do that.
There seem to be two parts to this.
Not keen on the handling of the android specific modules. i.e., the project's development model is to freely use constrained-java8 (j7 + lambdas) everywhere and then have those modules processed w/retrolambda for j7&android targets. Makes sense, doesn’t it? Can’t we retain that dev model for the android specific modules?
Agree it’s nice to avoid duplicating the j7 jars.
I’m trying to imagine how an android app developer would consume Edgent for building their app. (not an environment I’m familiar with)
With the current PR state, I think they’d have to declare dependencies on the j7 components.
Imagine they’re using the IotProvider, the WIoTP connector and android-topology.
I think they’d have to declare the dependencies:
c.a.e.java7.providers:edgent-providers-iot:1.2.0-SNAPSHOT
c.a.e.java7.connectors:edgent-connectors-iotp:1.2.0-SNAPSHOT
c.a.e.android.android:edgent-android-topology:1.2.0-SNAPSHOT # must we have “android.android”?
Kinda feels like it would be better to have them strictly think in terms of only the Edgent android platform. No?
c.a.e.android.providers:edgent-providers-iot:1.2.0-SNAPSHOT
c.a.e.android.connectors:edgent-connectors-iotp:1.2.0-SNAPSHOT
c.a.e.android.android:edgent-android-topology:1.2.0-SNAPSHOT # must we have “android.android”?
there wouldn’t be a c.a.e.android.providers:edgent-providers-development since it’s not supported for android
Presumably, the android poms for the non-android-specific components would just declare a dependency on their corresponding j7 artifact.
As for android tests/testing, we don’t have any automated mechanism for doing that and we wouldn’t want a mvn build to run all the tests again :-)
I guess we mostly take comfort in knowing android's 99% the same (tested) j7 jars and currently only two small android-specific modules that were manually tested.
> What’s still missing is the (binary-) distributions themselves. While with Maven we would be ready to go to start building Edgent applications, when using
Looking fwd to that installment!
Having (presumably edgent-only) binary bundles will be nice / simplify our project. I’ll follow-on with separate questions for that.
> PS: By the way … are there any other Edgent developers? It seems quite quiet here on the list, if you subtract my email-spam ;-)
Yeah, 5 or so of my colleague contributors have been heads-down on some rather demanding / high priority projects.
More incentive for folks to join and grow the community :-) So glad you’re here!!!
Making Edgent easily consumable via maven-central will lower the bar for using it.
— Dale
Re: Java7 compatability issue in analytics/sensors
Posted by Dale LaBossiere <dm...@gmail.com>.
> On Jun 20, 2017, at 2:22 AM, Christofer Dutz <ch...@c-ware.de> wrote:
> ...
> Ok … so to me it sounds like I should simply move the android directory to the android platform part of the build - So it’s only built, when building the android distribution. Then to remove it from the java7 platform. That should be all from a build point of view. I could duplicate the pom-only modules of java7 in android to give them a matching groupId, but the artifacts should be identical from the ones in java7 and they would add a lot of additional time for running the tests twice for java7. I think we shouldn’t do that.
There seem to be two parts to this.
Not keen on the handling of the android specific modules. i.e., the project's development model is to freely use constrained-java8 (j7 + lambdas) everywhere and then have those modules processed w/retrolambda for j7&android targets. Makes sense, doesn’t it? Can’t we retain that dev model for the android specific modules?
Agree it’s nice to avoid duplicating the j7 jars.
I’m trying to imagine how an android app developer would consume Edgent for building their app. (not an environment I’m familiar with)
With the current PR state, I think they’d have to declare dependencies on the j7 components.
Imagine they’re using the IotProvider, the WIoTP connector and android-topology.
I think they’d have to declare the dependencies:
c.a.e.java7.providers:edgent-providers-iot:1.2.0-SNAPSHOT
c.a.e.java7.connectors:edgent-connectors-iotp:1.2.0-SNAPSHOT
c.a.e.android.android:edgent-android-topology:1.2.0-SNAPSHOT # must we have “android.android”?
Kinda feels like it would be better to have them strictly think in terms of only the Edgent android platform. No?
c.a.e.android.providers:edgent-providers-iot:1.2.0-SNAPSHOT
c.a.e.android.connectors:edgent-connectors-iotp:1.2.0-SNAPSHOT
c.a.e.android.android:edgent-android-topology:1.2.0-SNAPSHOT # must we have “android.android”?
there wouldn’t be a c.a.e.android.providers:edgent-providers-development since it’s not supported for android
Presumably, the android poms for the non-android-specific components would just declare a dependency on their corresponding j7 artifact.
As for android tests/testing, we don’t have any automated mechanism for doing that and we wouldn’t want a mvn build to run all the tests again :-)
I guess we mostly take comfort in knowing android's 99% the same (tested) j7 jars and currently only two small android-specific modules that were manually tested.
> What’s still missing is the (binary-) distributions themselves. While with Maven we would be ready to go to start building Edgent applications, when using
Looking fwd to that installment!
Having (presumably edgent-only) binary bundles will be nice / simplify our project. I’ll follow-on with separate questions for that.
> PS: By the way … are there any other Edgent developers? It seems quite quiet here on the list, if you subtract my email-spam ;-)
Yeah, 5 or so of my colleague contributors have been heads-down on some rather demanding / high priority projects.
More incentive for folks to join and grow the community :-) So glad you’re here!!!
Making Edgent easily consumable via maven-central will lower the bar for using it.
— Dale
Re: Java7 compatability issue in analytics/sensors
Posted by Dan Debrunner <dj...@debrunners.com>.
Same here, busy being distracted with other stuff.
Dan.
On Tuesday, June 20, 2017 7:20 AM, Susan Cline <ho...@pacbell.net> wrote:
We are here, we are here, we are here … Hi Chris, yes, there are. It’s a bit of a quiet time now, but we most certainly are.
Cheers,
Susan
> On Jun 19, 2017, at 11:22 PM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Chris
>
> PS: By the way … are there any other Edgent developers? It seems quite quiet here on the list, if you subtract my email-spam ;-)
>
>
>
>
Re: Java7 compatability issue in analytics/sensors
Posted by Susan Cline <ho...@pacbell.net>.
We are here, we are here, we are here … Hi Chris, yes, there are. It’s a bit of a quiet time now, but we most certainly are.
Cheers,
Susan
> On Jun 19, 2017, at 11:22 PM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Chris
>
> PS: By the way … are there any other Edgent developers? It seems quite quiet here on the list, if you subtract my email-spam ;-)
>
>
>
>
Re: Java7 compatability issue in analytics/sensors
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Dale,
Ok … so to me it sounds like I should simply move the android directory to the android platform part of the build - So it’s only built, when building the android distribution. Then to remove it from the java7 platform. That should be all from a build point of view. I could duplicate the pom-only modules of java7 in android to give them a matching groupId, but the artifacts should be identical from the ones in java7 and they would add a lot of additional time for running the tests twice for java7. I think we shouldn’t do that.
What’s still missing is the (binary-) distributions themselves. While with Maven we would be ready to go to start building Edgent applications, when using Ant or other - more manual tools – a regular distribution package, bundling jars and scripts is probably preferable. This is handled by so-called “assemblies” … I would handle building android, java7 and java8 distributions with dedicated assembly modules.
Chris
PS: By the way … are there any other Edgent developers? It seems quite quiet here on the list, if you subtract my email-spam ;-)
Am 19.06.17, 22:58 schrieb "Dale LaBossiere" <dm...@gmail.com>:
> On Jun 19, 2017, at 4:20 PM, Christofer Dutz <ch...@c-ware.de> wrote:
> ...
> If you could write down exactly what the difference is between java8/7 and android, then I could probably finish that tomorrow.
Android is our j7 platform release with these changes:
- will not support due to no JMX support (ideally exclude artifacts for these)
edgent.api.developent
edgent.runtime.jmxcontrol
edgent.console.servlets
edgent.console.server
- adds
android.topology.jar
android.hardware.jar
— Dale
Re: Java7 compatability issue in analytics/sensors
Posted by Dale LaBossiere <dm...@gmail.com>.
> On Jun 19, 2017, at 4:20 PM, Christofer Dutz <ch...@c-ware.de> wrote:
> ...
> If you could write down exactly what the difference is between java8/7 and android, then I could probably finish that tomorrow.
Android is our j7 platform release with these changes:
- will not support due to no JMX support (ideally exclude artifacts for these)
edgent.api.developent
edgent.runtime.jmxcontrol
edgent.console.servlets
edgent.console.server
- adds
android.topology.jar
android.hardware.jar
— Dale
Re: Java7 compatability issue in analytics/sensors
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Dale,
Glad it seems to be working :-)
If you could write down exactly what the difference is between java8/7 and android, then I could probably finish that tomorrow.
Chris
Von meinem Samsung Galaxy Smartphone gesendet.
-------- Ursprüngliche Nachricht --------
Von: Dale LaBossiere <dm...@gmail.com>
Datum: 19.06.17 21:01 (GMT+01:00)
An: dev@edgent.apache.org
Betreff: Re: Java7 compatability issue in analytics/sensors
Success! Now I need to spend some time understanding the results :-) questions to follow
$ mvn -t toolchains-local.xml -Djava8.home=$JAVA_HOME clean install site:site -Pplatform-java7,platform-android
…
[INFO] Apache Edgent (Java 7): Test: SVT .................. SUCCESS [ 57.896 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 59:17 min
[INFO] Finished at: 2017-06-19T14:23:59-04:00
[INFO] Final Memory: 136M/969M
[INFO] ------------------------------------------------------------------------
> On Jun 19, 2017, at 12:10 PM, Dale LaBossiere <dm...@gmail.com> wrote:
>
> Hmm… changed the CLI options order to match that in .travis.yml and it’s working now.
> I’ll report once everything has run.
>
>> On Jun 19, 2017, at 12:05 PM, Dale LaBossiere <dml.apache@gmail.com <ma...@gmail.com>> wrote:
>>
>> Did you commit&push all of your changes?
>> I pulled the latest PR-309 stuff. Created my toolchains-local.xml (copied/edited toolchains-travis.xml)
>> and then...
>>
>>> On Jun 19, 2017, at 10:13 AM, Christofer Dutz <christofer.dutz@c-ware.de <ma...@c-ware.de>> wrote:
>>>
>>> mvn –Pplatform-java7,platform-android –Djava8.home={JAVA8_HOME} –t toolchains-local.xml clean install
>>
>> $ mvn –Pplatform-java7 –Djava8.home=$JAVA_HOME –t toolchains-local.xml clean install
>> [ERROR] Unknown lifecycle phase "–Pplatform-java7". You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>
>> ...
>
Re: Java7 compatability issue in analytics/sensors
Posted by Dale LaBossiere <dm...@gmail.com>.
Success! Now I need to spend some time understanding the results :-) questions to follow
$ mvn -t toolchains-local.xml -Djava8.home=$JAVA_HOME clean install site:site -Pplatform-java7,platform-android
…
[INFO] Apache Edgent (Java 7): Test: SVT .................. SUCCESS [ 57.896 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 59:17 min
[INFO] Finished at: 2017-06-19T14:23:59-04:00
[INFO] Final Memory: 136M/969M
[INFO] ------------------------------------------------------------------------
> On Jun 19, 2017, at 12:10 PM, Dale LaBossiere <dm...@gmail.com> wrote:
>
> Hmm… changed the CLI options order to match that in .travis.yml and it’s working now.
> I’ll report once everything has run.
>
>> On Jun 19, 2017, at 12:05 PM, Dale LaBossiere <dml.apache@gmail.com <ma...@gmail.com>> wrote:
>>
>> Did you commit&push all of your changes?
>> I pulled the latest PR-309 stuff. Created my toolchains-local.xml (copied/edited toolchains-travis.xml)
>> and then...
>>
>>> On Jun 19, 2017, at 10:13 AM, Christofer Dutz <christofer.dutz@c-ware.de <ma...@c-ware.de>> wrote:
>>>
>>> mvn –Pplatform-java7,platform-android –Djava8.home={JAVA8_HOME} –t toolchains-local.xml clean install
>>
>> $ mvn –Pplatform-java7 –Djava8.home=$JAVA_HOME –t toolchains-local.xml clean install
>> [ERROR] Unknown lifecycle phase "–Pplatform-java7". You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>
>> ...
>
Re: Java7 compatability issue in analytics/sensors
Posted by Dale LaBossiere <dm...@gmail.com>.
Hmm… changed the CLI options order to match that in .travis.yml and it’s working now.
I’ll report once everything has run.
> On Jun 19, 2017, at 12:05 PM, Dale LaBossiere <dm...@gmail.com> wrote:
>
> Did you commit&push all of your changes?
> I pulled the latest PR-309 stuff. Created my toolchains-local.xml (copied/edited toolchains-travis.xml)
> and then...
>
>> On Jun 19, 2017, at 10:13 AM, Christofer Dutz <christofer.dutz@c-ware.de <ma...@c-ware.de>> wrote:
>>
>> mvn –Pplatform-java7,platform-android –Djava8.home={JAVA8_HOME} –t toolchains-local.xml clean install
>
> $ mvn –Pplatform-java7 –Djava8.home=$JAVA_HOME –t toolchains-local.xml clean install
> [ERROR] Unknown lifecycle phase "–Pplatform-java7". You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>
> ...
Re: Java7 compatability issue in analytics/sensors
Posted by Dale LaBossiere <dm...@gmail.com>.
Did you commit&push all of your changes?
I pulled the latest PR-309 stuff. Created my toolchains-local.xml (copied/edited toolchains-travis.xml)
and then...
> On Jun 19, 2017, at 10:13 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> mvn –Pplatform-java7,platform-android –Djava8.home={JAVA8_HOME} –t toolchains-local.xml clean install
$ mvn –Pplatform-java7 –Djava8.home=$JAVA_HOME –t toolchains-local.xml clean install
[ERROR] Unknown lifecycle phase "–Pplatform-java7". You must specify a valid lifecycle phase or a goal in the format <plugin-prefix>:<goal> or <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal>
...
Re: Java7 compatability issue in analytics/sensors
Posted by Christofer Dutz <ch...@c-ware.de>.
Ok guys … now some MAJOR update :-)
I managed to setup a build that build all modules with Java8, if the profile “platform-java7” is enabled, also Java7 versions are produced by unpacking the Java8 versions in some pom-only modules, applying retrolambda there and then running all unit- and integration-tests with Java7. The cool thing is, I didn’t port only the ones build for java7 in the past, but all edgent modules and fixed the ones that were having problems (I added a helper that does the same as the Java8 extensions did). Now all modules except some examples are also available on Java7 (I had do disable some Tests though, as they were using Java8 APIs, but this should be fixable quite easily). The cool thing … all should also work on Travis too (I found a place where the Java paths were documented … see the .travis.yml).
The build of Java8 should work out of the box on any machine with Maven and Java8, if you want to build the Java7 versions, you need to activate the profile “platform-java7” and provide a so-called toolchain (either you create a toolchain.xml in your .m2 directory or you create a file elsewhere and pass that files path in with the “-t” command-line option). As retrolambda needs Java8 to run, you also need to provide a property: “java8.home” that points to your Java8 home directory.
Regarding the Android package, I would start working on this next. If the “android” modules are only used in the “android” platform, I would suggest building a similar structure for android as for Java7 and to move the real android modules into that directory. Then they wouldn’t be part of the Java8 and Java7 package and be included only in the android package.
You can use the toolchains-travis.xml file as a template to create your own. I added an git exclusion for toolchains-local.xml. So, if you just copy that to toolchains-local.xml and adjust your java-home paths inside, you should be able to build everything with the following command:
mvn –Pplatform-java7,platform-android –Djava8.home={JAVA8_HOME} –t toolchains-local.xml clean install
Hope it works on your machines too … if not I’ll handle the problems as soon as possible.
Chris
Am 19.06.17, 15:20 schrieb "Dale LaBossiere" <dm...@gmail.com>:
Nice catch!
I created https://issues.apache.org/jira/browse/EDGENT-423
— Dale
> On Jun 18, 2017, at 8:04 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> While fine tuning my maven migration, I stumbled over a problem in the analytics/sensors modules.
> As part of the build I am validating the classes for Java7 against the signatures of the Java 7 SDK. Here my plugin found an issue I thought was worth reporting.
> In the class org.apache.edgent.analytics.sensors.Range almost at the end in the method toUnsignedString we are using Byte.toUnsignedInt, which is only available in Java 8 … there is no back-port for java 7 for this code. Eventually we should replace this with code that works on Java 7 too.
Re: Java7 compatability issue in analytics/sensors
Posted by Dale LaBossiere <dm...@gmail.com>.
Nice catch!
I created https://issues.apache.org/jira/browse/EDGENT-423
— Dale
> On Jun 18, 2017, at 8:04 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> While fine tuning my maven migration, I stumbled over a problem in the analytics/sensors modules.
> As part of the build I am validating the classes for Java7 against the signatures of the Java 7 SDK. Here my plugin found an issue I thought was worth reporting.
> In the class org.apache.edgent.analytics.sensors.Range almost at the end in the method toUnsignedString we are using Byte.toUnsignedInt, which is only available in Java 8 … there is no back-port for java 7 for this code. Eventually we should replace this with code that works on Java 7 too.