1 |
>> This is a blantant copy and paste, but I thought it might be |
2 |
interesting, useful. |
3 |
|
4 |
|
5 |
The other thing people talk alot about is other build tools that are better |
6 |
than Ant, e.g. Gant, Raven <http://raven.rubyforge.org/> (ruby build scripts |
7 |
for Java) or some other one I heard of recently – ah-ha! found it – |
8 |
Gosling<https://gosling.dev.java.net/>(I’m sure I read a recent |
9 |
article about it somewhere, that pointed to a |
10 |
newer website?) that lets you write your build in Java and then just wraps |
11 |
Ant! Bizzaro. |
12 |
|
13 |
Another one is that people are concerned about their build tool changing |
14 |
itself over time, and so their build is not necessarily stable and |
15 |
reproducible. I for one love the idea of self upgrading software – hey, it’s |
16 |
one step closer to the end of the |
17 |
world<http://en.wikipedia.org/wiki/Skynet_%28fictional%29>right? Well |
18 |
I for one welcome our build tool |
19 |
overlords.<http://itre.cis.upenn.edu/%7Emyl/languagelog/archives/000399.html>But |
20 |
seriously, I think that the advantage of having the build tool upgrade |
21 |
itself and getting the latest bug fixes and feature updates, outweighs the |
22 |
disadvantage of the build breaking one day. So what? – You take an hour out, |
23 |
or half a day, or even a day, and fix it! |
24 |
|
25 |
Buut, if you work in a stiff, rigid environment, or work for NASA or the |
26 |
militar or something, then there’s a way around this as well. This is also |
27 |
the suggested best practice for dealing with plugins. (O.k., I remember |
28 |
reading this information somewhere, but it was harder to find again than i |
29 |
thought.) |
30 |
|
31 |
1. Run mvn help:effective-pom -Doutput=effective.pom this produces a list |
32 |
of the plugin versions your project is currently using. |
33 |
2. Open effective.pom and copy the build->pluginManagement section into |
34 |
your pom, optionally deleting the configuration and just keeping the goupid, |
35 |
artifactid and version. |
36 |
3. Make sure your project packages, to test you got the pluginManagement |
37 |
right. |
38 |
4. Rename your local repository to repository.back |
39 |
5. Run mvn dependency:go-offline – this will download all plugins and |
40 |
their dependencies for your project, into a clean repository. |
41 |
6. Move the repository into your project directory. |
42 |
7. Add the project repository to your POM as described above. |
43 |
8. Try running your mvn package with the –offline option and make sure |
44 |
everythings ok. |
45 |
9. Rename your backup from repository.bak back to repository. |
46 |
10. Commit. |
47 |
11. Done! You should be able to now build the project off of a fresh |
48 |
checkout and an empty repository. |
49 |
12. If you’ve gone this far, you may as well also commit the version of |
50 |
Maven your using into your source control as well, in a directory such as |
51 |
/tools/maven. |
52 |
|
53 |
*** |
54 |
|
55 |
When MDEP-177 <http://jira.codehaus.org/browse/MDEP-177> is addressed, this |
56 |
will be much easier to do. |
57 |
|
58 |
On another note, as far as running off-line is concerned, the other really |
59 |
neat-o thing you should definately do if there are more than two of you on |
60 |
location (or if you’re keen to share snapshots easily), is setup a local |
61 |
Maven repository cache/proxy/mirror using Nexus <http://nexus.sonatype.org/>. |
62 |
IMO, don’t bother trying Artefactory or the other one, Nexus is da’ bomb. |
63 |
|
64 |
Copied from http://stubbisms.wordpress.com/ |