edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale LaBossiere <dml.apa...@gmail.com>
Subject Re: mvn, Edgent samples, and the broader app development and packaging topic
Date Fri, 23 Jun 2017 16:40:00 GMT
Chris, thanks for the update.

First, and most importantly, I hope you have a great weekend! :-)

At a high level, I was thinking there’s value in a couple of build/packaging approaches.
- create a totally self contained executable-jar
- something that supports a model where a device may have a separately installed and managed
Edgent that any/all apps on the device use.
- a twist on the former where just the Edgent jars needed by the app are copied to a local
dir and bundled up

For the samples:
- we should provide tooling that supports all of the above
- the tooling should be able to generate j8, j7, or android
- it might be good if each sample had its own pom.xml / generated .jar rather than one bit
one
- the user should be able to easily run a CLI-built sample locally (no need to actually copy
things to a “device”)
- the user should be able to easily import a sample into a maven-integrated IDE and build
and run it
- no need to include/demo building without mvn tooling

Expanding on that...

- create a totally self contained executable-jar
  This is what you get from Eclipse when selecting a maven-based Edgent app project
  and doing Export… > Runnable JAR > “package required libraries into jar”.
  The user just gets that jar onto their device and a “java -jar <the-jar>” and
starts their app.  
  Very simple.  No additional work to get/install Edgent.  
  Only the app’s dependent Edgent jars (and deps) are included in the jar - i.e., it’s
~minimal/
  This is perhaps an actual production mode of use for simple "single Edgent app" devices.

- something that supports a model where a device may have a separately installed and managed
Edgent that any/all apps on the device use.
  This has some characteristics that you mentioned. 
  I’m not sure how important it is to separate the Edgent vs “ext” jars/directories.
  Unless there’s a compelling reason to do so, and it’s really not that much effort/complication,
I think I’d just use a single dir for all :-)

  Provide some cmd that populates a local dir with *all* the Edgent jars and their deps (the
analog of a full Edgent binary bundle).
  Provide an edgent-classpath.sh cmd that returns a CLASSPATH value that simply includes everything
in that dir
  Bundle up that that local dir and the edgent-classpath script.
  The user needs to get bundle onto the device and unpack it.
  Note, building the app wouldn’t use this dir/bundle, it’s just for deployment.
 (well, a user that had non-maven-intergrated app built tooling could use the generated dir)

  Create a jar containing just the Edgent app; make its manifest have and entry for main class.
  Provide a run-app.sh script that essentially just does:
	export CLASSPATH=`edgent-classpath.sh` # user can always augment this stmt if they have other
things to add
        java -jar <the-edgent-app-jar>   # start the app
  Bundle up that jar and the run script.
  The user needs to get bundle onto the device and unpack it.
  The app is started via “./run-app.sh”

- a twist on the former where just the Edgent jars needed by the app are copied to a local
dir and bundled up
  This leverages mvn to create the ~minimal set of Edgent jars and their deps needed by the
app.
  The dir contains what “mvn dependency:copy-dependency” creates.
  This seems to be the same thing as created by Eclipse   <project> > Export …
> Runnable JAR > “copy required jars into sub-folder”.
  (Note, unlike that Eclipse export, the app’s jar would NOT contain a manifest classpath.
 The edgent-classpath.sh scheme would be used.)
  The dir can be bundled up and brought to the device and unpacked.

Hope that’s all mostly making sense / sensible :-)

— Dale

> On Jun 23, 2017, at 3:39 AM, Christofer Dutz <christofer.dutz@c-ware.de> wrote:
> ...Just a little on what I’m currently working on. 
> The maven dependency plugin is able to create an xml representation of a projects dependencies.
I’m currently trying to create a build that pipes that through an XSLT and hereby creates
a start-script for the example they are built in. This will refer to a directory structure
in which all Edgent artifacts are output into one directory and all non-edgent dependencies
to an “ext” subdirectory within that lib directory. The scripts should be able to correctly
build an applications classpath based on that.


Mime
View raw message