...
Getting
...
the
...
source
...
code
...
First
...
of
...
all,
...
you
...
need
...
the
...
Pig
...
source
...
code.
...
Get
...
the
...
source
...
code
...
on
...
your
...
local
...
drive
...
using
...
...
.
...
Most
...
development
...
is
...
done
...
on
...
the
...
"trunk":
...
svn
...
checkout
...
http://svn.apache.org/repos/asf/pig/trunk/
Making Changes
Before you start, send a message to the Pig developer mailing list, or file a bug report in Jira. Describe your proposed changes and check that they fit in with what others are doing and have planned for the project. Be patient, it may take folks a while to understand your requirements.
Modify the source code and add some (very) nice features or fix some (nasty) bugs using your favorite IDE.
But take care about the following points
- All public classes and methods should have informative Javadoc comments.
- Do not use @author tags.
- Code should be formatted according to Sun's conventions. We use four spaces (not tabs) for indentation.
- Contributions should pass existing unit tests.
- New unit tests should be provided to demonstrate bugs and fixes. JUnit is our test framework:
- You must implement a class that extends
junit.framework.TestCaseand whose class name containsTest. - If an
HDFScluster and/or aMapReducecluster is needed by your test, add a field of typeMiniClusterto the class and initialize it with a statement like the following (the name of the field is not important).TestAlgebraicEval.javais an example of a test that uses cluster. The test will then run on a cluster created on the local machine.
MiniCluster cluster = MiniCluster.buildCluster();
- You must implement a class that extends
- Define methods within your class and annotate it with
@Test, and call JUnit's many assert methods to verify conditions; these methods will be executed when you runant test. - Place your class in the
testtree. - You can then run all the unit test with the command
ant test. Similarly, you can run a specific unit test with the commandant test -Dtestcase=<ClassName>(For exampleant test -Dtestcase=TestPigFile)
Generating a patch
Compilation
Make sure that your code introduces no new warnings into the javac compilation.
Unit Tests
Please make sure that all unit tests succeed before constructing your patch.
| Code Block |
|---|
h2. Making Changes Before you start, send a message to the [Pig developer mailing list|http://pig.apache.org/mailing_lists.html], or file a bug report in [Jira|http://issues.apache.org/jira/browse/PIG]. Describe your proposed changes and check that they fit in with what others are doing and have planned for the project. Be patient, it may take folks a while to understand your requirements. Modify the source code and add some (very) nice features or fix some (nasty) bugs using your favorite IDE. But take care about the following points * All public classes and methods should have informative [Javadoc|http://java.sun.com/j2se/javadoc/writingdoccomments/] comments. ** Do not use @author tags. * Code should be formatted according to [Sun's conventions|http://java.sun.com/docs/codeconv/]. We use four spaces (*not* tabs) for indentation. * Contributions should pass existing unit tests. * New unit tests should be provided to demonstrate bugs and fixes. [JUnit|http://www.junit.org/] is our test framework: ** You must implement a class that extends {{junit.framework.TestCase}} and whose class name contains {{Test}}. ** If an {{HDFS}} cluster and/or a {{MapReduce}} cluster is needed by your test, add a field of type {{MiniCluster}} to the class and initialize it with a statement like the following (the name of the field is not important). {{TestAlgebraicEval.java}} is an example of a test that uses cluster. The test will then run on a cluster created on the local machine. {{MiniCluster cluster = MiniCluster.buildCluster();}} * Define methods within your class and annotate it with {{@Test}}, and call JUnit's many assert methods to verify conditions; these methods will be executed when you run {{ant test}}. * Place your class in the {{test}} tree. * You can then run all the unit test with the command {{ant test}}. Similarly, you can run a specific unit test with the command {{ant test -Dtestcase=<ClassName>}} (For example {{ant test -Dtestcase=TestPigFile}}) h2. Generating a patch h3. Compilation Make sure that your code introduces no new warnings into the javac compilation. h3. Unit Tests Please make sure that all unit tests succeed before constructing your patch. {code} > cd trunk > ant -Djavac.args="-Xlint -Xmaxwarns 1000" clean jar test {code} |
After
...
a
...
while,
...
if
...
you
...
see
| Code Block |
|---|
} BUILD SUCCESSFUL {code} |
all
...
is
...
ok,
...
but
...
if
...
you
...
see
| Code Block |
|---|
} BUILD FAILED {code} |
then
...
please
...
examine
...
error
...
messages
...
in
...
build/test
...
and
...
fix
...
things
...
before
...
proceeding.
Javadoc
Please also check the javadoc.
| Code Block |
|---|
h3. Javadoc Please also check the javadoc. {code} > ant doc > firefox docs/index.html {code} |
Examine
...
all
...
public
...
classes
...
you've
...
changed
...
to
...
see
...
that
...
documentation
...
is
...
complete
...
and
...
informative.
...
Your
...
patch
...
must
...
not
...
generate
...
any
...
javadoc
...
warnings.
...
Creating
...
a
...
patch
...
Check
...
to
...
see
...
what
...
files
...
you
...
have
...
modified
...
with:
| Code Block |
|---|
} svn stat {code} |
Add
...
any
...
new
...
files
...
with:
| Code Block |
|---|
} svn add src/.../MyNewClass.java {code} |
Edit
...
the
...
CHANGES.txt
...
file,
...
adding
...
a
...
description
...
of
...
your
...
change,
...
including
...
the
...
bug
...
number
...
it
...
fixes.
...
If
...
this
...
is
...
a
...
new
...
feature,
...
or
...
other
...
enhancement
...
that
...
doesn't
...
currently
...
have
...
a
...
ticket
...
please
...
create
...
one
...
for
...
it,
...
then
...
use
...
it's
...
number
...
when
...
adding
...
your
...
note
...
to
...
CHANGES.txt.
...
You'll
...
need
...
this
...
ticket
...
to
...
submit
...
your
...
patch
...
anyway.
...
In
...
order
...
to
...
create
...
a
...
patch,
...
just
...
type:
| Code Block |
|---|
} svn diff > myBeautifulPatch.patch {code} |
This
...
will
...
report
...
all
...
modifications
...
done
...
on
...
Pig
...
sources
...
on
...
your
...
local
...
disk
...
and
...
save
...
them
...
into
...
the
...
myBeautifulPath.patch
...
file.
...
Read
...
the
...
patch
...
file.
...
Make
...
sure
...
it
...
includes
...
ONLY
...
the
...
modifications
...
required
...
to
...
fix
...
a
...
single
...
issue.
...
Please
...
do
...
not:
...
- reformat
...
- code
...
- unrelated
...
- to
...
- the
...
- bug
...
- being
...
- fixed:
...
- formatting
...
- changes
...
- should
...
- be
...
- separate
...
- patches/commits.
...
- comment
...
- out
...
- code
...
- that
...
- is
...
- now
...
- obsolete:
...
- just
...
- remove
...
- it.
...
- insert
...
- comments
...
- around
...
- each
...
- change,
...
- marking
...
- the
...
- change:
...
- folks
...
- can
...
- use
...
- subversion
...
- to
...
- figure
...
- out
...
- what's
...
- changed
...
- and
...
- by
...
- whom.
...
- make
...
- things
...
- public
...
- which
...
- are
...
- not
...
- required
...
- by
...
- end
...
- users.
...
Please
...
do:
...
- try
...
- to
...
- adhere
...
- to
...
- the
...
- coding
...
- style
...
- of
...
- files
...
- you
...
- edit;
...
- comment
...
- code
...
- whose
...
- function
...
- or
...
- rationale
...
- is
...
- not
...
- obvious;
...
- update
...
- documentation
...
- (e.g.,
...
- package.html
...
- files,
...
- this
...
- wiki,
...
- etc.)
...
If
...
you
...
need
...
to
...
rename
...
files
...
in
...
your
...
patch:
...
- Write
...
- a
...
- shell
...
- script
...
- that
...
- uses
...
- 'svn
...
- mv'
...
- to
...
- rename
...
- the
...
- original
...
- files.
...
- Edit
...
- files
...
- as
...
- needed
...
- (e.g.,
...
- to
...
- change
...
- package
...
- names).
...
- Create
...
- a
...
- patch
...
- file
...
- with
...
- 'svn
...
- diff
...
- --no-diff-deleted
...
- --notice-ancestry'.
...
- Submit
...
- both
...
- the
...
- shell
...
- script
...
- and
...
- the
...
- patch
...
- file.
...
This
...
- way
...
- other
...
- developers
...
- can
...
- preview
...
- your
...
- change
...
- by
...
- running
...
- the
...
- script
...
- and
...
- then
...
- applying
...
- the
...
- patch.
...
Testing
...
your
...
patch
...
Before
...
submitting
...
your
...
patch,
...
you
...
are
...
encouraged
...
to
...
run
...
the
...
same
...
tools
...
that
...
the
...
automated
...
Hudson
...
patch
...
test
...
system
...
will
...
run
...
on
...
your
...
patch.
...
This
...
enables
...
you
...
to
...
fix
...
problems
...
with
...
your
...
patch
...
before
...
you
...
submit
...
it.
...
The
...
test-patch
...
Ant
...
target
...
will
...
run
...
your
...
patch
...
through
...
the
...
same
...
checks
...
that
...
Hudson
...
currently
...
does
...
except
...
for
...
executing
...
the
...
core
...
and
...
contrib
...
unit
...
tests.
...
To
...
use
...
this
...
target,
...
you
...
must
...
run
...
it
...
from
...
a
...
clean
...
workspace
...
(ie
...
svn
...
stat
...
shows
...
no
...
modifications
...
or
...
additions).
...
From
...
your
...
clean
...
workspace,
...
run:
| Code Block |
|---|
} ant \ -Dpatch.file=/patch/to/my.patch \ -Dforrest.home=/path/to/forrest/ \ -Dfindbugs.home=/path/to/findbugs \ -Djava5.home=/patch/to/java5home \ -Dscratch.dir=/path/to/a/temp/dir \ (optional) -Dsvn.cmd=/path/to/subversion/bin/svn \ (optional) -Dgrep.cmd=/path/to/grep \ (optional) -Dpatch.cmd=/path/to/patch \ (optional) test-patch {code} |
At
...
the
...
end,
...
you
...
should
...
get
...
a
...
message
...
on
...
your
...
console
...
that
...
is
...
similar
...
to
...
the
...
comment
...
added
...
to
...
Jira
...
by
...
Hudson's
...
automated
...
patch
...
test
...
system.
...
The
...
scratch
...
directory
...
(which
...
defaults
...
to
...
the
...
value
...
of
...
$
...
user.home
...
/tmp)
...
will
...
contain
...
some
...
output
...
files
...
that
...
will
...
be
...
useful
...
in
...
determining
...
what
...
issues
...
were
...
found
...
in
...
the
...
patch.
...
Some
...
things
...
to
...
note:
...
- the
...
- optional
...
- cmd
...
- parameters
...
- will
...
- default
...
- to
...
- the
...
- ones
...
- in
...
- your
...
PATH
...
- environment
...
- variable
- the
grepcommand must support the -o flag (GNU does) - the
patchcommand must support the -E flag - you may need to explicitly set ANT_HOME. Running
ant -diagnosticswill tell you the default value on your system.
Applying a patch
To apply a patch either you generated or found from JIRA, you can issue
| Code Block |
|---|
* the {{grep}} command must support the -o flag (GNU does) * the {{patch}} command must support the -E flag * you may need to explicitly set ANT_HOME. Running {{ant -diagnostics}} will tell you the default value on your system. h3. Applying a patch To apply a patch either you generated or found from JIRA, you can issue {code} patch -p0 <cool_patch.patch {code} |
if
...
you
...
just
...
want
...
to
...
check
...
whether
...
the
...
patch
...
applies
...
you
...
can
...
run
...
patch
...
with
...
--dry-run
...
option
| Code Block |
|---|
} patch -p0 --dry-run <cool_patch.patch {code} |
If
...
you
...
are
...
an
...
Eclipse
...
user,
...
you
...
can
...
apply
...
a
...
patch
...
by
...
:
...
- Right
...
- click
...
- project
...
- name
...
- in
...
- Package
...
- Explorer,
...
#.
...
- Team
...
- ->
...
- Apply
...
- Patch
...
Contributing
...
your
...
work
...
Finally,
...
patches
...
should
...
be
...
attached
...
to
...
a
...
bug
...
report
...
in
...
...
via
...
the
...
Attach
...
File
...
link
...
on
...
the
...
jira.
...
Please
...
add
...
a
...
comment
...
that
...
asks
...
for
...
a
...
code
...
review
...
following
...
our
...
code
...
review
...
checklist.
...
Please
...
note
...
that
...
the
...
attachment
...
should
...
be
...
granted
...
license
...
to
...
ASF
...
for
...
inclusion
...
in
...
ASF
...
works
...
(as
...
per
...
the
...
...
...
subsection
...
5).
...
When
...
you
...
believe
...
that
...
your
...
patch
...
is
...
ready
...
to
...
be
...
committed,
...
select
...
the
...
Submit
...
Patch
...
link
...
on
...
the
...
issue's
...
Jira.
...
Submitted
...
patches
...
will
...
be
...
automatically
...
tested
...
against
...
"trunk"
...
by
...
...
Hudson,
...
the
...
lucene
...
project's
...
continuous
...
integration
...
engine.
...
Upon
...
test
...
completion,
...
Hudson
...
will
...
add
...
a
...
success
...
("+1")
...
message
...
or
...
failure
...
("-1")
...
to
...
your
...
bug
...
report
...
in
...
Jira.
...
If
...
your
...
issue
...
contains
...
multiple
...
patch
...
versions,
...
Hudson
...
tests
...
the
...
last
...
patch
...
uploaded.
...
Folks
...
should
...
run
...
'ant
...
clean
...
test
...
javadoc'
...
before
...
selecting
...
'Submit
...
Patch'.
...
Tests
...
should
...
all
...
pass.
...
Javadoc
...
should
...
report
...
no
...
warnings
...
or
...
errors.
...
Hudson's
...
tests
...
should
...
only
...
double-check
...
things,
...
and
...
not
...
be
...
used
...
as
...
a
...
primary
...
patch
...
tester,
...
which
...
would
...
create
...
too
...
much
...
noise
...
on
...
the
...
mailing
...
list
...
and
...
in
...
Jira.
...
Submitting
...
patches
...
that
...
fail
...
Hudson
...
testing
...
is
...
frowned
...
on,
...
(unless
...
the
...
failure
...
is
...
not
...
actually
...
due
...
to
...
the
...
patch).
...
If
...
your
...
patch
...
involves
...
performance
...
optimizations,
...
they
...
should
...
be
...
validated
...
by
...
benchmarks
...
that
...
demonstrate
...
an
...
improvement.
...
Once
...
a
...
"+1"
...
comment
...
is
...
received
...
from
...
the
...
automated
...
patch
...
testing
...
system
...
and
...
a
...
"+1,
...
code
...
reviewed"
...
comment
...
is
...
received
...
from
...
a
...
code
...
reviewer,
...
a
...
committer
...
should
...
then
...
evaluate
...
it
...
within
...
a
...
few
...
days
...
and
...
either:
...
commit
...
it;
...
or
...
reject
...
it
...
with
...
an
...
explanation.
...
Once
...
your
...
patch
...
has
...
been
...
submitted,
...
a
...
committer
...
should
...
then
...
evaluate
...
it
...
within
...
a
...
few
...
days
...
and
...
either:
...
commit
...
it;
...
or
...
reject
...
it
...
with
...
an
...
explanation.
...
Please
...
be
...
patient.
...
Committers
...
are
...
busy
...
people
...
too.
...
If
...
no
...
one
...
responds
...
to
...
your
...
patch
...
after
...
a
...
few
...
days,
...
please
...
make
...
friendly
...
reminders.
...
Please
...
incorporate
...
other's
...
suggestions
...
into
...
into
...
your
...
patch
...
if
...
you
...
think
...
they're
...
reasonable.
...
Finally,
...
remember
...
that
...
even
...
a
...
patch
...
that
...
is
...
not
...
committed
...
is
...
useful
...
to
...
the
...
community.
...
Should
...
your
...
patch
...
earn
...
a
...
-1
...
on
...
the
...
Hudson
...
test,
...
set
...
the
...
issue
...
status
...
to
...
'Resume
...
Progress',
...
upload
...
a
...
patch
...
with
...
necessary
...
fixes
...
and
...
then
...
set
...
the
...
status
...
to
...
'Submit
...
Patch'
...
again.
...
Committers:
...
for
...
non-trivial
...
changes,
...
it
...
is
...
best
...
to
...
get
...
another
...
committer
...
to
...
review
...
your
...
patches
...
before
...
commit.
...
Use
...
"Submit
...
Patch"
...
like
...
other
...
contributors,
...
and
...
then
...
wait
...
for
...
a
...
"+1"
...
from
...
another
...
committer
...
before
...
committing.
...
Please
...
also
...
try
...
to
...
frequently
...
review
...
things
...
in
...
the
...
patch
...
queue.
...
Jira
...
Guidelines
...
Please
...
comment
...
on
...
issues
...
in
...
Jira,
...
making
...
your
...
concerns
...
known.
...
Please
...
also
...
vote
...
for
...
issues
...
that
...
are
...
a
...
high
...
priority
...
for
...
you.
...
Please
...
refrain
...
from
...
editing
...
descriptions
...
and
...
comments
...
if
...
possible,
...
as
...
edits
...
spam
...
the
...
mailing
...
list
...
and
...
clutter
...
Jira's
...
"All"
...
display,
...
which
...
is
...
otherwise
...
very
...
useful.
...
Instead,
...
preview
...
descriptions
...
and
...
comments
...
using
...
the
...
preview
...
button
...
(on
...
the
...
right)
...
before
...
posting
...
them.
...
Keep
...
descriptions
...
brief
...
and
...
save
...
more
...
elaborate
...
proposals
...
for
...
comments,
...
since
...
descriptions
...
are
...
included
...
in
...
Jira's
...
automatically
...
sent
...
messages.
...
If
...
you
...
change
...
your
...
mind,
...
note
...
this
...
in
...
a
...
new
...
comment,
...
rather
...
than
...
editing
...
an
...
older
...
comment.
...
The
...
issue
...
should
...
preserve
...
this
...
history
...
of
...
the
...
discussion.
...
Stay
...
involved
...
Contributors
...
should
...
join
...
the
...
...
...
...
.
...
In
...
particular,
...
the
...
commit
...
list
...
(to
...
see
...
changes
...
as
...
they
...
are
...
made),
...
the
...
dev
...
list
...
(to
...
join
...
discussions
...
of
...
changes)
...
and
...
the
...
user
...
list
...
(to
...
help
...
others).
...
See
...
Also
Picking Something to Work On
Looking for a place to start? A great first place is to peruse the JIRA and find an issue that needs resolved. If you're looking for a bigger project, try ProposedProjects. This
gives a list of projects the Pig team would like to see worked on.