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" <dml.apa...@gmail.com>:
I ask things without understanding some of the implications/consequences :-)
> On Jun 20, 2017, at 11:03 AM, Christofer Dutz <christofer.d...@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
