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 <[email protected]>
> 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.
