edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: Java7 compatability issue in analytics/sensors
Date Tue, 20 Jun 2017 15:03:38 GMT
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.


Am 20.06.17, 16:34 schrieb "Dale LaBossiere" <dml.apache@gmail.com>:

    > 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.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.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

View raw message