accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Billie Rinaldi <billie.rina...@gmail.com>
Subject Re: "Provided" dependencies
Date Thu, 07 Nov 2013 22:30:04 GMT
Christopher,

You're our maven expert, so in general I will defer to your good
judgement.  I am fine with either approach as long as we continue not to
package those dependencies that are currently marked provided.  I've gotten
used to this practice and now like it, and if I recall correctly it was the
reason we marked the dependencies provided in the first place.

Billie


On Wed, Nov 6, 2013 at 4:06 PM, Christopher <ctubbsii@apache.org> wrote:

> This has nothing to do with packaging. It has to do with developer
> workspaces and default dependency resolution using maven.
>
> I'm not suggesting a change to packaging. The declaration of the scope
> is independent of packaging.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Wed, Nov 6, 2013 at 6:54 PM, John Vines <vines@apache.org> wrote:
> > 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 <ctubbsii@apache.org> 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 <vines@apache.org> 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 <ctubbsii@apache.org>
> >> 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
> >> >>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message