> On Jun 27, 2017, at 3:24 AM, Christofer Dutz <christofer.d...@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
