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
