tl;dr : I would prefer not to add another tarball as part of our "official" releases, but I'd be in favor of a blog instructions, script, or build profile, which users could read/execute/activate to create a client-centric package.
I've long believed that supporting different downstream packaging scenarios should be prioritized over upstream binary packaging. I have argued in favor of removing our current tarball entirely, while supporting efforts to enable downstream packaging by modularizing the server code, supporting a client-API jar (future work), and decoupling code from launch scripts. I think we should continue to do these kinds of improvements to support different packaging scenarios downstream, but I'd prefer to avoid additional "official" binary releases. Rather than provide additional packages, I'd prefer to work with downstream to make the source more "packagable" to suit the needs of these downstream vendor/community packagers. One way we can do that here is by either documenting what would be needed in a client-centric package, or by providing a script or build profile to create it from source, so that your $dayjob or any other downstream packager doesn't have to figure that out from scratch. On Thu, Jan 4, 2018 at 7:17 PM Josh Elser <josh.el...@gmail.com> wrote: > Hi, > > $dayjob presented me with a request to break up the current tarball into > two: one suitable for "users" and another for the Accumulo services. The > ultimate goal is to make upgrade scenarios a bit easier by having client > and server centric packaging. > > The "client" tarball would be something suitable for most users > providing the ability to do things like: > > * Launch a java app against Accumulo > * Launch a MapReduce job against Accumulo > * Launch the Accumulo shell > > Essentially, the client tarball is just a pared down version of our > "current" tarball and the server-tarball is likely equivalent to our > "current" tarball (given that we have little code which would be > considered client-only). > > Obviously, there are many ways to go about this. If there is buy-in from > other folks, adding some new assembly descriptors and making it a part > of the Maven build (perhaps, optionally generated) would be the easiest > in terms of maintenance. However, I don't want to push for that if it's > just going to be ignored by folks. I'll be creating something to support > this one way or another. > > Any thoughts/opinions? Would this have any value to other folks? > > - Josh >
