> On Sep 18, 2017, at 3:40 PM, John D. Ament <johndam...@apache.org> wrote:
>
> On Mon, Sep 18, 2017 at 3:25 PM Dale LaBossiere <dml.apa...@gmail.com>
> wrote:
>
>> I pulled the latest pr309 changes and generated a binary bundle using “mvn
>> package -Pdistribution”. I see the external dependencies are now present
>> in an ext directory in the bundle. Yay! :-)
>>
>
> If you're using maven, and we have the proper transitive dependencies
> listed, why is this useful?
It’s not useful in that case.
Quite frankly I think we have the other cases where a similar
capability/content is needed already covered (though similar issues arise):
- the user is developing their Edgent app with tooling that isn’t integrated
with maven repos and just needs all the released jars
we supply a get-edgent-jars.sh that instead of building Edgent jars
retrieves them and their deps from a maven repo
the user can then do what they want with those jars - e.g. just setup
classpath to them
- to deploy Edgent runtime components to an edge device (lacking maven repo
connectivity) for execution of their Edgent app
again they can use that get-edgent-jars.sh script and then create their
own bundle containing everything and convey that to their device.
alternatively, they can:
- build their app with maven and create an uber jar containing
their app and dependent Edgent runtime deps, etc
- or use a package-app.sh we provide that creates a tarball
containing their app and dependent Edgent runtime deps, etc
What sort of “documentation” do we need to provide the user telling them what
external runtime dependencies Edgent has?
That documentation might also be referred to by the get-edgent-jars.sh and
package-app.sh scripts.
How do other projects address telling its users this info this when they’re not
providing license/notice content for their external deps because they’re not
releasing binary bundles containing them? Pointers to specific content pls.
>> Clarification for others, the generated zip/tarball will NOT be released
>> by the ASF. This bundle is something that users can build for themselves
>> for certain use cases. With that in mind...
>>
>> There’s a LICENSE and NOTICE file present in the bundle. Right now the
>> content of each is for a released “source bundle” context - i.e. no mention
>> of any of the bundled external deps content.
>>
>> Can we simply exclude these inaccurate files? I assume we can since this
>> isn’t a released artifact. Mentor input helpful here. Note, each bundled
>> Edgent jar has its own LICENSE/NOTICE in its manifest.
>>
>>
> No. While the binary release is a convenience, it should be accurate. The
> LICENSE/NOTICE should reflect the contents of the binary bundle.
That would suck :-) Avoiding that is part of the reason to *cease releasing* a
binary bundle containing external deps.
Of course we can cease documenting this “-Pdistribution”.
— Dale
