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 Tue, 27 Jun 2017 14:24:24 GMT
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.


Am 27.06.17, 15:28 schrieb "Christofer Dutz" <christofer.dutz@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.
    Am 27.06.17, 15:15 schrieb "Dale LaBossiere" <dml.apache@gmail.com>:
        > On Jun 27, 2017, at 3:24 AM, Christofer Dutz <christofer.dutz@c-ware.de>
        > 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
        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
        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

View raw message