On Fri, Jan 5, 2018 at 10:01 AM Josh Elser <[email protected]> wrote:
> I'd be worried about advertising something that we're not treating as > official as it would languish (unless we create tests that can validate > the result for us). > > My concern is "packagability". That's what I'm concerned about languishing. I see no reason why either should, though. As for including it as another "convenience binary" with our releases, I'm not sold on that yet, but I'm not entirely against it either. I'll withhold judgment until we have something concrete to review. > Thanks for the input. > > On 1/4/18 7:43 PM, Christopher wrote: > > 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 <[email protected]> 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 > >> > > >
