I would think this should be broken into front-end and back-end. The point
being that if you are writing a UDF and you get a Jetty conflict at compile
time, it's probably a good thing to know because you will get it at runtime.
(I realize the example of Jetty in a UDF is a bit far fetched :)

I imagine that eventually Hadoop will get a real class manager and then this
will not be an issue. (I seem to remember an OSGi patch a while ago.) If you
are not careful, you will trade a compile time problem for a runtime problem.

On Monday 18 February 2008 05:18:51 Iván de Prado wrote:
I have seen that you are embedding the binary classes from several
projects into pig.jar. The idea is package all in a single jar to
simplify its use and reduce the size. I thinks is a good idea.

By the other hand, people that are developing their own LoadFunc and
other code based in Pig needs to include the pig jar in their projects.
But because pig.jar contains binaries from other OS projects, dependency
conflicts can appears (like conflicts with Jetty).

I have change the build.xml to be able to generate two jars:
- pig.jar (The current default)
- pig-core.jar

The pig-core.jar doesn't includes the dependencies into the jar, so
pig-core.jar can be included safely in people projects without generate
dependency conflicts.

I attach the new build.xml. It would be good if something like that is
added to future versions.

Congratulations for your nice project,
Iván de Prado

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 11 | next ›
Discussion Overview
groupuser @
categoriespig, hadoop
postedFeb 18, '08 at 1:19p
activeFeb 19, '08 at 7:34p



site design / logo © 2021 Grokbase