edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: mvn, Edgent samples, and the broader app development and packaging topic
Date Sun, 25 Jun 2017 13:44:14 GMT
Hi Dale,

I just paused my work on the classpath generation and simply added the maven-shade-plugin
which creates uber-jars, which produces jars that contain not only the modules content, but
also includes all dependencies into one big fat jar … I also added a sample start script
to the topology project. 

Would this do as a startging point?

Regarding your points:
First section:
- Well it now produces an additional self-contained jar additionally
- When using Maven you usually don’t use this model of having something installed, it is
possible using the “system” scope in dependencies and providing the systemPath element
pointing to some “${edgent.home}/my-edgent-lib-1.2.0.jar” but that wouldn’t be good
style. Usually the single-source for the artifacts would be the maven local repo on that device.
Second section:
- The shade plugin would work on all platforms. All I would have to do, is to add the plugin
configuration to the other platforms.
- Having jars for each example would require splitting them up into separate maven modules.
I don’t think that’s a good idea. I’d prefer a start script that lets the user choose
the sample to run. I know this would require adjusting the start script whenever a sample
is added/deleted/changed, but it would reduce the number of these super-fat uber jars.
- If the user ran the maven build (mvn clean package) any user would be able to run the samples.
- IntelliJ was able to immediately run every example I tried, even before the shade plugin
was added and I think Eclipse this should also work.

Regarding the binary distribution. I think we should put non-edgent libs in a separate directory.
Mainly because this way we clearly draw a line to what’s our stuff and which is from others
(even if these “others” are also ASF projects)

Chris

Am 23.06.17, 18:40 schrieb "Dale LaBossiere" <dml.apache@gmail.com>:

    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