Regarding the assembly, The way the build is currently setup, we would be distributing jars via Apaches Maven Repo which is synced with Maven Central. So, everyone using maven would easily be able to use these. But if someone isn’t using Maven or Ivy with a Maven resolver or Gradle with a Maven resolver, they would have to either build Edgent locally or manually download all the jars from Maven Central. I don’t think people would like that. I know of quite a few that would be used to creating an Eclipse project with a libs directory, which they simply copy a set of jars into. For that type of user, a binary distribution would be beneficial.
Regarding the Jar with jars inside … seems I could use the assembly plugin for that, it’s jar-with-dependencies goal seems to be for creating exactly such a thing. I’ll check that out right away. Chris Am 27.06.17, 15:15 schrieb "Dale LaBossiere" <[email protected]>: > On Jun 27, 2017, at 3:24 AM, Christofer Dutz <[email protected]> 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
