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" <dml.apa...@gmail.com>:
> On Jun 20, 2017, at 2:22 AM, Christofer Dutz <christofer.d...@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
