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 Tue, 27 Jun 2017 13:15:37 GMT

> On Jun 27, 2017, at 3:24 AM, Christofer Dutz <christofer.dutz@c-ware.de> wrote:
> 
> Hi Dale,
> 
> Well it would be possible to reduce the classes in the uber-jars to only the used classes,
but this usually causes issues as soon as there’s reflection in the software somewhere.
Sorry for the confusion.  I wasn’t asking for that sort of additional uber-included classes
filtering (an interesting idea; I seem to recall some tool that can do that).  Rather, in
Eclipse, "<project> > Export … > Java > Runnable JAR > package required
libraries into generated JAR" creates a jar that includes the actual dependent jars, not their
extracted classes.  The jar also includes a tiny “Jar in Jar” loader which is the “main-class”.
 Seems very clean/nice.  Was interested in your opinion on it.

> ...
> To help people getting started, I would rather suggest using Maven archetypes. ...
I had a feeling you might suggest that :-)  Works for me.

> I could move the uber-jar generation config into a separate profile which the user must
manually activate …
Right now I don’t have a strong opinion on that.  I had mentioned it in case it made it
easier to consider/accept alternative ideas like per-sample-projects/poms.  If you still think
per-sample-poms are best avoided for other reasons then OK, stick with the current structure
and uber generation scheme.

> So, on my to-do list now I have noted:
> - Move the uber-jar configuration into a profile
see above.  your call.
> - No longer make the main Edgent build also build the examples
sounds good (I guess you agreed with the rationale)
> - Create an example archetype based on the Hello World example
sounds good
> - Create an assembly for a binary distribution
I’m unclear on the full implications of that. I’m now of the, perhaps incorrect?, opinion
that we should NOT distribute binary distribution tgz bundles.  Are we on the same page? 

If this assembly/tgz is just something that someone can run/create if they need a way to access
the Edgent jars and deps outside of the repo then I get that.

I’m imagining a tool that you can point at component in a repo and it will do the jar copying/bundling.
 No need for any other sources, etc.
e.g., if I identify edgent-parent:1.2.0-SNAPSHOT it creates a bundle with all of the jars/deps
of that ss/release.  extra credit? - If I identify edgent-connectors-mqtt:1.2.0-SNAPSHOT the
generated bundle only includes that subset of jars/deps.  Does that make sense to you?  There’s
nothing edgent specific about such a tool; maybe one already exists?

— Dale


Mime
View raw message