edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale LaBossiere <dml.apa...@gmail.com>
Subject Re: Java7 compatability issue in analytics/sensors
Date Tue, 20 Jun 2017 14:34:13 GMT

> On Jun 20, 2017, at 2:22 AM, Christofer Dutz <christofer.dutz@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
Mime
View raw message