Forget the assembly jar-with-dependencies goal … it produces the same output as
the shade plugin :-(
I think the packaging type you are looking for is like that of Spring Boot
applications. I’ll try to find out if this is possible without spring boot.
Chris
Am 27.06.17, 15:28 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
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" <dml.apa...@gmail.com>:
> 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
