Details
-
Wish
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
Edgent has released 3 sets of jars, one for each platform: java8, java7, android.
Each platform-set consists of approximately 40 jars.
The new world of releasing Edgent jars to Maven Central doesn't change the above but it now seems more in your face. Reducing the number of jars that users deal with seems desirable.
Re: per-platform-jars
================
Presumably we could have just released a single J7-based set of jars (including the android-specific jars in that) that would be used on J8,J7 and Android. I'm pretty sure J8 clients can use J8-lambdas and link and run against the J7 jars.
That said, it sort of feels better to have a real J8 set for J8 execution environments.
As for J7/Android, do we really need separate sets for both? To clarify, the Android set is just a copy of the J7-based set, minus a couple J7-only things (like the console, JMX, development provider) plus a couple of Android-specific jars (edgent-android-hardware, edgent-android-topology). Would it be bad if we combined them to a superset of the two? The documentation would address that a couple are J7-only and a couple are Android-only.
So it seems we could reduce to either:
- a single J7-based set
- a J8-based set and a J7-based set
Thoughts on that?
I don't think it should affect the decision for the above but the complexity of Edgent maven-based build tooling would be lessened accordingly - i.e., each platform/set has its own set of 40+ poms so we'd be able to get rid of some.
Re: 40-jars-per-set
===============
The large number of jars was fallout from a "micro-service" point of view - package everything as small as possible and let the developer / deployment environment include only what's needed in order to lessen (not fully minimize) the size of an deployment installation.
Some of the jars / features are optional - e.g., what connectors the app uses, what analytics the app uses. And the Edgent console is generally utilized only in a development-only context - not imagined to be deployed to a production device execution context.
The core of the Edgent runtime itself is partitioned to facilitate alternate implementations. At least at this time there is only a single implementation and there aren't any discussions, etc of that situation changing any time soon. These packages represent about 13 jars - the packages:
- api. {execution,function,graph,oplet,topology,window}
- spi. {graph,topology}
- runtime. {appservice,etiao,jmxcontrol,jobregistry,jsoncontrol}
It seems those could reasonably be bundled into a single "edgent-core" jar.
There are three provider implementations: direct,iot,development.
I'm not so sure about bundling them in a single jar (particularly development) or in the "edgent-core" jar.
It seems appropriate to keep the connectors and analytics "optional" packages packaged as they are today. That still leaves a fair number of jars (there would still be e.g., 15 for different connectors, 2 for analytics, 2 for apps, 2 for utils, 1 for console). These "optional" packages are the ones that have significant 3rd-party jar dependencies.
Thinking out loud...
If we only had to support Edgent application "uber-jars" as a deployment packaging scheme then we could bundle all of Edgent in a single jar - the uber-jar construction processing incorporates only "referenced" classes into the uber-jar. Uber-jars aren't practical as "the only" deployment model.
I suppose an alternative could be to supply (or utilize) some other tooling that could select "desired" Edgent packages (e.g., that multiple applications on a device might use) from a single Edgent jar and compose them into a "custom" Edgent jar for deployment purposes, thereby enabling release of only a single Edgent jar? Note, the deployment also needs to include any transitive 3rd-party dependency jars.
Thoughts on initially reducing the number of "edgent-core" jars, etc?