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 Wed, 21 Jun 2017 12:06:11 GMT
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.apache@gmail.com>:

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

Mime
View raw message