This is starting to sound pretty interesting. Could you flesh out this
example for those who are not maven gurus?
Regards,
Alan
Brett Porter wrote, On 10/31/2005 12:20 PM:
Yes, version ranges work, but simply omitting the version won't do it.
You could have [2.4,2.5) to pick up 2.4, 2.4-1, 2.4-2, etc. though.
Cheers,
Brett
On 11/1/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
Oh, I thought one of the big features of m2 was support for version
ranges.
BTW I find the name servlet-2.4-1.0 confusing myself.
-dain
On Oct 31, 2005, at 12:10 PM, Brett Porter wrote:
Actually, I meant a version of 2.4-1, 2.4-2.
I think there is advantages and disadvantages to each, so I'll let you
all decide what's best to work with. I just wanted to point out that
omitting the version won't work so it'll need to be specified, and
personally I'd find that a bit confusing presented with:
servlet-2.4-1.0.
- Brett
On 11/1/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
Just to clarify you mean we should have this:
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>servlet-2.4</artifactId>
<name>Geronimo :: Servlet API</name>
<version>1</version>
So the version number is a single non-dotted increasing integer?
BTW for most APIs we will be able to simply release a certified
version and never update, but for some APIs, like JavaMail, are
mostly implementation code, we will have to to patch releases. Also
if we get into the habit of adding JavaDoc documentation over time,
we will have to do periodic release to get the line numbers in the
debug symbols to match-up.
-dain
On Oct 30, 2005, at 9:29 PM, Brett Porter wrote:
I think this versioning has potential to be confusing, and the
omission of <version/> below doesn't actually do that - though it is
probably possible with a version of (,) that includes everything.
Personally, I'd prefer to have:
servlet-api-2.4
servlet-api-2.4-1
servlet-api-2.4-2
or similar.
(Technically, the last "build number" is used for rebuilding the
same
source code, not patching, but I think the alternative of 2.4.x
creates some more confusion and the above will work as intended).
Ideally, once 2.4 is compliant you don't need to release it again
anyway :)
Perhaps when we have proper spec-dependency handling in Maven it
might
be less confusing to use the geronimo-spec version number instead of
the spec number.
My 2cents...
- Brett
On 10/30/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
I know this has been talked about before on this list, but I'd like
to get the proposal in one place. With the help of Alan and Jason,
this is what I got:
Normally we just have this directory structure:
specs/trunk/servlet-2.2/src/
specs/trunk/servlet-2.4/src/
specs/trunk/jsp-2.4/src/
When we are happy with the specs we make a tag:
specs/tags/1.0/servlet-2.2/src/
specs/tags/1.0/servlet-2.4/src/
specs/tags/1.0/javamail-2.2-r2/src/
specs/tags/1.1/servlet-2.2/src/
specs/tags/1.1/servlet-2.4/src/
specs/tags/1.1/javamail-2.2-r2/src/
The pom for the specs would be like this:
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>servlet-2.4</artifactId>
<name>Geronimo :: Servlet API</name>
<version>1.0</version>
With maven 2 version ranges a user can just have the following and
maven will pick the most resent release of our spec automatically:
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>servlet-2.4</artifactId>
<dependency>
The current directory structure in https://svn.apache.org/repos/
asf/
geronimo/specs is very close to this. The only big change will
be to
add the version number of the specification to the directory name.
What do yo think?
-dain
