Dale LaBossiere created EDGENT-437:
--------------------------------------
Summary: Reduce the number of Edgent jars?
Key: EDGENT-437
URL: https://issues.apache.org/jira/browse/EDGENT-437
Project: Edgent
Issue Type: Wish
Components: Miscellaneous
Reporter: Dale LaBossiere
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?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
