Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Added a maven style example with a single top level directory #159

Closed
wants to merge 1 commit into from
Closed

Added a maven style example with a single top level directory #159

wants to merge 1 commit into from

Conversation

ericzundel
Copy link
Member

This example shows a problem when you try to build with a BUILD file one level deep

$ cat at maven-example/BUILD
jvm_binary(name='maven-example',
  source='src/main/java/example/Main.java',
  main='example.Main'
)

and try to invoke pants on the default target in that file:

PANTS_DEV=1 ./pants goal binary maven-example
*** Running pants in dev mode from /Users/zundel/Src/Pants/src/python/pants/bin/pants_exe.py ***

14:59:46 00:00 [main]
               See a report at: http://localhost:57641/run/pants_run_2014_05_27_14_59_46_615
14:59:46 00:00   [bootstrap]
14:59:46 00:00   [setup]
14:59:46 00:00     [parse]
               Unknown goal(s): maven-example

               FAILURE

It works correctly if you add a slash on to the end of the name:

PANTS_DEV=1 ./pants goal binary maven-example/
*** Running pants in dev mode from /Users/zundel/Src/Pants/src/python/pants/bin/pants_exe.py ***

14:58:56 00:00 [main]
               See a report at: http://localhost:57641/run/pants_run_2014_05_27_14_58_56_486
14:58:56 00:00   [bootstrap]
14:58:56 00:00   [setup]
14:58:56 00:00     [parse]
...
               SUCCESS

or if you fully specify the target as "./pants goal binary maven-example:maven-example

@ity ity assigned ity and unassigned ity May 28, 2014
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 12, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
89cbf70 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 12, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
527b760 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.
@gmalmquist gmalmquist mentioned this pull request Jun 12, 2014
Closed
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 12, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
4b87f25 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 12, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
3b40809 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 13, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
f8c080d 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 13, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
35756d1 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 13, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
2da4366 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 13, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
3a7a408 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 13, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
d0f1d3c 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
@ericzundel ericzundel closed this Jun 15, 2014
@ericzundel ericzundel deleted the zundel/top-level-dir-build branch June 15, 2014 20:50
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 16, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
4e05bd0 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 16, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
e8234fb 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 16, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
5a5b46e 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 17, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
ae470ab 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
@ericzundel
Copy link
Member Author

Up for review @ https://rbcommons.com/s/twitter/r/551/

gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 17, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
dbb55c6 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 17, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
e659622 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 17, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
29447d9 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 17, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
4f0bbc9 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 17, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
9405a48 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
gmalmquist added a commit to ericzundel/pants that referenced this pull request Jun 17, 2014
@gmalmquist
Fixes the bug where pants doesn't recognize build targets on top-leve…
6443576 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: pantsbuild#159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.
ericzundel pushed a commit that referenced this pull request Jun 17, 2014
@gmalmquist @ericzundel
Fixes the bug where pants doesn't recognize build targets on top-leve…
bd1a9e0 
…l directories.

The previous argument parser naively simply checked whether a command-line argument contained a slash (/) or a colon (:). This is a reasonable assumption most of the time, but in the case where a BUILD file is located only one directory deep, (eg, buildroot/folder/BUILD), this makes it impossible to run pants on the target simply by calling (eg) ./pants goal bundle folder.

See github issue for example: #159

This fixes it by actually checking to see if a phase with goals is defined by the command-line argument. It still checks before that whether the argument contains a slash or a colon, because that if an argument has those characters it can't mean a goal. But an argument not having those characters doesn't mean it is a goal.

In a completely ambiguous situation (eg, given a command argument 'bundle', and there is a valid BUILD file at bundle/BUILD), we err on the side of the goal, and print out a warning. This makes sense, because it allows the user to disambiguate the situation using the '--' syntax.

Testing done:
Added unit tests to pants_test/commands/test_goal.py; everything passes.

Bugs Fixed 218

Reviewed at https://rbcommons.com/s/twitter/r/551/
peiyuwang added a commit that referenced this pull request Apr 6, 2016
@peiyuwang
[engine] bug fix: ensure we catch all exceptions in subprocess
f18ce8f 
We intended to catch all subprocesses exceptions, for example the test case
EngineTest.test_multiprocess_unpickleable checks SerializationError, but some
later added code wasn't protected, including line #159 that caused
#3149 test to hang.

This review fixes this by moving everything into the same try block.

This review does not fix the root cause of #3149
but next time it happens the subprocess won't die and will report the
exception back to the engine.

Testing Done:
https://travis-ci.org/peiyuwang/pants/builds/121229553 passed.

Bugs closed: 3149, 3155

Reviewed at https://rbcommons.com/s/twitter/r/3656/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@ericzundel @ity