gjp 0.29.0 → 0.30.0
Sign up to get free protection for your applications and to get access to all the features.
- data/README.md +86 -111
- data/lib/gjp.rb +2 -2
- data/lib/gjp/ant_runner.rb +27 -0
- data/lib/gjp/cli.rb +27 -26
- data/lib/gjp/kit_runner.rb +2 -42
- data/lib/gjp/limited_network_user.rb +1 -1
- data/lib/gjp/maven_runner.rb +47 -0
- data/lib/gjp/pom.rb +10 -17
- data/lib/gjp/pom_getter.rb +10 -3
- data/lib/gjp/project.rb +5 -5
- data/lib/gjp/script_generator.rb +4 -3
- data/lib/gjp/source_getter.rb +12 -81
- data/lib/gjp/version.rb +1 -1
- data/lib/gjp/version_matcher.rb +2 -2
- data/spec/lib/ant_runner_spec.rb +46 -0
- data/spec/lib/kit_runner_spec.rb +5 -76
- data/spec/lib/maven_runner_spec.rb +67 -0
- data/spec/lib/pom_getter_spec.rb +6 -0
- data/spec/lib/pom_spec.rb +12 -22
- data/spec/lib/source_getter_spec.rb +9 -42
- data/spec/spec_helper.rb +28 -11
- metadata +8 -8
- data/lib/gjp/parent_pom_getter.rb +0 -22
- data/lib/gjp/source_address_getter.rb +0 -51
- data/spec/lib/parent_pom_getter_spec.rb +0 -16
- data/spec/lib/source_address_getter_spec.rb +0 -20
data/README.md
CHANGED
@@ -1,27 +1,21 @@
|
|
1
1
|
# gjp – Green Java Packager's tools
|
2
2
|
|
3
|
-
`gjp`
|
3
|
+
`gjp` is a set of tools to ease creating Linux packages for Java projects.
|
4
4
|
|
5
|
-
|
5
|
+
## Why?
|
6
6
|
|
7
|
-
|
8
|
-
|
9
|
-
`gjp` is a research project currently in beta state. All basic features have been coded, non-essential ones are being planned, packages are currently being built. If you are a packager you can try to use it, any feedback would be **very** welcome!
|
10
|
-
|
11
|
-
At the moment `gjp` is tested on openSUSE and can only output RPMs for the openSUSE and SLES distributions. Fedora, RHEL and other distros could be supported in the future.
|
7
|
+
Packaging of Java projects is sometimes hard because build tools like Maven partially overlap with distro tools like RPM in functionality.
|
12
8
|
|
13
|
-
|
9
|
+
We are trying to come up with **a tool that drastically simplifies packaging**.
|
14
10
|
|
15
|
-
|
11
|
+
## How to install?
|
16
12
|
|
17
|
-
|
18
|
-
|
19
|
-
## Requirements and installation
|
13
|
+
First you need:
|
20
14
|
|
21
15
|
* [Ruby 1.9](https://www.ruby-lang.org/en/);
|
22
16
|
* [git](http://git-scm.com/);
|
23
17
|
* a JDK that can compile whatever software you need to package;
|
24
|
-
* only for the optional `set-up-nonet-user` subcommand, `sudo` and `iptables
|
18
|
+
* only for the optional `set-up-nonet-user` subcommand, `sudo` and `iptables`.
|
25
19
|
|
26
20
|
You can install gjp via RubyGems:
|
27
21
|
|
@@ -29,38 +23,27 @@ You can install gjp via RubyGems:
|
|
29
23
|
|
30
24
|
## Workflow
|
31
25
|
|
32
|
-
Building a package with `gjp` is quite unusual — this is a [deliberate choice](#motivation)
|
33
|
-
|
34
|
-
### Overview
|
35
|
-
|
36
|
-
The basic process is:
|
37
|
-
|
38
|
-
* a `gjp` project is created;
|
39
|
-
* package sources are added in `src/<package name>`;
|
40
|
-
* any other file that is needed for the build, except the JDK, is added in binary form (jars, the Maven executable, plugins, etc.) in `kit/`. In `gjp` a **kit** is a set of binary files that satisfies all build dependencies in a `gjp` project;
|
41
|
-
* a build is attempted and during the build, `gjp` keeps track of file changes. When it finishes, `gjp` restores `src/` in its original state, making it a "repeatable dry-run build". `gjp` will retain any files that were automatically downloaded by Maven or other similar tools in `kit/`, along with other binary build dependencies, and note any produced file for later spec generation;
|
42
|
-
* `gjp` produces spec files for two packages: one for the project itself and one for the kit needed to build it;
|
43
|
-
* kit and project packages can be submitted to [OBS](http://en.opensuse.org/openSUSE:Build_Service). Project package will rebuild cleanly because it needs no Internet access - all files were already downloaded during the dry-run phase above and are included in the kit.
|
44
|
-
|
45
|
-
Note that:
|
26
|
+
Building a package with `gjp` is quite unusual — this is a [deliberate choice](#motivation), so don't worry. Basic steps are:
|
46
27
|
|
47
|
-
*
|
48
|
-
*
|
49
|
-
*
|
50
|
-
*
|
51
|
-
*
|
28
|
+
* `gjp init` a new project;
|
29
|
+
* add sources to `src/<package name>` and everything else you need in binary form in `kit/` (eg. a Maven binary distribution);
|
30
|
+
* execute `gjp dry-run`, any command needed to compile your software (possibly `gjp mvn package`), then `gjp finish`;
|
31
|
+
* execute `gjp generate-all`;
|
32
|
+
* done! Spec files and tarballs are baked in `output` automatically by `gjp`.
|
52
33
|
|
53
|
-
|
34
|
+
## How can that possibly work? (commons-collections walkthrough)
|
54
35
|
|
55
|
-
|
36
|
+
Let's review all steps in detail with a concrete Maven-based example, commons-collections.
|
56
37
|
|
57
|
-
|
38
|
+
First, ceate a new `gjp` project, in this example named "myproject":
|
58
39
|
|
59
|
-
mkdir
|
60
|
-
cd
|
40
|
+
mkdir myproject
|
41
|
+
cd myproject
|
61
42
|
gjp init
|
62
43
|
|
63
|
-
`gjp init` generates a folder structure
|
44
|
+
(`gjp init` generates a folder structure for you).
|
45
|
+
|
46
|
+
Second, place all your projects' source files in `src/`. Every `src/` subfolder will become a separate package named after the folder itself, so use the following commands to create a `commons-collections` folders and populate it:
|
64
47
|
|
65
48
|
cd src
|
66
49
|
mkdir commons-collections
|
@@ -69,116 +52,91 @@ Ceate a new `gjp` project, in this example named "galaxy":
|
|
69
52
|
unzip commons-collections-3.2.1-src.zip
|
70
53
|
rm commons-collections-3.2.1-src.zip
|
71
54
|
|
72
|
-
|
55
|
+
Third, all non-source files needed for the build should go into `kit`. This includes all build dependencies and tools excluding the JDK, so in this case we need Maven:
|
73
56
|
|
74
57
|
cd ../../kit
|
75
|
-
wget http://apache.
|
76
|
-
unzip apache-maven-3.1.
|
77
|
-
rm apache-maven-3.1.
|
78
|
-
cd ..
|
79
|
-
|
80
|
-
This is actually everything needed to do a first dry-run build.
|
81
|
-
|
82
|
-
#### First dry-run build
|
58
|
+
wget http://www.eu.apache.org/dist/maven/binaries/apache-maven-3.1.1-bin.zip
|
59
|
+
unzip apache-maven-3.1.1-bin.zip
|
60
|
+
rm apache-maven-3.1.1-bin.zip
|
83
61
|
|
84
|
-
|
62
|
+
Fourth, you need to show `gjp` how to build your package by executing `gjp dry-run` and `gjp finish`. Bash history will be recorded to generate a build script (possibly only a starting point, maybe sufficient in simple cases):
|
85
63
|
|
86
64
|
gjp dry-run
|
87
65
|
cd src/commons-collections/commons-collections-3.2.1-src/
|
88
66
|
gjp mvn package
|
89
|
-
|
90
|
-
Success! Now we have to tell gjp to return in normal mode:
|
91
|
-
|
92
67
|
gjp finish
|
93
68
|
|
94
|
-
|
95
|
-
|
96
|
-
Note that, if the build was unsusccesful, the following command can be used to cancel it and return to pre-dry running state:
|
69
|
+
Note that we used `gjp mvn package` instead of `mvn package` so that `gjp` will use Maven from `kit/` instead of the system-wide installation you might have. `gjp` will also add some options on the mvn commandline so that any downloaded files will be retained in `kit/m2` so that this build can be replayed (even without network access) later. Also note that this being a dry-run build, sources will be brought back to their original state after `gjp finish`. This ensures build repeatability.
|
97
70
|
|
98
|
-
|
71
|
+
Finally, use this command to let `gjp` to generate build scripts, spec files and tarballs:
|
99
72
|
|
100
|
-
|
101
|
-
|
102
|
-
`gjp` expects that all commands needed to build a package are in a `build.sh` script in `src/<package name>`. If you are a Bash user you are lucky - `gjp` can create one for you by looking at your command history! Just type:
|
103
|
-
|
104
|
-
gjp generate-package-script
|
73
|
+
gjp generate-all
|
105
74
|
|
106
|
-
Note that
|
75
|
+
Note that gjp will also generate a special binary-only package called a **kit**, which contains basically the `kit/` folder. This is the only build-time requirement of any `gjp` package in your project.
|
107
76
|
|
108
|
-
|
77
|
+
## Special cases
|
109
78
|
|
110
|
-
|
79
|
+
### Failing builds
|
111
80
|
|
112
|
-
|
81
|
+
If youyr build fails for whatever reason, abort it with `gjp finish --abort`. `gjp` will restore all project files as they were before build.
|
113
82
|
|
114
|
-
|
83
|
+
### Manual changes
|
115
84
|
|
116
|
-
|
85
|
+
You can do any manual changes to spec and build.sh files and regenerate them later, `gjp` will reconcile changes with a [three-way merge](http://en.wikipedia.org/wiki/Three-way_merge#Three-way_merge) and alert about any conflicts. You can generate single files with the following commands:
|
117
86
|
|
118
|
-
|
87
|
+
* `gjp generate-kit-archive`: (re)generates the kit tarball;
|
88
|
+
* `gjp generate-kit-spec`: (re)generates the kit spec;
|
89
|
+
* `gjp generate-package-script`: (re)generates the `build.sh` file from the latest bash history (assumes `gjp dry-run` and `gjp finish`have been used). Assumes your current working directory is in a package folder (that is, a subdirectory of `src/<package name>/`);
|
90
|
+
* `gjp generate-package-archive`: (re)generates a package tarball;
|
91
|
+
* `gjp generate-package-spec`: (re)generates a package spec;
|
119
92
|
|
120
|
-
|
93
|
+
Note that, by default, `generate-kit-archive` will generate additional "diff" tar.xz files instead of rewriting the whole archive - this will result in faster uploads if you use OBS (see below). You can use the `--full` option to regenerate a single complete archive.
|
121
94
|
|
122
|
-
|
95
|
+
### [OBS](build.opensuse.org)
|
123
96
|
|
124
|
-
|
97
|
+
If you want to submit packages to OBS, you can do so by replacing the `output/` directory in your `gjp` project with a symlink to your OBS project directory.
|
125
98
|
|
126
|
-
|
127
|
-
gjp generate-package-spec
|
128
|
-
less ../commons-collections.spec
|
99
|
+
Packages will rebuild cleanly in OBS because no Internet access is needed - all files were already downloaded during dry-run and are included in the kit.
|
129
100
|
|
130
|
-
|
131
|
-
You can also edit the specs file manually if you want. When you later regenerate it, `gjp` will automatically try to reconcile changes with a [three-way merge](http://en.wikipedia.org/wiki/Three-way_merge#Three-way_merge).
|
101
|
+
Note that the kit package is needed at build time only by OBS, no end user should ever install it.
|
132
102
|
|
133
|
-
|
103
|
+
### Kit sources
|
134
104
|
|
135
|
-
|
105
|
+
Your kit is basically a binary blob. If its sources are needed for proper packaging, for example to comply with the GPL, some extra steps are needed.
|
136
106
|
|
137
|
-
|
107
|
+
If you use Maven, most (~90%) sources can be automatically downloaded:
|
138
108
|
|
139
|
-
|
140
|
-
mkdir <package_name>
|
141
|
-
cd <package_name>
|
142
|
-
wget <sources>
|
143
|
-
...
|
144
|
-
gjp dry-run
|
145
|
-
gjp mvn package
|
146
|
-
gjp finish
|
147
|
-
gjp generate-all
|
148
|
-
|
149
|
-
#### Kit sources
|
109
|
+
gjp get-maven-source-jars
|
150
110
|
|
151
|
-
|
111
|
+
The remaining (mostly very outdated) jars will be listed by `gjp` when the download ends. You need to manually find corresponding sources for them, you can use:
|
152
112
|
|
153
|
-
|
113
|
+
gjp get-source /path/to/<jar name>.pom
|
154
114
|
|
155
|
-
|
115
|
+
to get pointers to relevant sites if available in the pom itself.
|
156
116
|
|
157
|
-
|
117
|
+
A list of commonly used jars can be found [below](#frequently-used-jar-sources).
|
158
118
|
|
159
|
-
|
119
|
+
### Ant builds
|
160
120
|
|
161
|
-
|
121
|
+
`gjp` is currently optimized for Maven as it is the most common build tool, but it can work with any other. In particular, support for Ant has already been implemented and `gjp ant` works like `gjp mvn`.
|
162
122
|
|
163
|
-
|
123
|
+
Sometimes you will have jar files distributed along with the source archive that will end up in `src/`: you don't want that! Run
|
164
124
|
|
165
|
-
|
166
|
-
* `gjp get-source-address POM` will attempt to find the SCM Internet address of a pom.xml from the file itself or through api.github.com. `POM` can either be a filename or a URI;
|
167
|
-
* `gjp get-source POM ADDRESS` downloads the source of a pom.xml's project from its SCM at ADDRESS;
|
125
|
+
gjp purge-jars
|
168
126
|
|
169
|
-
|
127
|
+
to have them moved to `kit/jars`. The command will generate a symlink back to the original, so builds will work as expected.
|
170
128
|
|
171
|
-
|
129
|
+
When generating spec files, be sure to have a `pom.xml` in your package directory even if you are not using Maven: `gjp` will automatically take advantage of information from it to compile many fields.
|
172
130
|
|
173
|
-
|
131
|
+
You can also ask `gjp` to find one via `gjp get-pom <filename>.jar` (be sure to have Maven in your kit).
|
174
132
|
|
175
|
-
|
133
|
+
### Other builds
|
176
134
|
|
177
|
-
|
135
|
+
Other build tools are currently unsupported but will be added in the future. You can nevertheless use them - the only rule is that you have to keep all of their files in `kit`.
|
178
136
|
|
179
|
-
|
137
|
+
### Optional: networkless dry-run builds
|
180
138
|
|
181
|
-
`gjp`
|
139
|
+
If you want to be 100% sure your package builds without network access, you can use a special `gjp` subcommand to setup a `nonet` user that cannot use the Internet. Then you can simply retry the build using that user to see if it works. Note that the following commands will alter group permissions to allow both your current user and `nonet` to work on the same files.
|
182
140
|
|
183
141
|
gjp set-up-nonet-user
|
184
142
|
chmod -R g+rw ../../..
|
@@ -190,9 +148,6 @@ Once built, you should get a pom.xml file (via `gjp get-pom`, see above) in orde
|
|
190
148
|
exit
|
191
149
|
gjp finish
|
192
150
|
|
193
|
-
The above is not mandatory, but it can be useful for debugging purposes.
|
194
|
-
|
195
|
-
|
196
151
|
### Gotchas
|
197
152
|
|
198
153
|
* `gjp` internally uses `git` to keep track of files, any gjp project is actually also a `git` repo. Feel free to navigate it, you can commit, push and pull as long as the `gjp` tags are preserved. You can also delete commits and tags, effectively rewinding gjp history (just make sure to delete all tags pointing to a certain commit when you discard it);
|
@@ -201,6 +156,13 @@ The above is not mandatory, but it can be useful for debugging purposes.
|
|
201
156
|
|
202
157
|
export NO_BRP_CHECK_BYTECODE_VERSION=true
|
203
158
|
|
159
|
+
* if packages build at first but then fail after a few days because Maven tries to connect to the Internet, add the `--option` flag to the `mvn` line in `build.sh`;
|
160
|
+
|
161
|
+
### Frequently used jar sources
|
162
|
+
|
163
|
+
* ant-launcher-1.6.5: is included in ant-1.6.5 sources, you most prbably have it already in `kit/m2/ant/ant/1.6.5`;
|
164
|
+
* doxia-sink-api-1.0-alpha-4: use `svn checkout http://svn.apache.org/repos/asf/maven/doxia/doxia/tags/doxia-sink-api-1.0-alpha-4/ doxia-sink-api-1.0-alpha-4`;
|
165
|
+
* kxml2-2.2.2: use http://downloads.sourceforge.net/project/kxml/kxml2/2.2.2/kxml2-src-2.2.2.zip;
|
204
166
|
|
205
167
|
## Motivation
|
206
168
|
|
@@ -219,17 +181,24 @@ The current solution in openSUSE is having the packager handle those differences
|
|
219
181
|
|
220
182
|
The Fedora community is experimenting with another set of tools, [XMvn](http://mizdebsk.fedorapeople.org/xmvn/site/), which goals are similar to `gjp`'s.
|
221
183
|
|
222
|
-
|
184
|
+
## Kit rationale
|
223
185
|
|
224
186
|
`gjp` simplifies the packaging process mostly because of its use of a binary blob package that contains all build time dependencies for a set of packages called a **kit**.
|
225
187
|
|
226
188
|
Building software from a binary blob is unusual for Linux distros, and it surely has some drawbacks. It is anyway believed that benefits outweigh them, in fact using prebuilt software:
|
227
189
|
|
228
|
-
* drastically reduces packaging efforts. A very basic and relatively simple package like [commons-collections](http://commons.apache.org/proper/commons-collections/) needs about [150 jars](https://build.opensuse.org/package/show/home:SilvioMoioli/
|
190
|
+
* drastically reduces packaging efforts. A very basic and relatively simple package like [commons-collections](http://commons.apache.org/proper/commons-collections/) needs about [150 jars](https://build.opensuse.org/package/show/home:SilvioMoioli/myproject-kit) just to be compiled and tested. Those should be packaged, roughly, one-by-one!
|
229
191
|
* is just the way all Java developers out there build, test and use their software — this is how they expect it to work. Any different approach is necessarily error-prone and could result in unexpected bugs;
|
230
192
|
* does not affect the ability of providing patches to Java projects, as only build time requirements are in the kit. In virtually all cases patching a piece of software does not require to patch its build toolchain;
|
231
193
|
* does not affect the ability of complying to software licenses like the GPL. In fact those licenses only require to redistribute a project's source code - not the whole toolchain needed to build it. [Sources can be added](#kit-sources) for GPL'd parts of the kit, if any.
|
232
194
|
|
195
|
+
## Status
|
196
|
+
|
197
|
+
`gjp` is a research project currently in beta state. If you are a packager you can try to use it, any feedback would be **very** welcome!
|
198
|
+
|
199
|
+
At the moment `gjp` is tested on openSUSE.
|
200
|
+
|
201
|
+
|
233
202
|
## Sources
|
234
203
|
|
235
204
|
`gjp`'s Git repo is available on GitHub, which can be browsed at:
|
@@ -240,6 +209,12 @@ and cloned with:
|
|
240
209
|
|
241
210
|
git clone git@github.com:SilvioMoioli/gjp.git
|
242
211
|
|
212
|
+
## Contact
|
213
|
+
|
214
|
+
Are you using `gjp` or even just reading this? Let's get in touch!
|
215
|
+
|
216
|
+
smoioli at suse dot de
|
217
|
+
|
243
218
|
## License
|
244
219
|
|
245
220
|
MIT license.
|
data/lib/gjp.rb
CHANGED
@@ -9,10 +9,10 @@ require "gjp/version_matcher"
|
|
9
9
|
require "gjp/maven_website"
|
10
10
|
require "gjp/limited_network_user"
|
11
11
|
require "gjp/pom_getter"
|
12
|
-
require "gjp/source_address_getter"
|
13
12
|
require "gjp/source_getter"
|
14
|
-
require "gjp/parent_pom_getter"
|
15
13
|
require "gjp/kit_runner"
|
14
|
+
require "gjp/ant_runner"
|
15
|
+
require "gjp/maven_runner"
|
16
16
|
require "gjp/kit_spec_adapter"
|
17
17
|
require "gjp/package_spec_adapter"
|
18
18
|
require "gjp/spec_generator"
|
@@ -0,0 +1,27 @@
|
|
1
|
+
# encoding: UTF-8
|
2
|
+
|
3
|
+
module Gjp
|
4
|
+
# runs Ant with gjp-specific options
|
5
|
+
class AntRunner < KitRunner
|
6
|
+
include Logger
|
7
|
+
|
8
|
+
# runs ant in a subprocess
|
9
|
+
def ant(options)
|
10
|
+
run_executable("#{get_ant_commandline(@project.full_path)} #{options.join(' ')}")
|
11
|
+
end
|
12
|
+
|
13
|
+
# returns a command line for running Ant from the specified
|
14
|
+
# prefix
|
15
|
+
def get_ant_commandline(prefix)
|
16
|
+
executable = find_executable("ant")
|
17
|
+
|
18
|
+
if executable != nil
|
19
|
+
ant_path = File.join(prefix, executable)
|
20
|
+
|
21
|
+
"#{ant_path}"
|
22
|
+
else
|
23
|
+
raise ExecutableNotFoundError.new("ant")
|
24
|
+
end
|
25
|
+
end
|
26
|
+
end
|
27
|
+
end
|
data/lib/gjp/cli.rb
CHANGED
@@ -73,7 +73,7 @@ module Gjp
|
|
73
73
|
checking_exceptions do
|
74
74
|
project = Gjp::Project.new(".")
|
75
75
|
ensure_dry_running(true, project) do
|
76
|
-
Gjp::
|
76
|
+
Gjp::MavenRunner.new(project).mvn(@options)
|
77
77
|
end
|
78
78
|
end
|
79
79
|
end
|
@@ -91,7 +91,7 @@ module Gjp
|
|
91
91
|
checking_exceptions do
|
92
92
|
project = Gjp::Project.new(".")
|
93
93
|
ensure_dry_running(true, project) do
|
94
|
-
Gjp::
|
94
|
+
Gjp::AntRunner.new(project).ant(@options)
|
95
95
|
end
|
96
96
|
end
|
97
97
|
end
|
@@ -301,42 +301,43 @@ module Gjp
|
|
301
301
|
|
302
302
|
puts "#{format_path(path, project)} written, #{text_status}"
|
303
303
|
else
|
304
|
-
puts "#{name} not found. Try
|
304
|
+
puts "#{name}'s pom not found. Try:"
|
305
|
+
puts "http://google.com/#q=#{URI::encode(pom_getter.cleanup_name(name) + " pom")}"
|
305
306
|
end
|
306
307
|
end
|
307
308
|
end
|
308
309
|
end
|
309
310
|
|
310
|
-
subcommand "get-
|
311
|
-
parameter "POM", "a pom file path or URI"
|
312
|
-
def execute
|
313
|
-
checking_exceptions do
|
314
|
-
puts Gjp::ParentPomGetter.new.get_parent_pom(pom)
|
315
|
-
end
|
316
|
-
end
|
317
|
-
end
|
318
|
-
|
319
|
-
subcommand "get-source-address", "Retrieves a project's SCM Internet address" do
|
311
|
+
subcommand "get-source", "Attempts to retrieve a project's sources" do
|
320
312
|
parameter "POM", "a pom file path or URI"
|
321
313
|
|
322
314
|
def execute
|
323
315
|
checking_exceptions do
|
324
|
-
|
316
|
+
project = Gjp::Project.new(".")
|
317
|
+
source_getter = Gjp::SourceGetter.new
|
318
|
+
|
319
|
+
puts "Attempting to find source through Maven..."
|
320
|
+
if source_getter.get_maven_source_jar(project, pom)
|
321
|
+
puts "Source jar found and added to Maven repository."
|
322
|
+
else
|
323
|
+
effective_pom_path = Gjp::MavenRunner.new(project).get_effective_pom(pom)
|
324
|
+
puts "Source jar not found in Maven. Try looking here:"
|
325
|
+
pom = Gjp::Pom.new(effective_pom_path)
|
326
|
+
if pom.url && !pom.url.empty?
|
327
|
+
puts "Website: #{pom.url}"
|
328
|
+
end
|
329
|
+
if pom.scm_connection && !pom.scm_connection.empty?
|
330
|
+
puts "SCM connection: #{pom.scm_connection}"
|
331
|
+
end
|
332
|
+
if pom.scm_url && !pom.scm_url.empty?
|
333
|
+
puts "SCM connection: #{pom.scm_url}"
|
334
|
+
end
|
335
|
+
puts "The effective POM: #{effective_pom_path}"
|
336
|
+
puts "Google: http://google.com/#q=#{URI::encode(pom.name + ' sources')}"
|
337
|
+
end
|
325
338
|
end
|
326
339
|
end
|
327
340
|
end
|
328
|
-
|
329
|
-
subcommand "get-source", "Retrieves a project's source code directory" do
|
330
|
-
parameter "ADDRESS", "project's SCM Internet address"
|
331
|
-
parameter "POM", "project's pom file path or URI"
|
332
|
-
parameter "[DIRECTORY]", "directory in which to save the source code", :default => "."
|
333
|
-
|
334
|
-
def execute
|
335
|
-
checking_exceptions do
|
336
|
-
puts Gjp::SourceGetter.new.get_source(address, pom, directory)
|
337
|
-
end
|
338
|
-
end
|
339
|
-
end
|
340
341
|
|
341
342
|
private
|
342
343
|
|
data/lib/gjp/kit_runner.rb
CHANGED
@@ -27,51 +27,11 @@ module Gjp
|
|
27
27
|
nil
|
28
28
|
end
|
29
29
|
|
30
|
-
# runs an external executable
|
30
|
+
# runs an external executable, returns true on success
|
31
31
|
def run_executable(full_commandline)
|
32
32
|
log.debug "running #{full_commandline}"
|
33
33
|
Process.wait(Process.spawn(full_commandline))
|
34
|
-
|
35
|
-
end
|
36
|
-
|
37
|
-
# runs mvn in a subprocess
|
38
|
-
def mvn(options)
|
39
|
-
run_executable "#{get_maven_commandline(@project.full_path)} #{options.join(' ')}"
|
40
|
-
end
|
41
|
-
|
42
|
-
# returns a command line for running Maven from the specified
|
43
|
-
# prefix
|
44
|
-
def get_maven_commandline(prefix)
|
45
|
-
executable = find_executable("mvn")
|
46
|
-
|
47
|
-
if executable != nil
|
48
|
-
mvn_path = File.join(prefix, executable)
|
49
|
-
repo_path = File.join(prefix, "kit", "m2")
|
50
|
-
config_path = File.join(prefix, "kit", "m2", "settings.xml")
|
51
|
-
|
52
|
-
"#{mvn_path} -Dmaven.repo.local=#{repo_path} -s#{config_path}"
|
53
|
-
else
|
54
|
-
raise ExecutableNotFoundError.new("mvn")
|
55
|
-
end
|
56
|
-
end
|
57
|
-
|
58
|
-
# runs mvn in a subprocess
|
59
|
-
def ant(options)
|
60
|
-
run_executable "#{get_ant_commandline(@project.full_path)} #{options.join(' ')}"
|
61
|
-
end
|
62
|
-
|
63
|
-
# returns a command line for running Ant from the specified
|
64
|
-
# prefix
|
65
|
-
def get_ant_commandline(prefix)
|
66
|
-
executable = find_executable("ant")
|
67
|
-
|
68
|
-
if executable != nil
|
69
|
-
ant_path = File.join(prefix, executable)
|
70
|
-
|
71
|
-
"#{ant_path}"
|
72
|
-
else
|
73
|
-
raise ExecutableNotFoundError.new("ant")
|
74
|
-
end
|
34
|
+
$?.exitstatus == 0
|
75
35
|
end
|
76
36
|
end
|
77
37
|
|