The examples are something I’m currently working on …
They will work differently than right now (definitely no classpath in the
Manifest).
In Maven there are several ways to do this … I’ll have to dig into how the
samples are run to find out how to do it in an ideal way.
I have also seen the current way things are bundled in the binaries … I also
think changing this would be a good idea as the way it is handled now forces
the directory structure on the users. I wouldn’t like to do that. I would much
more prefer a directory with edgent artifacts and an “ext” directory containing
external dependencies and passing in an individual classpath to the
applications. … but as I said … I’ll have to dig a little more into the
examples. First I’ll finish the android modules.
Chris
Am 21.06.17, 15:21 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
Today (pre-mvn), Edgent has a number of sample programs under /samples.
They are pre-built and included in the binary release bundle as a collection of
jars edgent.samples.{apps,…}.jar and are run via scripts under /scripts.
Your thoughts on samples in the new world? As things are now, the scripts
don’t work. They presume a (binary release) directory tree where all of the
edgent jars reside in a particular layout. They also use the
non-version-labeled-name form of the Edgent jars.
At a high level there's “how do I build and package/assemble my app for
execution on a device, and run my app”. Edgent, mostly, isn’t in the business
of how to package the bits or get them to / install them on the device.
Today’s binary release bundle only addresses the “run” part of that. The
binary bundle includes the sample sources but doesn’t include tooling/scripts
to build them. How lame is that? :-)
In my mind it’s NOT a hard requirement that we (a) provide pre-built
samples, nor (b) provide an Edgent binary release bundle (containing all the
Edgent jars and deps). I think it’s just the opposite :-)
I’ll stop there just to kickoff this thread.
— Dale
