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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]>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 <[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 >> >> >>
