accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Is C++ code still part of 1.5 release?
Date Sat, 18 May 2013 02:39:19 GMT
Yeah, the inclusion of the binary in the source tarball was an
oversight that has been corrected. If you're interested in the
details:

We require the javadocs to be built aggregately, because we ship them
for the monitor. So, we need them already built for the package phase.
However, they can't be built until the children are compiled, so we
execute similar to:
mvn clean compile javadoc:aggregate package -P
docs,apache-release,native, etc...

This means that the packaging of the source assembly either gets
executed after the the binaries have been built, (or, if we override
and bind the source assembly to an earlier phase, it gets executed
twice) and ends up picking them up (this is a side-effect of what I
intend to fix with ACCUMULO-935 (one of the many issues I intend to
fix with that ticket)). I have put in a little bit of messiness to get
it to work right now (bound to the validate phase to run before
everything, and uses exec plugin to mv with --no-clobber flag, so I
keep the earlier one). I may have a cleaner workaround in mind, but
this is working for now.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Fri, May 17, 2013 at 10:11 PM, Adam Fuchs <afuchs@apache.org> wrote:
> I stand corrected. Thanks for the link, Billie. Looks like we should also
> remove the .so file from the -src.tar.gz lest we risk having our project
> deleted.
>
> Adam
>
>
>
> On Fri, May 17, 2013 at 5:39 PM, Billie Rinaldi <billie.rinaldi@gmail.com>wrote:
>
>> On May 17, 2013 5:13 PM, "Adam Fuchs" <afuchs@apache.org> wrote:
>> >
>> > I'm with Michael on this one. We should really only be releasing one
>> > package that has all of the source and built binaries. IMO the
>> > interpretation of http://www.apache.org/dev/release.html that we must
>> have
>> > a source-only release is overly restrictive. "Every ASF release must
>> > contain a source package, which must be sufficient for a user to build
>> and
>> > test the release provided they have access to the appropriate platform
>> and
>> > tools." can also be interpreted such that a single package with source
>> and
>> > binaries meets the release requirement.
>>
>> In lieu of ranting myself, I'll point you here: http://s.apache.org/nnN
>>
>> Billie
>>
>> >
>> > I have seen a lot of confusion about people trying to build the accumulo
>> > code when they really don't need to, and they often run into trouble when
>> > their environment is not set up for java development. Having multiple
>> > .tar.gz artifacts adds to this confusion. When we reordered the download
>> > page so that the -dist.tar.gz came before the -src.tar.gz those types of
>> > questions dropped dramatically on the mailing list. The existence of the
>> > -src.tar.gz creates confusion on its own (although our README doesn't
>> help).
>> >
>> > Adam
>> >
>> >
>> >
>> > On Fri, May 17, 2013 at 4:00 PM, Michael Berman <mberman@sqrrl.com>
>> wrote:
>> >
>> > > As an Accumulo user, the thing I want most is a single package that
>> > > contains the things I need to set up a running instance.  I don't want
>> to
>> > > build the whole thing from source, but I am happy to build the native
>> map,
>> > > unless every possible architecture is going to be distributed.  I
>> really
>> > > don't care at all whether the tarball name ends in "-bin" or "-package"
>> or
>> > > "-theStuffYouWant".  If the only reason not to include the native map
>> > > sources in the binary release is because the filename ends in -bin, why
>> not
>> > > just call it accumulo-1.5.0.tar.gz?
>> > >
>> > >
>> > > On Fri, May 17, 2013 at 3:51 PM, John Vines <vines@apache.org> wrote:
>> > >
>> > > > If we're going to be making binary releases that have no other
>> mechanism
>> > > > for creating the native libraries, then we should probably cut a few
>> > > > different binary releases for x86, amd64, and darwin at the very
>> least.
>> > > >
>> > > > Sent from my phone, please pardon the typos and brevity.
>> > > > On May 17, 2013 12:36 PM, "Josh Elser" <josh.elser@gmail.com>
wrote:
>> > > >
>> > > > > I'm happy we're stating our opinions here, but there are also
two
>> other
>> > > > > people who believe that the bin should not contain it. That's
nice
>> that
>> > > > you
>> > > > > want source code in a binary release, but your opinion is not
the
>> only
>> > > > one.
>> > > > > I feel like you're telling me that my opinion is sub-par to your
>> > > opinion
>> > > > > because it is.
>> > > > >
>> > > > > If this is such a sticking point, I move that we completely kill
>> the
>> > > > > notion of source and binary releases and make one tarball that
>> contains
>> > > > > both.
>> > > > >
>> > > > > On 5/17/13 3:17 PM, John Vines wrote:
>> > > > >
>> > > > >> I agree with Adam. It seems like it's a debate of consistency
vs.
>> > > > >> pragmatism. The cost of including these libraries are all
of maybe
>> 1kb
>> > > > in
>> > > > >> the package. The cost of excluding them is potential frustration
>> from
>> > > > end
>> > > > >> users and a lot of repetitive stress against the Apache Mirrors
>> (lets
>> > > > try
>> > > > >> and be considerate). I think it's a no brainer, but I have
yet to
>> > > here a
>> > > > >> reason that is not 'no source code in a binary release!'
>> > > > >>
>> > > > >>
>> > > > >> On Fri, May 17, 2013 at 12:11 PM, Adam Fuchs <afuchs@apache.org>
>> > > wrote:
>> > > > >>
>> > > > >>  Just to solidify the decision that Chris is already leaning
>> towards,
>> > > > let
>> > > > >>> me
>> > > > >>> try to clarify my position:
>> > > > >>> 1. The only reason not to add the native library source
code in
>> the
>> > > > >>> -bin.tar.gz distribution is that src != bin. There is
no
>> measurable
>> > > > >>> negative effect of putting the cpp files and Makefile
into the
>> > > > >>> -bin.tar.gz.
>> > > > >>> 2. At least one person wants the native library source
code in
>> the
>> > > > >>> -bin.tar.gz to make their life easier.
>> > > > >>>
>> > > > >>> This is a very simple decision. It really doesn't matter
how easy
>> it
>> > > is
>> > > > >>> to
>> > > > >>> include prebuilt native code in some other way or build
the code
>> and
>> > > > copy
>> > > > >>> it in using some other method. Those are all tangential
>> arguments.
>> > > > >>>
>> > > > >>> Adam
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> On Fri, May 17, 2013 at 2:49 PM, William Slacum <
>> > > > >>> wilhelm.von.cloud@accumulo.net**> wrote:
>> > > > >>>
>> > > > >>>  I think of the native maps as an add on and they should
probably
>> be
>> > > > >>>>
>> > > > >>> treated
>> > > > >>>
>> > > > >>>> as such. I think we should consider building a different
package
>> and
>> > > > >>>> installing them separately. Personally, for development
and
>> > > testing, I
>> > > > >>>> don't use them.
>> > > > >>>>
>> > > > >>>> Since we're building RPMs and debian packages, the
steps to
>> install
>> > > an
>> > > > >>>>
>> > > > >>> add
>> > > > >>>
>> > > > >>>> on is roughly 20 keystrokes.
>> > > > >>>>
>> > > > >>>>
>> > > > >>>> On Fri, May 17, 2013 at 2:22 PM, Josh Elser <
>> josh.elser@gmail.com
>> >
>> > > > >>>>
>> > > > >>> wrote:
>> > > > >>>
>> > > > >>>>
>> > > > >>>>  I believe I already voiced my opinion on this, but
let me
>> restate
>> > > it
>> > > > >>>>>
>> > > > >>>> since
>> > > > >>>>
>> > > > >>>>> the conversation is happening again.
>> > > > >>>>>
>> > > > >>>>> Bundling the native library built with a "common"
library is
>> > > easiest
>> > > > >>>>>
>> > > > >>>> and
>> > > > >>>
>> > > > >>>> I
>> > > > >>>>
>> > > > >>>>> believe makes the most sense. My opinion is that
source files
>> > > should
>> > > > be
>> > > > >>>>> included in a source release and that a bin release
doesn't
>> include
>> > > > >>>>>
>> > > > >>>> source
>> > > > >>>>
>> > > > >>>>> files. Since we're specifically making this distinction
by
>> making
>> > > > these
>> > > > >>>>> releases, it doesn't make sense to me why we
would decide "oh,
>> well
>> > > > in
>> > > > >>>>>
>> > > > >>>> this
>> > > > >>>>
>> > > > >>>>> one case, the bin dist will actually have _some_
src files
>> too."
>> > > > >>>>>
>> > > > >>>>> Is it not intuitive that if people need to rebuild
something,
>> that
>> > > > they
>> > > > >>>>> download a src dist (and bin) to start? :shrug:
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > >
>> > >
>>

Mime
View raw message