gjp 0.16.0 → 0.16.1
Sign up to get free protection for your applications and to get access to all the features.
- data/README.md +39 -17
- data/lib/gjp/project.rb +17 -9
- data/lib/gjp/version.rb +1 -1
- metadata +1 -1
data/README.md
CHANGED
@@ -6,7 +6,9 @@ The project objective is to strongly reduce manual packaging efforts by enabling
|
|
6
6
|
|
7
7
|
## Status
|
8
8
|
|
9
|
-
`gjp` is a research project currently in alpha state. Basic concepts seem to be viable, packages are currently being built with the new approach to identify problem areas but not all basic features have been coded yet. If you are a packager you can try to use it (any feedback would be **very** welcome!), but be warned that anything can still change at this point.
|
9
|
+
`gjp` is a research project currently in alpha state. Basic concepts seem to be viable, packages are currently being built with the new approach to identify problem areas but not all basic features have been coded yet. If you are a packager you can try to use it (any feedback would be **very** welcome!), but be warned that anything can still change at this point.
|
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.
|
10
12
|
|
11
13
|
## Contact
|
12
14
|
|
@@ -14,15 +16,17 @@ Are you using `gjp` or even just reading this? Let's get in touch!
|
|
14
16
|
|
15
17
|
smoioli at suse dot de
|
16
18
|
|
19
|
+
## Requirements and installation
|
17
20
|
|
18
|
-
|
21
|
+
* [Ruby 1.9](https://www.ruby-lang.org/en/);
|
22
|
+
* [git](http://git-scm.com/);
|
23
|
+
* a JDK that can compile whatever software you need to package;
|
24
|
+
* only for the optional `set-up-nonet-user` subcommand, `sudo` and `iptables`;
|
19
25
|
|
20
|
-
|
26
|
+
You can install gjp via RubyGems:
|
21
27
|
|
22
28
|
$ gem install gjp
|
23
29
|
|
24
|
-
Note: `gjp` requires `git` in order to work. Some non-essential subcommands also need `iptables`, `sudo` and a JDK.
|
25
|
-
|
26
30
|
## Workflow
|
27
31
|
|
28
32
|
Building a package with `gjp` is quite unusual — this is a [deliberate choice](#motivation) to minimize packaging efforts.
|
@@ -34,7 +38,7 @@ The basic process is:
|
|
34
38
|
* a `gjp` project is created;
|
35
39
|
* sources are added to the project, `gjp` keeps track of them;
|
36
40
|
* any other file that is needed for the build, except the JDK, is added in binary form (jars, the Maven executable, its plugins, etc.). Again, `gjp` keeps track of what you add, noting that those were binary build dependencies and not sources;
|
37
|
-
* a build is attempted. After the build is successful, `gjp`
|
41
|
+
* a build is attempted. After the build is successful, `gjp` tracks which files were produced and restores sources in their original state, making it a "repeatable dry-run build". `gjp` also retains any files that were automatically downloaded by Maven or other similar tools during the dry-run as binary build dependencies;
|
38
42
|
* `gjp` produces spec files for two packages: one for the project itself and one for all of its binary build dependencies, called a **kit**;
|
39
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 above and are included in the kit.
|
40
44
|
|
@@ -48,19 +52,21 @@ Note that:
|
|
48
52
|
|
49
53
|
In `gjp`, the build process can be in one of the following phases at any given moment:
|
50
54
|
|
51
|
-
* gathering
|
52
|
-
* dry-running
|
53
|
-
* finishing
|
55
|
+
* **gathering**: in this phase you add sources and kit files. New projects start in this phase, you can always enter it later with `gjp gather`;
|
56
|
+
* **dry-running**: in this phase you attempt a build. Any change in the sources will be reverted after it ends, while files added to the kit will be retained. You can enter this phase with `gjp dry-run`;
|
57
|
+
* **finishing**: in this phase `gjp` generates specs and archive files. You can enter it running `gjp finish`;
|
54
58
|
|
55
59
|
### Sample project (commons-io)
|
56
60
|
|
61
|
+
#### Initialization and first gathering phase
|
62
|
+
|
57
63
|
Ceate a new `gjp` project, in this example named "galaxy":
|
58
64
|
|
59
65
|
mkdir galaxy
|
60
66
|
cd galaxy
|
61
67
|
gjp init
|
62
68
|
|
63
|
-
|
69
|
+
`gjp init` automatically starts a new gathering phase in which you can add sources and kit files. It also generated a folder structure and assumes you respect it, in particular, you should 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
70
|
|
65
71
|
cd src
|
66
72
|
mkdir commons-collections
|
@@ -77,7 +83,11 @@ Now let's move to the kit (which, unsurprisingly, should be placed in the `kit`
|
|
77
83
|
rm apache-maven-3.1.0-bin.zip
|
78
84
|
cd ..
|
79
85
|
|
80
|
-
|
86
|
+
This is actually everything needed to do a first dry-run build.
|
87
|
+
|
88
|
+
#### First dry-run phase
|
89
|
+
|
90
|
+
Let's call `gjp dry-run` to let `gjp` know we are building and then call Maven. Note that `gjp mvn` is used instead of plain `mvn`: `gjp` will take care of locating the Maven installation we have in the `kit` and ensure it will store all downloaded files there.
|
81
91
|
|
82
92
|
gjp dry-run
|
83
93
|
cd src/commons-collections/commons-collections-3.2.1-src/
|
@@ -86,6 +96,8 @@ Nothing else is needed for a first build. Let's call `gjp dry-run` to let `gjp`
|
|
86
96
|
|
87
97
|
Success! At this point `gjp` took note of all needed files, and restored `src` as it was before the build. This should be sufficient to be able to repeat the build on a machine with no Internet access, but what if we wanted to be 100% sure of that?
|
88
98
|
|
99
|
+
#### Second, networkless, dry-run phase
|
100
|
+
|
89
101
|
`gjp` has a subcommand to setup a `nonet` user without Internet access, courtesy of `iptables`. 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.
|
90
102
|
|
91
103
|
gjp set-up-nonet-user
|
@@ -99,6 +111,8 @@ Success! At this point `gjp` took note of all needed files, and restored `src` a
|
|
99
111
|
|
100
112
|
The above is obviously not mandatory, but it can be useful for debugging purposes.
|
101
113
|
|
114
|
+
#### Second gathering phase: adding a build.sh file
|
115
|
+
|
102
116
|
One last thing before generating packages is to setup a build script. By default `gjp` will generate a spec file which assumes a `build.sh` script in the source folder of your project that contains all commands needed to build the package itself. At the moment, this needs to be done manually, but it will hopefully be automated in a future release.
|
103
117
|
|
104
118
|
Let's start a new gathering phase and add that:
|
@@ -112,19 +126,21 @@ Add the following lines:
|
|
112
126
|
cd src/commons-collections/commons-collections-3.2.1-src/
|
113
127
|
../../../kit/apache-maven-3.1.0/bin/mvn -Dmaven.repo.local=`readlink -e ../../../kit/m2` -s`readlink -e ../../../kit/m2/settings.xml` package
|
114
128
|
|
129
|
+
Note that `build.sh` gets called from the `gjp` project root, hence the `cd` line, and the Maven line was taken directly from `gjp mvn` output above and pasted verbatim.
|
115
130
|
Now complete the gathering:
|
116
131
|
|
117
132
|
gjp finish
|
118
133
|
cd ../../..
|
119
134
|
|
120
|
-
|
135
|
+
#### Generating archives and spec files
|
121
136
|
|
122
137
|
The following command will generate the kit spec:
|
123
138
|
|
124
139
|
gjp generate-kit-spec
|
125
140
|
less specs/galaxy-kit.spec
|
126
141
|
|
127
|
-
Nothing fancy here,
|
142
|
+
Nothing fancy here, the spec simply copies `kit` contents in a special directory to be available for later compilation of packages.
|
143
|
+
You can also edit the spec 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).
|
128
144
|
|
129
145
|
You can also generate the corresponding .tar.xz file with:
|
130
146
|
|
@@ -138,14 +154,14 @@ You can then generate the project spec and archive files provided you have a pom
|
|
138
154
|
gjp generate-package-archive commons-collections
|
139
155
|
less specs/commons-collections.spec
|
140
156
|
|
141
|
-
|
157
|
+
commons-collection BuldRequires galaxy-kit, its archive contains only source files and it will install any produced .jar file in `/usr/lib/java`. The archive is generated from `file_lists/commons-collections_input`, which lists source files. Output files are in `file_lists/commons-collections_output` and are used to compile the `%install` and `%files` sections of the project spec (by default only jar files are included, see `gjp generate-package-spec --help`).
|
142
158
|
|
143
159
|
less file_lists/commons-collections_input
|
144
160
|
less file_lists/commons-collections_output
|
145
161
|
|
146
162
|
Packages are ready to be submitted to an OBS project. As OBS integration is not yet implemented, refer to OBS documentation to do that.
|
147
163
|
|
148
|
-
|
164
|
+
#### Kit sources
|
149
165
|
|
150
166
|
If kit sources are needed for license compliance, some extra work is needed. Fortunately, finding jar source files and adding them to the kit is much easier than packaging its contents in proper RPMs!
|
151
167
|
|
@@ -166,9 +182,11 @@ More comprehensive support is planned in future releases.
|
|
166
182
|
|
167
183
|
You are advised to use [Maven Central](http://search.maven.org/) to search for sources and other information about projects.
|
168
184
|
|
169
|
-
###
|
185
|
+
### Troubleshooting
|
170
186
|
|
171
|
-
|
187
|
+
To know in which phase you are in, use `gjp status`.
|
188
|
+
|
189
|
+
`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 freely as long as the `gjp` tags are preserved. You can also delete commits and tags, effectively rewiding gjp history (just make sure to delete all tags pointing to a certain commit when you discard it).
|
172
190
|
|
173
191
|
## Motivation
|
174
192
|
|
@@ -207,3 +225,7 @@ Building software from a binary blob is unusual for Linux distros, and it surely
|
|
207
225
|
and cloned with:
|
208
226
|
|
209
227
|
git clone git@github.com:SilvioMoioli/gjp.git
|
228
|
+
|
229
|
+
## License
|
230
|
+
|
231
|
+
MIT license.
|
data/lib/gjp/project.rb
CHANGED
@@ -176,18 +176,26 @@ module Gjp
|
|
176
176
|
`git commit -m "#{message}"`
|
177
177
|
|
178
178
|
if tag != nil
|
179
|
-
|
180
|
-
$1
|
181
|
-
else
|
182
|
-
0
|
183
|
-
end
|
184
|
-
`git tag gjp_#{tag}_#{latest_count.to_i + 1}`
|
179
|
+
`git tag gjp_#{tag}_#{latest_tag_count(tag) + 1}`
|
185
180
|
end
|
186
181
|
end
|
187
182
|
|
188
|
-
# returns the last tag
|
189
|
-
|
190
|
-
|
183
|
+
# returns the last tag of its type corresponding to a
|
184
|
+
# gjp snapshot
|
185
|
+
def latest_tag(tag_type)
|
186
|
+
"gjp_#{tag_type}_#{latest_tag_count(tag_type)}"
|
187
|
+
end
|
188
|
+
|
189
|
+
# returns the last tag count of its type corresponding
|
190
|
+
# to a gjp snapshot
|
191
|
+
def latest_tag_count(tag_type)
|
192
|
+
`git tag`.split.map do |tag|
|
193
|
+
if tag =~ /^gjp_#{tag_type}_([0-9]+)$/
|
194
|
+
$1.to_i
|
195
|
+
else
|
196
|
+
0
|
197
|
+
end
|
198
|
+
end.max or 0
|
191
199
|
end
|
192
200
|
|
193
201
|
# reverts path contents as per latest tag
|
data/lib/gjp/version.rb
CHANGED