edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dale LaBossiere (JIRA)" <j...@apache.org>
Subject [jira] [Created] (EDGENT-437) Reduce the number of Edgent jars?
Date Mon, 20 Nov 2017 17:52:00 GMT
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)

Mime
View raw message