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