Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4226910F09 for ; Wed, 6 Nov 2013 23:55:40 +0000 (UTC) Received: (qmail 84096 invoked by uid 500); 6 Nov 2013 23:55:40 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 84068 invoked by uid 500); 6 Nov 2013 23:55:40 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 84060 invoked by uid 99); 6 Nov 2013 23:55:40 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Nov 2013 23:55:40 +0000 Received: from localhost (HELO mail-la0-f50.google.com) (127.0.0.1) (smtp-auth username vines, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Nov 2013 23:55:39 +0000 Received: by mail-la0-f50.google.com with SMTP id eo20so182332lab.37 for ; Wed, 06 Nov 2013 15:55:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=OAqNcFuSUusRL+7XpSe3WNAG/r14ke9N69sNH6DrgcY=; b=I+xiFYxMLlLyT8UNNQsP5sgaqEZTHBq1pzxjbANpEJqn6G+QuOTYfasOapjTN27ih6 k385NI2ZqeWdNSdBmH4YMedkQU6TAOWO9U/dDaOK+qkDbg5q4fz2gyNotbSSt91gWKEP /SQ5AuLORCy4zqucBcmHDAWWoDJds9c04Q/BIAiIhMXIrv3q/06V7qC/tBLJ6N/9gnk3 7EC6IVfyeOQqg2mb1Dc2utrZmHP/i4/U31ejsOYViO6JjeJ4sPcKnYgOxd2hMafgokwW 35/MwX7A4bMxGIq9hxQDBteeKj/LFW01lRt7wWDsDgV+XuBIX2T8cUqBxK1YdWsj07L4 yZ7g== X-Received: by 10.152.9.2 with SMTP id v2mr3227725laa.40.1383782137774; Wed, 06 Nov 2013 15:55:37 -0800 (PST) MIME-Version: 1.0 Reply-To: vines@apache.org Received: by 10.114.99.99 with HTTP; Wed, 6 Nov 2013 15:54:56 -0800 (PST) In-Reply-To: References: From: John Vines Date: Wed, 6 Nov 2013 18:54:56 -0500 Message-ID: Subject: Re: "Provided" dependencies To: Accumulo Dev List Content-Type: multipart/alternative; boundary=089e0158b8eec4cbcb04ea8ae2e2 --089e0158b8eec4cbcb04ea8ae2e2 Content-Type: text/plain; charset=ISO-8859-1 We support different versions of hadoop and we already need the HDFS classpath for the conf files, so we might as well use the ones there instead of bundling them up and potentially causing conflicts if something strange happens in the hadoop client api. On Wed, Nov 6, 2013 at 6:46 PM, Christopher wrote: > I'm not sure I understand your meaning. Why exactly do you think > specifying the scope as provided makes sense? > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Wed, Nov 6, 2013 at 5:46 PM, John Vines wrote: > > The provided make sense for hadoop to pick up dependencies. To a less > > extent, it makes sense for ZK. > > > > However, as someone who is using accumulo for a project, I would love to > > have a client library that is as sparse as possible to avoid having to > deal > > with resource conflicts. > > > > > > On Wed, Nov 6, 2013 at 5:17 PM, Joey Echeverria < > joey+ml@clouderagovt.com>wrote: > > > >> Do Accumulo users need Hadoop or it's dependencies in order to use the > >> client APIs? > >> > >> The only client API that I could see needing it would be the > >> [In|Out]putFormats, but it'd be cool if that was a separate module and > >> that module had the appropriate Hadoop dependencies with the compile > >> scope. > >> > >> -Joey > >> > >> On Wed, Nov 6, 2013 at 5:05 PM, Christopher > wrote: > >> > What's the latest opinion whether things should be marked "provided" > in > >> the pom? > >> > I've changed my mind on this a few times, myself, so I'm curious what > >> > others think. > >> > > >> > The provided scope means that it will not propagate as a transitive > >> > dependency. Other than that, it doesn't do much... though we can > >> > control packaging based on provided or not. > >> > > >> > I'm not sure this gets us much, and it's inconvenient for users. We > >> > can control packaging in other ways (like being more explicit and > >> > carefully considering which dependencies we include in an RPM or > >> > tarball, for instance). > >> > > >> > If we drop its declaration, what this means, is that if users want to > >> > build with Accumulo as a dependency, but against a different version > >> > of Hadoop than what we declare in our POM, they'll have to explicitly > >> > the hadoop dependencies, and redeclare them, or they will > >> > have to use their section to force a particular > >> > dependency of hadoop. > >> > > >> > The advantage to users, though, if we drop this, is that they won't > >> > have to constantly re-declare transitive dependencies to get their > >> > projects to build/test/run. > >> > > >> > See http://s.apache.org/maven-dependency-scopes > >> > > >> > Thoughts? > >> > > >> > -- > >> > Christopher L Tubbs II > >> > http://gravatar.com/ctubbsii > >> > --089e0158b8eec4cbcb04ea8ae2e2--