Salut,
Paul Sandoz wrote:
> Jeanfrancois Arcand wrote:
>>> How do you differentiate between the following with maven:
>>>
>>> - a stable and a dated snapshot release to the java.net maven repo;
>>
>> It is how you define your pom.xml:
>>
>>> <dependency>
>>> <groupId>com.sun.grizzly</groupId>
>>> <artifactId>grizzly-http-servlet</artifactId>
>>> <version>1.7.3.1</version>
>>> </dependency>
>>
>> for a stable version
>>
>
> Where is that particular pom.xml located?
It is located remotely inside the Maven repository:
http://download.java.net/maven/2/com/sun/grizzly/grizzly-http-servlet/1.7.3.1/grizzly-http-servlet-1.7.3.1.pom
Contains the resolved version. Before doing a release, I'm always
executing the following script (there is some maven plug in that can
probably do that, but I'm too lazy to learn them :-)). So when I cut a
release, I do:
% svn copy trunk tags/1_7_3_2
% run the followinhg script
======================
#!/bin/sh
# sed/changeword
prog=`basename $0`
old=1.7_SNAPSHOT
new=1.7.3.2
file=pom.xml
for FIL in `find . -name $file -exec grep -l $old {} \;`
do
echo 'Replacing in '$FIL
perl -i -pe s/$old/$new/g $FIL
done
=======================
% This steps replace the 1.7-SNAPSHOT by the proper version in all
pom.xml file.
% svn commit // commit the branch
% mvn deploy
The mvn deploy is the operation that takes care for me to:
(1) Create the remote folders layout on the remote repository
(2) Upload the new archetype (*.jar, -source.jar, md5/sha1)
My release is done. Now every day I've a script that does:
% svn checkout
% mvn install deploy
which upload the -SNAPSHOT.jar to the remote repository.
>
>
>> > <dependency>
>> > <groupId>com.sun.grizzly</groupId>
>> > <artifactId>grizzly-http-servlet</artifactId>
>> > <version>1.7-SNAPSHOT</version>
>> > </dependency>
>>
>> This is the nightly build. If you look here
>>
>> http://download.java.net/maven/2/com/sun/grizzly/grizzly-http-servlet/1.7-SNAPSHOT/
>>
>>
>> You can see Maven add a timestamp at the end to differentiate nightly
>> build.
>>
>
> How do you get maven to do that?
When adding in your pom.xml:
<version>1.7-SNAPSHOT</version>
Maven will download the following file:
http://download.java.net/maven/2/com/sun/grizzly/grizzly-http-servlet/1.7-SNAPSHOT/maven-metadata.xml
Inside that file, you have the information about the lastest SNASPHOT
release:
<versioning>
<snapshot>
<timestamp>20080422.234234</timestamp>
<buildNumber>23</buildNumber>
</snapshot>
<lastUpdated>20080422235222</lastUpdated>
</versioning>
Maven does that for you automatically.
>
>
>>
>>>
>>> - a general snapshot release installed to the local repository i.e.
>>> just doing mvn install.
>>
>> In you local repo, you will not have any timestamp at the end.
>>
>> Local: 1.7-SNAPSHOT
>> Remote: 1.7-SNAPSHOT-.....
>>
>
> OK.
>
>
>>
>>>
>>> I notice the following in grizzly/pom.xml:
>>>
>>> <properties>
>>> <grizzly-version>1.7-SNAPSHOT</grizzly-version>
>>> <grizzly-released-version>1.7.3</grizzly-released-version>
>>> <grizzly-next-version>1.8.0</grizzly-next-version>
>>> <junit-version>3.8.1</junit-version>
>>> <grizzly-jruby-version>0.1.2</grizzly-jruby-version>
>>> <maven-plugin.version>1.0.0</maven-plugin.version>
>>> </properties>
>>>
>>> I am guessing by default 1.7-SNAPSHOT will be chosen as from here:
>>>
>>> <modelVersion>4.0.0</modelVersion>
>>> <groupId>com.sun.grizzly</groupId>
>>> <artifactId>grizzly-project</artifactId>
>>> <packaging>pom</packaging>
>>> <name>grizzly-project</name>
>>> <version>1.7-SNAPSHOT</version>
>>>
>>>
>>> In the modules, say for example, modules/grizzly/pom.xml i notice:
>>>
>>> <parent>
>>> <groupId>com.sun.grizzly</groupId>
>>> <artifactId>grizzly-project</artifactId>
>>> <version>1.7-SNAPSHOT</version>
>>> <relativePath>../../pom.xml</relativePath>
>>> </parent>
>>>
>>> and you are duplicating "1.7-SNAPSHOT" defined in the parent pom.xml.
>>> Is that necessary?
>>
>> That's because Maven is broken if you put {grizzly.version} instead of
>> 1.7-SNAPSHOT (at least when I've worked on it). Ideally, it should be
>> the {grizzly.version} but I've gived up trying to fix it :-). Do you
>> know how to fix that?
>>
>
> As you may guess by my questions i do not :-)
>
> I am looking at the Grizzly maven infrastructure as a model for Jersey.
Let me know if I can be of any help. So far our build haven't suffered
any problems related to Maven.
A+
-- jeanfrancois
>
> Paul.
>