Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> "Provided" dependencies

Copy link to this message
Re: "Provided" dependencies
It eases the common case of including transitive dependencies in user
code that writes against the Accumulo API, allowing them to control
versioning of dependencies with the standard dependencyManagement
section (they won't have to explicitly specify dependencies which are
transitive, which can be non-intuitive).

It makes things slightly more difficult in the case of specifying an
alternate transitive dependency than the standard one (eg. using CDH
instead of Apache Hadoop). In this case, users will continue to
specify their CDH dependencies as they would anyway in their project,
but they'll also have to exclude the Apache Hadoop transitive
dependency from the Accumulo dependency.

There's a trade-off here, based on what makes it easier for users
writing client code against Accumulo. As far as I can tell, there's no
other pro/con for the declaration, as our packaging scheme is
independent of the scope.

These choices become moot when we can get separate accumulo-client-api
and accumulo-client-runtime dependencies via ACCUMULO-1483.

Christopher L Tubbs II
On Thu, Nov 7, 2013 at 5:09 PM, Sean Busbey <[EMAIL PROTECTED]> wrote:
> Can we please specify what use case we're hoping to ease by changing our
> provided status for e.g. hadoop-client?
> On Thu, Nov 7, 2013 at 4:05 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
>> Dropping provided sounds good.    Seems like it would make users poms
>> simpler.
>> On Wed, Nov 6, 2013 at 5:05 PM, Christopher <[EMAIL PROTECTED]> 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
>> > <exclude> the hadoop dependencies, and redeclare them, or they will
>> > have to use their <dependencyManagement> 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
>> >
> --
> Sean