date:20061219

Ok, I'm now looking into it. I'll try and pull down central from  
ibiblio at some point to do it locally, but I will likely muddle with  
repository.maven.org too. Please let me know if that's a problem.


I have scheduled '1.0'. This reflects the 1.0-SNAPSHOT in the POM. It  
is not the final version, we can bicker about its quality when the 72  
issues get fixed. Or when we decide enough are fixed for it to be  
released and well post poone the rest. I'm just interested in broad  
scheduling for now.


All the things listed in this thread so far are there with a high  
priority, except for the still vague 'design flaws' which I just  
can't wait to hear about.


Cheers,
Brett

Re: Getting together a release



On 19 Dec 06, at 9:14 PM 19 Dec 06, Joakim Erdfelt wrote:


Jason van Zyl wrote:


On 19 Dec 06, at 4:31 PM 19 Dec 06, Brett Porter wrote:


Hi,

I am going to start looking into the issue with Archiva hanging on
repository.maven.org, then look at getting a release together, since
there has been a spike in interest and we can't really just  
recommend

people grab it from SVN.

Other than that issue, does anyone have any "must fixes" for a  
release?




Two concrete show stoppers I think are that it doesn't convert
repositories properly. I've found several things and the groovy
conversion problem that cropped up a few days ago.

Even on local setups Archiva will fall over. Joakim has found this
with his install and I have found it with mine.

Over the course of December the only things that have been worked on
are Security, some conversion to common stuff, and the logo. No work
done on the conversion, the proxy, or the reporting. I just honestly
don't think it does anyone any service releasing it like this.

I've been trying to get archiva pulled into a decent profiler so I can
track down the apparent memory leak we have.  The reason there hasn't
been any commits is because I don't have a solution yet. ;-)

As for the release.  I think making an 1.0-alpha-1 release would be  
good

at this point.


Yup, an alpha is fine.


It will help if we have more people banging away at it.
Having more test cases.  Having more jiras around it.  We know form  
our

own testing what needs to be fixed.  We can start with that list for
1.0-alpha-2.  By then we'll hopefully have more input from other  
peoples

out there.



Sounds perfectly reasonable.

Jason.


- Joakim

Re: Getting together a release

2006-12-19 Thread Joakim Erdfelt

Jason van Zyl wrote:
>
> On 19 Dec 06, at 4:31 PM 19 Dec 06, Brett Porter wrote:
>
>> Hi,
>>
>> I am going to start looking into the issue with Archiva hanging on
>> repository.maven.org, then look at getting a release together, since
>> there has been a spike in interest and we can't really just recommend
>> people grab it from SVN.
>>
>> Other than that issue, does anyone have any "must fixes" for a release?
>>
>
> Two concrete show stoppers I think are that it doesn't convert
> repositories properly. I've found several things and the groovy
> conversion problem that cropped up a few days ago.
>
> Even on local setups Archiva will fall over. Joakim has found this
> with his install and I have found it with mine.
>
> Over the course of December the only things that have been worked on
> are Security, some conversion to common stuff, and the logo. No work
> done on the conversion, the proxy, or the reporting. I just honestly
> don't think it does anyone any service releasing it like this.
I've been trying to get archiva pulled into a decent profiler so I can
track down the apparent memory leak we have.  The reason there hasn't
been any commits is because I don't have a solution yet. ;-)

As for the release.  I think making an 1.0-alpha-1 release would be good
at this point.  It will help if we have more people banging away at it. 
Having more test cases.  Having more jiras around it.  We know form our
own testing what needs to be fixed.  We can start with that list for
1.0-alpha-2.  By then we'll hopefully have more input from other peoples
out there.

- Joakim

Re: versioning

Seems there is some misunderstanding here, I agree in many things you
said, extend version schemas, allow different schemas to be pluggable
if possible, set a default schema as "standard",...
I'd just prefer have xml syntax over string parsing and encourage
people to use whatever the standard we choose.

On 12/19/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:

Carlos Sanchez wrote:
> On 12/19/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:
>> Carlos Sanchez wrote:
>> > the repository has some rules and you have to follow them to be
>> > manageable, eg. you name jars artifactId-version.jar and not
>> > otherwise. If there are version rules you'd have to follow, and I
>> > don't see the problem in having a standardized version convention, as
>> >  we have standardized folder names.
>>
>> As I said before:
>>
>> > The problem is basically that this simply isn't powerful enough to
>> > cover all the various versioning schemes there are in the wild.
>
> 4 or more sections will cover almost all the versioning schemas

What sections?

If you're talking about the 4 sub-elements of the pom, why limit to 4?
We've got a good solution now that allows for any number of 'sections'.

>> > Suggesting forcing everybody to conform to your idea of versioning
>> > isn't at all helpful; similarly imposing a complex mapping between
>> > upstream and maven versions for a project is unattractive.
>
> projects shouldn't care and will end benefiting from standardization
> as they did with folder names. We need to look to other versioning
> standards out there (eg. OSGi) instead of inventing a new one.
> if a non maven project is 1.0-alpha1 we'd simply use 1/0/alpha/1 and
> we can sort the sections

Folder names? For what?
Where would you use 1/0/alpha/1?

I'm pro standardization, and we should set an example, but I disagree that we 
should limit
or enforce our version scheme to OSGi or any other schemes out there. This will 
limit the
applicability of maven in the field. It should be 'convention over 
configuration', meaning that
if you follow 'our' standards, it's easy; if you have other company policies, 
you should be able to
apply them to maven aswell.

We could adopt the OSGi versioning scheme when developing maven (although we 
already have one
which is pretty similar), but I do not want to impose that on maven users.

I'm finding that you're the only one objecting somewhat, and can't find a real 
reason or usecase
that contradicts my proposal in any way. All I'm suggesting is that we replace 
the version
implementation with something that's more flexible, backwards compatible, and 
can be used for any
known scheme. I'm just asking for usecases where the solution won't work.

Extending the POM to add configuration for custom version schemes is another 
(though related)
discussion, and can be added later on, though I doubt if it's necessary.

-- Kenney
>
>>
>> Which part do you disagree with?
>>
>>
>> --
>> Richard van der Hoff <[EMAIL PROTECTED]>
>> Telephony Gateways Project Manager
>> Tel: +44 (0) 845 666 7778
>> http://www.mxtelecom.com
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SV: Mojo and it's own dependencies

On 31 Oct 06, at 9:06 AM 31 Oct 06, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:



Hi

I am now able to look at it. I suppose the what you refer to as  
"common project called maven-ant" is not the maven-ant plugin? What  
is the svn of this?




Long delay, but I was just able to get the sample Ant-based mojo  
today. It was work for a client and it had to get some approval and  
be cleaned up but you can now find it here:


http://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/axis-maven-plugin

It's a Maven plugin that is completely written in Ant script. The  
plugin resources are unpacked in the target directory so that you can  
reference physical files in your Ant scripts, it has full access to  
the various classpath entries in the same way the Ant Run plugin  
does, and it has an example of loading custom taskdefs. In this case  
taskdefs from ant-contrib. So this comes from a production build  
where knowledge of Ant must be leveraged and this now shows you can  
do whatever you want with Ant, yet allows you contain the inherent un- 
maintainability of Ant in a plugin and have it be completely  
reusable. From the perspective of the Maven users it doesn't matter  
now whether the plugin is written in Ant script, Ruby, or Java. It's  
all the same, and configured the same way for users of Maven. I have  
not back-ported the changes required to make this run in 2.0.x. I  
will attempt to do this but it won't happen before the new year. I  
need to makes some pictures of integration tests across versions and  
create some more ITs before I attempt to back-port the changes. At  
the very least, you can see how it works.


Jason.



Hermod

-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 11:36 PM
To: Maven Developers List
Subject: Re: SV: Mojo and it's own dependencies



On 19 Oct 06, at 5:19 PM 19 Oct 06, Hermod Opstvedt wrote:


Hi

Yeah, now we're talking. I need to setup a classpath for another
java class
that is to be run by an ant based mojo. So setting up the first
mojo with
the same dependencies as it, I will be able to supply the Ant
script that as
a classpath variable (Sneaky but does the trick)



I need to document it, and you can help me with it, but I have that
working with the new ant-based plugin stuff that I've committed.

What I got working was an axis plugin entirely written in Ant. So a
plugin script used in an ant-based plugin now has access to the
compile, test, runtime and plugin classpath.

I reworked all the ant stuff and combined John and Kenney's work and
put it in a common project called maven-ant.

I'll dig you up a sample if you document it :-)

It fully works and has been run with a sizable ant script.

Jason.


Hermod

-Opprinnelig melding-
Fra: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sendt: 19. oktober 2006 21:30
Til: Maven Developers List
Emne: Re: Mojo and it's own dependencies


On 19 Oct 06, at 1:50 PM 19 Oct 06, Hermod Opstvedt wrote:


Hi

Is there a Maven helper class that can be called from a Mojo that
will give
the Mojo access to it's own dependencies?



You can use the expression ${plugin.artifacts} i.e.

/**
  * @parameter expression="${plugin.artifacts}"
  */
private List pluginArtifacts;

Is that what you're looking for?

Jason.


Hermod


 
-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *  
* * * *


This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that the DnB  
NOR Group
cannot accept any payment orders or other legally binding  
correspondence with

customers as a part of an email.

This email message has been virus checked by the anti virus  
programs used

in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *  
* * * *



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

re: Feedback Needed on Release Reporting Tool

2006-12-19 Thread natalie.burdick

John

Just a few small suggestions:

In the menu on the far left:

Overview
Introduction 
Usage 
FAQ 
Examples
Generating Votes Report 
Generating Resolved Issues Report 
Generating A Custom Report 

suggest:

Overview
Introduction 
Usage 
FAQs 
Examples
Generating a Votes Report 
Generating a Resolved Issues Report 
Generating a Custom Report 

On the the descriptor for: License Header Results -- relabeling to: Artifact 
License Info

Also, for consistency -- some casing changes:

Issues Resolved For This Release -- List of Issues Resolved in this Release
List of deliverables -- List of Release Deliverables

Lastly, how about using one of the newer Built by Maven logos?



--- Original Message ---
 
From: "John Tolentino" <[EMAIL PROTECTED]>
To: "Maven Developers List" 
Date: Tue, 19 Dec 2006 11:19:44 +0800
Subject: Feedback Needed on Release Reporting Tool
 
Hi Everyone,

Been working on a tool to generate reports for release candidates and
this is a mock of what it should look like:
http://people.apache.org/~jtolentino/release-reports/MockReport.html

We can send this generated page to the dev list when we call for a release.

I appreciate any feedback so I can improve the reporting (and before I
go further into implementation).

Thanks,
John

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Getting together a release

2006-12-19 Thread Max Bowsher

Brett Porter wrote:
> Hi,
> 
> I am going to start looking into the issue with Archiva hanging on
> repository.maven.org, then look at getting a release together, since
> there has been a spike in interest and we can't really just recommend
> people grab it from SVN.
> 
> Other than that issue, does anyone have any "must fixes" for a release?

I don't remember where I saw it, but I think someone mentioned that the
proxying functionality was going to disappear from /proxy and be merged
into the /repository URLs. If that's correct, then getting such a major
URL change done before a release would be most desirable.

Other than that, the health report seems rather broken, in that is shows
a large quantity of errors which don't seem to correspond to reality, in
my experience. (see my message "Health Report woes" on archiva-users@).
If that's actually happening to everyone, not just me, then it probably
bears investigation before a release.

Max.

Re: downloading eclipse runtime binary or RCP delta pack

2006-12-19 Thread Barrie Treloar

On 12/20/06, Graham Leggett <[EMAIL PROTECTED]> wrote:

On Tue, December 19, 2006 5:15 pm, Bhupendra Bhardwaj wrote:

>> The most simple solution right now is probably to add
>> http://repo1.maven.org/eclipse/ to your list of repositories in
>> settings.xml.

> Not really. Because the solution I was looking for was to package my RCP
> app
> for all platforms and the repo1.maven.org/eclipse only has swt jar for
> win32
> platform.

And the solution to that is to point eclipse:make-artifacts at the eclipse
deltapack, and import those jars into the repository as well. This worked
for us.

Whoever created repo1.maven.org/eclipse can also add the delta pack for us too.

Pretty please.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

problem with separation of "java" and "resources"

2006-12-19 Thread Joerg Hohwiller

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there everybody,

from the separation of concerns view of the maven plugins I can see the point in
separating "java" and "resources" in src/main and src/test.

- From the users point of view this is quite ugly:

- -If you are looking at a java file and want to look at a related resource, you
have to navigate all the way up out of "java" and back into "resources" down to
the same package. Developers are used to find them right beside their java 
files.

- -The situation gets even worse if you look at package refactoring: You have to
 perform the same refactoring twice. If you make a little spelling mistake (or
you simply forget to do it twice) you break your code.

Maybe I am using the wrong IDE (eclipse), but ...

What are the arguments for this separation? Isn't the resources plugin generic
enough to include all files except "*.java" from "java"? Could this be done by
configuration in the POM? (the super POM???)

Regards
  Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFiGoBmPuec2Dcv/8RAsukAJ4k+CWrrCYzlOFR2k8mMFQIOyLUMACfRZs2
uf+RM6+QFoPUmPJtbgyYDX8=
=QFMc
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven2 and NTLM



On 19/12/2006, at 9:39 PM, Steve Loughran wrote:


Anyone interested in working on this?


Thanks for volunteering! :)

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Getting together a release



On 19 Dec 06, at 4:31 PM 19 Dec 06, Brett Porter wrote:


Hi,

I am going to start looking into the issue with Archiva hanging on  
repository.maven.org, then look at getting a release together,  
since there has been a spike in interest and we can't really just  
recommend people grab it from SVN.


Other than that issue, does anyone have any "must fixes" for a  
release?




Two concrete show stoppers I think are that it doesn't convert  
repositories properly. I've found several things and the groovy  
conversion problem that cropped up a few days ago.


Even on local setups Archiva will fall over. Joakim has found this  
with his install and I have found it with mine.


Over the course of December the only things that have been worked on  
are Security, some conversion to common stuff, and the logo. No work  
done on the conversion, the proxy, or the reporting. I just honestly  
don't think it does anyone any service releasing it like this.


Jason.


- Brett

RE: Getting together a release

2006-12-19 Thread Ryan, Scott D

I think one of the "got to haves" is the ability to proxy across
artifacts even if the checksum is bad.  I know there are a couple of
patches out there to fix this but without this in the release it makes
usefulness of Archiva pretty minimal.  Other than that we have been
using the project to support our maven 2 build system for about 30
projects and an automated build system and it has worked flawlessly.  I
love the security features and would love to see more reports.

Another thing I have noticed is that the used by information does not
seem to be very accurate.  Most of the time it is only filled in if the
artifacts are in the same group.

Thanks for a great project and I look forward to the first release
soon.. 

Scott D. Ryan
Senior Java Developer/Architect

-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, December 19, 2006 2:43 PM
To: archiva-dev@maven.apache.org
Subject: Re: Getting together a release

On 19 Dec 06, at 4:31 PM 19 Dec 06, Brett Porter wrote:

> Hi,
>
> I am going to start looking into the issue with Archiva hanging on 
> repository.maven.org, then look at getting a release together, since 
> there has been a spike in interest and we can't really just recommend 
> people grab it from SVN.
>
> Other than that issue, does anyone have any "must fixes" for a 
> release?
>

It must go back to an alpha, and I don't think it's even close to  
being able to being released.

It's is totally unstable on central. Drawing in people to a release I  
don't think is the right thing to do.

I will respond to your previous email about the design flaws but I  
don't think a release is wise. It is totally not ready for a release  
even as an alpha.

Jason.

> - Brett
>

- - - - - - - - - - - - - - - - - - - - - - - - - -
This message is intended only for the personal and confidential use of the 
designated recipient(s) named. If you are not the intended recipient of this 
message, you are hereby notified that any review, dissemination, distribution 
or copying of this message is strictly prohibited. This communication is for 
information purposes only and should not be regarded as an offer to sell or as 
a solicitation of an offer to buy any financial product, an official 
confirmation of any transaction, or as an official statement of Aurora Loan 
Services. Email transmission cannot be guaranteed to be secure or error-free. 
Therefore, we do not represent that this information is complete or accurate 
and it should not be relied upon as such. All information is subject to change 
without notice.

Re: versioning

Carlos Sanchez wrote:

On 12/19/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:

Carlos Sanchez wrote:
> the repository has some rules and you have to follow them to be
> manageable, eg. you name jars artifactId-version.jar and not
> otherwise. If there are version rules you'd have to follow, and I
> don't see the problem in having a standardized version convention, as
>  we have standardized folder names.

As I said before:

> The problem is basically that this simply isn't powerful enough to
> cover all the various versioning schemes there are in the wild.

4 or more sections will cover almost all the versioning schemas

What sections?

If you're talking about the 4 sub-elements of the pom, why limit to 4?
We've got a good solution now that allows for any number of 'sections'.

> Suggesting forcing everybody to conform to your idea of versioning
> isn't at all helpful; similarly imposing a complex mapping between
> upstream and maven versions for a project is unattractive.

projects shouldn't care and will end benefiting from standardization
as they did with folder names. We need to look to other versioning
standards out there (eg. OSGi) instead of inventing a new one.
if a non maven project is 1.0-alpha1 we'd simply use 1/0/alpha/1 and
we can sort the sections

Folder names? For what?
Where would you use 1/0/alpha/1?

I'm pro standardization, and we should set an example, but I disagree that we 
should limit
or enforce our version scheme to OSGi or any other schemes out there. This will 
limit the
applicability of maven in the field. It should be 'convention over 
configuration', meaning that
if you follow 'our' standards, it's easy; if you have other company policies, 
you should be able to
apply them to maven aswell.

We could adopt the OSGi versioning scheme when developing maven (although we 
already have one
which is pretty similar), but I do not want to impose that on maven users.

I'm finding that you're the only one objecting somewhat, and can't find a real 
reason or usecase
that contradicts my proposal in any way. All I'm suggesting is that we replace 
the version
implementation with something that's more flexible, backwards compatible, and 
can be used for any
known scheme. I'm just asking for usecases where the solution won't work.

Extending the POM to add configuration for custom version schemes is another 
(though related)
discussion, and can be added later on, though I doubt if it's necessary.

-- Kenney

Which part do you disagree with?

--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Getting together a release



On 19 Dec 06, at 4:31 PM 19 Dec 06, Brett Porter wrote:


Hi,

I am going to start looking into the issue with Archiva hanging on  
repository.maven.org, then look at getting a release together,  
since there has been a spike in interest and we can't really just  
recommend people grab it from SVN.


Other than that issue, does anyone have any "must fixes" for a  
release?




It must go back to an alpha, and I don't think it's even close to  
being able to being released.


It's is totally unstable on central. Drawing in people to a release I  
don't think is the right thing to do.


I will respond to your previous email about the design flaws but I  
don't think a release is wise. It is totally not ready for a release  
even as an alpha.


Jason.


- Brett

Re: ApacheCon Talks

I'll submit a "Maven Archiva", a "Project Visibility with Maven" talk  
and a "Apache Repository BOF". If anyone is interested on working on  
them with me, just ping me.


- Brett

On 20/12/2006, at 1:47 AM, Jason van Zyl wrote:


Hi,

Just checking in with folks to see if anyone is planning ApacheCon  
talks. I'm planning on doing the introduction to Maven talk, and  
I'm talking with Rod Coffin about working with him on his  
Enterprise Maven talk and I would also like to once again organize  
the BOFs I did the last time, "Maven Community BOF", and  
"Enterprise Maven BOF". Just trying to organize with others before  
submitting everything.


Jason.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Getting together a release


Hi,

I am going to start looking into the issue with Archiva hanging on  
repository.maven.org, then look at getting a release together, since  
there has been a spike in interest and we can't really just recommend  
people grab it from SVN.


Other than that issue, does anyone have any "must fixes" for a release?

- Brett

Re: ApacheCon Talks



On 19 Dec 06, at 2:14 PM 19 Dec 06, Tom Huybrechts wrote:


On 12/19/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

Jason van Zyl wrote:
>
> On 19 Dec 06, at 12:28 PM 19 Dec 06, Steve Loughran wrote:
>
>> Jason van Zyl wrote:
>>> Hi,
>>> Just checking in with folks to see if anyone is planning  
ApacheCon

>>> talks.
>>
>> 1. "fear the repository police". We will pick people in the  
audience

>> and beat them with rolled up copies of the pom schema until they
>> promise not to publish invalid metadata. we will start off with  
"Is

>> there anyone here who works on commons-logging?",
>>
>
> It will soon be impossible to publish invalid metadata.

Speaking as someone who also works on commons-logging (*ducking*), is
there work being done on a maven-repo-compliant-plugin or something
similar that could be run on every pom that is submitted through
MAVENUPLOAD? I.e. confirming to the rules set up here:
   http://maven.apache.org/guides/mini/guide-ibiblio-upload.html

If not, I think I could put something together.


I have some play-stuff in the maven-repositorytools-plugin
(mojo-sandbox) as part of a bundle-deploy mojo. It includes iterating
over imports to see if they are provided by a dependency, and also
some POM element checking.



Yah, your stuff should find its way into Archiva, which is where I'm  
going to place my submission work, and projects which do not have  
their transitive closures get the boot.


Jason.


tom



>> 2. Something on big project ant; ivy, import &c. Mostly how to use
>> these concepts effectively and so have a scaled build that doesnt
>> force you to throw away all your existing build process.
>
> Interesting as one of my topics in the Maven Enterprise BOF is the
> conversion of huge project that basically retained 95% of it's Ant
> scripting, except it is packaged up in Maven plugins to be  
maintainable,

> and understandable.
>
>> 3. Work related: something on virtualization; how to use amazon  
EC2 to
>> host apache httpd and the like, what works, what doesn't  
(persistence,
>> mainly). We'd use smartfrog to manage the deployments and maybe  
show
>> using linuxcoe/instalinux to create the amazon Xen image at  
build time

>> based on the RPM list you have under SCM.
>>
>> 4. I've invited the TestNG people and Xavier of Ivy fame to submit
>> proposals. Both would be good. BTW, there's lots of unhappiness in
>> TestNG-users about SureFire; someone should talk to them about  
their

>> needs.
>>
>
> Kenney is working on the surefire plugin as we speak.
>
>> -Steve
>>


--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

On 19 Dec 06, at 2:08 PM 19 Dec 06, Carlos Sanchez wrote:

On 12/19/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:

Carlos Sanchez wrote:
> the repository has some rules and you have to follow them to be
> manageable, eg. you name jars artifactId-version.jar and not
> otherwise. If there are version rules you'd have to follow, and I
> don't see the problem in having a standardized version  
convention, as

>  we have standardized folder names.

As I said before:

> The problem is basically that this simply isn't powerful enough to
> cover all the various versioning schemes there are in the wild.

4 or more sections will cover almost all the versioning schemas

I'm all for something standard but I think what we have, RPM spec  
versioning, and OSGi are unlikely to converge anytime soon. We need  
support many schemes, so as long as ours can evolve which is must as  
its fragile ATM.

> Suggesting forcing everybody to conform to your idea of versioning
> isn't at all helpful; similarly imposing a complex mapping between
> upstream and maven versions for a project is unattractive.

projects shouldn't care and will end benefiting from standardization
as they did with folder names. We need to look to other versioning
standards out there (eg. OSGi) instead of inventing a new one.
if a non maven project is 1.0-alpha1 we'd simply use 1/0/alpha/1 and
we can sort the sections

Which part do you disagree with?

--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ApacheCon Talks


On 12/19/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

Jason van Zyl wrote:
>
> On 19 Dec 06, at 12:28 PM 19 Dec 06, Steve Loughran wrote:
>
>> Jason van Zyl wrote:
>>> Hi,
>>> Just checking in with folks to see if anyone is planning ApacheCon
>>> talks.
>>
>> 1. "fear the repository police". We will pick people in the audience
>> and beat them with rolled up copies of the pom schema until they
>> promise not to publish invalid metadata. we will start off with "Is
>> there anyone here who works on commons-logging?",
>>
>
> It will soon be impossible to publish invalid metadata.

Speaking as someone who also works on commons-logging (*ducking*), is
there work being done on a maven-repo-compliant-plugin or something
similar that could be run on every pom that is submitted through
MAVENUPLOAD? I.e. confirming to the rules set up here:
   http://maven.apache.org/guides/mini/guide-ibiblio-upload.html

If not, I think I could put something together.


I have some play-stuff in the maven-repositorytools-plugin
(mojo-sandbox) as part of a bundle-deploy mojo. It includes iterating
over imports to see if they are provided by a dependency, and also
some POM element checking.

tom



>> 2. Something on big project ant; ivy, import &c. Mostly how to use
>> these concepts effectively and so have a scaled build that doesnt
>> force you to throw away all your existing build process.
>
> Interesting as one of my topics in the Maven Enterprise BOF is the
> conversion of huge project that basically retained 95% of it's Ant
> scripting, except it is packaged up in Maven plugins to be maintainable,
> and understandable.
>
>> 3. Work related: something on virtualization; how to use amazon EC2 to
>> host apache httpd and the like, what works, what doesn't (persistence,
>> mainly). We'd use smartfrog to manage the deployments and maybe show
>> using linuxcoe/instalinux to create the amazon Xen image at build time
>> based on the RPM list you have under SCM.
>>
>> 4. I've invited the TestNG people and Xavier of Ivy fame to submit
>> proposals. Both would be good. BTW, there's lots of unhappiness in
>> TestNG-users about SureFire; someone should talk to them about their
>> needs.
>>
>
> Kenney is working on the surefire plugin as we speak.
>
>> -Steve
>>


--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning


On 12/19/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:

Carlos Sanchez wrote:
> the repository has some rules and you have to follow them to be
> manageable, eg. you name jars artifactId-version.jar and not
> otherwise. If there are version rules you'd have to follow, and I
> don't see the problem in having a standardized version convention, as
>  we have standardized folder names.

As I said before:

> The problem is basically that this simply isn't powerful enough to
> cover all the various versioning schemes there are in the wild.


4 or more sections will cover almost all the versioning schemas


> Suggesting forcing everybody to conform to your idea of versioning
> isn't at all helpful; similarly imposing a complex mapping between
> upstream and maven versions for a project is unattractive.


projects shouldn't care and will end benefiting from standardization
as they did with folder names. We need to look to other versioning
standards out there (eg. OSGi) instead of inventing a new one.
if a non maven project is 1.0-alpha1 we'd simply use 1/0/alpha/1 and
we can sort the sections



Which part do you disagree with?


--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ApacheCon Talks


On 19 Dec 06, at 1:31 PM 19 Dec 06, Carlos Sanchez wrote:


On 12/19/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

Jason van Zyl wrote:
>
> On 19 Dec 06, at 12:28 PM 19 Dec 06, Steve Loughran wrote:
>
>> Jason van Zyl wrote:
>>> Hi,
>>> Just checking in with folks to see if anyone is planning  
ApacheCon

>>> talks.
>>
>> 1. "fear the repository police". We will pick people in the  
audience

>> and beat them with rolled up copies of the pom schema until they
>> promise not to publish invalid metadata. we will start off with  
"Is

>> there anyone here who works on commons-logging?",
>>
>
> It will soon be impossible to publish invalid metadata.

Speaking as someone who also works on commons-logging (*ducking*), is
there work being done on a maven-repo-compliant-plugin or something
similar that could be run on every pom that is submitted through
MAVENUPLOAD? I.e. confirming to the rules set up here:
   http://maven.apache.org/guides/mini/guide-ibiblio-upload.html

If not, I think I could put something together.


nothing exists



http://svn.apache.org/repos/asf/maven/components/trunk/maven-project/ 
src/main/java/org/apache/maven/project/validation/


If you have more ideas for validation think about adding them there  
as anything submitted must pass the standard validator. Or if you  
have any other tools make them plexus components. I'm working on  
Archiva in general but artifact submission via a web service is the  
thing I'm prototyping. When it works JIRA goes away for uploading  
bundles.


Jason.



>> 2. Something on big project ant; ivy, import &c. Mostly how to use
>> these concepts effectively and so have a scaled build that doesnt
>> force you to throw away all your existing build process.
>
> Interesting as one of my topics in the Maven Enterprise BOF is the
> conversion of huge project that basically retained 95% of it's Ant
> scripting, except it is packaged up in Maven plugins to be  
maintainable,

> and understandable.
>
>> 3. Work related: something on virtualization; how to use amazon  
EC2 to
>> host apache httpd and the like, what works, what doesn't  
(persistence,
>> mainly). We'd use smartfrog to manage the deployments and maybe  
show
>> using linuxcoe/instalinux to create the amazon Xen image at  
build time

>> based on the RPM list you have under SCM.
>>
>> 4. I've invited the TestNG people and Xavier of Ivy fame to submit
>> proposals. Both would be good. BTW, there's lots of unhappiness in
>> TestNG-users about SureFire; someone should talk to them about  
their

>> needs.
>>
>
> Kenney is working on the surefire plugin as we speak.
>
>> -Steve
>>


--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ApacheCon Talks


On 12/19/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

Jason van Zyl wrote:
>
> On 19 Dec 06, at 12:28 PM 19 Dec 06, Steve Loughran wrote:
>
>> Jason van Zyl wrote:
>>> Hi,
>>> Just checking in with folks to see if anyone is planning ApacheCon
>>> talks.
>>
>> 1. "fear the repository police". We will pick people in the audience
>> and beat them with rolled up copies of the pom schema until they
>> promise not to publish invalid metadata. we will start off with "Is
>> there anyone here who works on commons-logging?",
>>
>
> It will soon be impossible to publish invalid metadata.

Speaking as someone who also works on commons-logging (*ducking*), is
there work being done on a maven-repo-compliant-plugin or something
similar that could be run on every pom that is submitted through
MAVENUPLOAD? I.e. confirming to the rules set up here:
   http://maven.apache.org/guides/mini/guide-ibiblio-upload.html

If not, I think I could put something together.


nothing exists



>> 2. Something on big project ant; ivy, import &c. Mostly how to use
>> these concepts effectively and so have a scaled build that doesnt
>> force you to throw away all your existing build process.
>
> Interesting as one of my topics in the Maven Enterprise BOF is the
> conversion of huge project that basically retained 95% of it's Ant
> scripting, except it is packaged up in Maven plugins to be maintainable,
> and understandable.
>
>> 3. Work related: something on virtualization; how to use amazon EC2 to
>> host apache httpd and the like, what works, what doesn't (persistence,
>> mainly). We'd use smartfrog to manage the deployments and maybe show
>> using linuxcoe/instalinux to create the amazon Xen image at build time
>> based on the RPM list you have under SCM.
>>
>> 4. I've invited the TestNG people and Xavier of Ivy fame to submit
>> proposals. Both would be good. BTW, there's lots of unhappiness in
>> TestNG-users about SureFire; someone should talk to them about their
>> needs.
>>
>
> Kenney is working on the surefire plugin as we speak.
>
>> -Steve
>>


--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ApacheCon Talks

2006-12-19 Thread Dennis Lundberg


Jason van Zyl wrote:


On 19 Dec 06, at 12:28 PM 19 Dec 06, Steve Loughran wrote:


Jason van Zyl wrote:

Hi,
Just checking in with folks to see if anyone is planning ApacheCon 
talks.


1. "fear the repository police". We will pick people in the audience 
and beat them with rolled up copies of the pom schema until they 
promise not to publish invalid metadata. we will start off with "Is 
there anyone here who works on commons-logging?",




It will soon be impossible to publish invalid metadata.


Speaking as someone who also works on commons-logging (*ducking*), is 
there work being done on a maven-repo-compliant-plugin or something 
similar that could be run on every pom that is submitted through 
MAVENUPLOAD? I.e. confirming to the rules set up here:

  http://maven.apache.org/guides/mini/guide-ibiblio-upload.html

If not, I think I could put something together.

2. Something on big project ant; ivy, import &c. Mostly how to use 
these concepts effectively and so have a scaled build that doesnt 
force you to throw away all your existing build process.


Interesting as one of my topics in the Maven Enterprise BOF is the 
conversion of huge project that basically retained 95% of it's Ant 
scripting, except it is packaged up in Maven plugins to be maintainable, 
and understandable.


3. Work related: something on virtualization; how to use amazon EC2 to 
host apache httpd and the like, what works, what doesn't (persistence, 
mainly). We'd use smartfrog to manage the deployments and maybe show 
using linuxcoe/instalinux to create the amazon Xen image at build time 
based on the RPM list you have under SCM.


4. I've invited the TestNG people and Xavier of Ivy fame to submit 
proposals. Both would be good. BTW, there's lots of unhappiness in 
TestNG-users about SureFire; someone should talk to them about their 
needs.




Kenney is working on the surefire plugin as we speak.


-Steve




--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ApacheCon Talks



On 19 Dec 06, at 12:28 PM 19 Dec 06, Steve Loughran wrote:


Jason van Zyl wrote:

Hi,
Just checking in with folks to see if anyone is planning ApacheCon  
talks.


1. "fear the repository police". We will pick people in the  
audience and beat them with rolled up copies of the pom schema  
until they promise not to publish invalid metadata. we will start  
off with "Is there anyone here who works on commons-logging?",




It will soon be impossible to publish invalid metadata.

2. Something on big project ant; ivy, import &c. Mostly how to use  
these concepts effectively and so have a scaled build that doesnt  
force you to throw away all your existing build process.


Interesting as one of my topics in the Maven Enterprise BOF is the  
conversion of huge project that basically retained 95% of it's Ant  
scripting, except it is packaged up in Maven plugins to be  
maintainable, and understandable.


3. Work related: something on virtualization; how to use amazon EC2  
to host apache httpd and the like, what works, what doesn't  
(persistence, mainly). We'd use smartfrog to manage the deployments  
and maybe show using linuxcoe/instalinux to create the amazon Xen  
image at build time based on the RPM list you have under SCM.


4. I've invited the TestNG people and Xavier of Ivy fame to submit  
proposals. Both would be good. BTW, there's lots of unhappiness in  
TestNG-users about SureFire; someone should talk to them about  
their needs.




Kenney is working on the surefire plugin as we speak.


-Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Feedback Needed on Release Reporting Tool

John Tolentino wrote:

[snip]

Right. I personally don't like raw maven output on such a page - the 
docck report plugin
should just generate a normal report page, preferrably embed it in 
this page.

I'll see what I can do on translating docck return values into a
suitable report.

Ok cool.

What's the 'download link' for? I can see how that's useful for 
assembly releases,
like maven-2.0.x-bin.tar.gz, but for plugins/other loose artifacts, 
would it point

to the jar in the repository? Is that useful?

When asking for a vote, we're expected to supply binaries of the
release candidate. This URL would point to that staging site.

Ah right. Should 'Download url' possibly be renamed to something like 'Release 
site',
since it doesn't point to a binary or a page where you can ONLY download
the binary, but provides a complete mvn site?

[snip]

Another thought about the docck report: should we list that on the 
page at all?
I think that, and the license header stuff are just plugins that fail 
the build if
the project is not compliant. So we should assume that when those 
plugins are enabled/used,
the project satisfies the requirements. A link to the project 
(staging)site which already

contains all the reports should be enough, right?

We've created standards on documenting plugins. I think it would be
good for people to know that effort is being made to keep to those
standards. Would also make developers mindful that we should help on
the documentation of our work as well. Other than the plugins, it's
not required, but i know would really be appreciated by its users.

The parent pom for all plugins should include that report then. Isn't that 
enough?

On the license, aren't this required by apache since October--or
earlier if my memory has failed me? Again, optional for other
projects.

Yup, true, but again, a plugin declaration in the root apache/maven pom
should take care of this. 

Though I see what you're doing here - you prove compliance to all demands 
set by apache for a binary release on one page. Perhaps a simple list

of demands with OK/FAIL behind them, where the elements in the list point
to the report itself, is sufficient?

for instance:

 Documentation standards: OK
...

We could make it an expandable section as well to keep things simple
and users interested in the detailed report could click on it for
viewing.

See above.

Also - when the release is made, will this page be available on the 
project site somewhere?

So people can see the project history, examine changelogs, etc.

I think it would be handy for people to know what fixes/new features
are included. Can be added in the Project Reports section.

Cool.

versions on mvn sites still need some discussion; for instance a menu section
with 'previous versions', 'latest snapshot' etc. that point to complete sites
for other versions would be nice; all sites would have a version in their 
directory too,
and a 'current' symlink or redirect page pointing to the latest non-snapshot 
release.
But this should be discussed on a separate thread. (there was a thread about 
this a
while back but nothing came out of it IIRC).

Thanks,

Kenney

-- Kenney

>
> Jason.
>
>> Thanks,
>> John
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The Future of the Release Process.

2006-12-19 Thread robert burrell donkin

On 12/19/06, Steve Loughran <[EMAIL PROTECTED]> wrote:

robert burrell donkin wrote:
> On 12/19/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
>
> 
>
>> I'd like to see POM auditing in there somewhere.
>
> +1
>
> henri's been talking about adding this to RAT. IMHO this should be
> implemented as a separate component so that it could be used by a
> variety of applications: for example, it might be interesting to be
> able to apply policy rules as part of subversion commits or staging
> updates.
>

I have a colleague who has been converting all the POMs and .class files
in the repository to RDF, ready for auditing.

cool :-)

We are

1. planning an apache con EU talk, "fear the repository police".

in suitable costumes, i hope ;-)

2. looking to get management approval to hand the code to the MIT Simile
project (e.g. Stefano)

cool

(there seems to a lot of interest developing around RDF ATM amongst
apache members)

stefano's keen to see discussions related to apache and RDFs in the
labs http://mail-archives.apache.org/mod_mbox/labs-labs/200612.mbox/[EMAIL 
PROTECTED]
(which makes sense to me.)

3. Thinking of something to audit the metadata. Maybe in prolog (my
choice), maybe something else.

i plan to persuade projects (by including this in RAT rather than a
conventional configuration file) to start recording auditing meta data
about documents which didn't originate at apache in RDF. i've also
been toying with the idea of using RDF to record relationships between
licenses and policy about licenses.

these sound like related problems to me

Working title "repo-man". This not only lets us have a good name, it
gives us good quotes

repo man rules :-)

it's amazing at the cinema...

"It's 4 A.M., do you know where your jar is?"
"You don't even know what's in your own trunk! And you know what? I
think you're afraid to find out! "

+1

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-eclipse-plugin release: vote result and follow up (was: [vote] release maven-eclipse-plugin)


Hi,

Fabrizio Giustina wrote:

The vote for the release of the eclipse plugin (and related shared
libraries) closed with 3 positive PMC binding votes (me, jason,
stephane) + two positive user votes.


I also voted, btw (on the 2nd try).


However, due to recent discussions on how votes should be called (on a
stable svn revision, deploying a preview binary and site), plus the
well know issues related to the updated apache guidelines I think it
would be better to repeat the vote, breaking this release into two:
- I will now take care of releasing all the shared dependencies listed
in the previous mails as prerequisite of the eclipse plugin release
(details below)
- after that I will update the maven-eclipse-plugin pom in order to
depend on stable versions, and call again a vote based on a stable svn
revision and a deployed binary/site.

the only non-maven snapshot dependency was plexus-utils, now released.
Thanks to Andrew Williams. This is the remaining tree of our
dependencies


You can't depend on anything newer than 1.1! Maven 2.0.4 has plexus-utils-1.1 
in the core/ dir,
overriding all other plexus jars in the class realms.
Only if you added a new class in there, that either doesn't use any other p-u 
class,
or uses one that hasn't changed since 1.1, this will work.

Plexus-utils is part of the 'maven api'.

-- Kenney


maven-eclipse-plugin -> will wait for another vote on a stable revision
 maven-test-tools -> will be moved out of sandbox and released as 
1.0-alpha-1

 maven-plugin-testing-harness -> will be released as 1.0-beta-2 (I
will see if 1.0-beta-1 could work)


Isn't this project going to be dropped soon? If we make an official release
we may have to support it in the future.


 maven-plugin-testing-tools -> will be moved out of sandbox and
released as 1.0-alpha-1
   maven-test-tools (already listed above)
   maven-invoker --> actually 1.0-SNAPSHOT, dependency will be moved
to already released 2.0.5


I don't follow.. you mean maven-invoker-2.0.5 is released but the pom still
says 1.0-SNAPSHOT?


-- Kenney


   maven-repository-builder -> will be moved out of sandbox and
released as 1.0-alpha-1
 maven-common-artifact-filters -> will be moved out of sandbox
and released as 1.0-alpha-1



fabrizio



On 12/11/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote:

I was already planning to start a vote, so a +1 from me since we
already waited too long and added so many changes and enhancements
lately.

Anyway, as usual there are a couple of things that need to be done 
before:

- license headers needs to be updated and added where missing
- we will have to wait till the remote-resources-plugin is released
(but this should happen soon)

And a bigger issue (the reason why I was delaying this vote):
- there are a few (!) shared components used for testing that need to
be release as well:
org.apache.maven.shared:maven-test-tools:1.0-SNAPSHOT
org.apache.maven.shared:maven-plugin-testing-tools:1.0-SNAPSHOT
org.apache.maven.shared:maven-plugin-testing-harness:1.0-beta-2-SNAPSHOT

plus:
- org.apache.maven.shared:maven-test-tools is still in the sandbox and
it requires a release version of:
org.codehaus.plexus:plexus-utils:1.4-SNAPSHOT

- org.apache.maven.shared:maven-plugin-testing-tools is in the sandbox
too and depends on the following snapshots:
org.apache.maven.shared:maven-repository-builder
org.apache.maven.shared:maven-invoker

and more:
- maven-repository-builder is still in the sandbox too and depends on
a snapshot version of
org.apache.maven.shared:maven-common-artifact-filters

... so, this vote should also mean moving 3 artifacts out of the
sandbox and release other 6 artifacts (not counting the plexus one)?
I think we really need to do this bunch of release (even marking some
components as beta or even alpha), so for me this is an unconditional
+1 for everything: we need a way out from this mess...


fabrizio


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning


Carlos Sanchez wrote:
the repository has some rules and you have to follow them to be 
manageable, eg. you name jars artifactId-version.jar and not 
otherwise. If there are version rules you'd have to follow, and I 
don't see the problem in having a standardized version convention, as

 we have standardized folder names.


As I said before:


The problem is basically that this simply isn't powerful enough to
cover all the various versioning schemes there are in the wild.
Suggesting forcing everybody to conform to your idea of versioning
isn't at all helpful; similarly imposing a complex mapping between
upstream and maven versions for a project is unattractive.


Which part do you disagree with?


--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Feedback Needed on Release Reporting Tool

2006-12-19 Thread robert burrell donkin


On 12/19/06, John Tolentino <[EMAIL PROTECTED]> wrote:

Hi Everyone,

Been working on a tool to generate reports for release candidates and
this is a mock of what it should look like:
http://people.apache.org/~jtolentino/release-reports/MockReport.html

We can send this generated page to the dev list when we call for a release.

I appreciate any feedback so I can improve the reporting (and before I
go further into implementation).


IMHO license auditing is quite a lot more subtle than it might first
appear: checking license headers is really only the start. there's a
lot more complexity that a release audit tool needs to cope with in
the wild.

whether maven ends up using RAT or rolling another release audit tool,
it probably makes sense to think about collaborating on some of the
problems.

for example, audit meta-data is important: a machine readable record
of the licensing and provenance of a document. it's not always right
to include a license header in a document but it's not unreasonable to
ask that every document without a header be accumpianied by audit
meta-data. rdf seems a good match for the format.

(see http://mail-archives.apache.org/mod_mbox/labs-labs/200612.mbox/[EMAIL 
PROTECTED]
thread)

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

Richard van der Hoff wrote:

Kenney Westerhof wrote:

Richard van der Hoff wrote:

Hi,

Carlos Sanchez wrote: Regarding Kenney's proposal: as discussed on
#maven, all sounds very sensible to me. I'm still fishing for, and
failing to find, examples of failures for projects where people
invert the precedence of . and -; however anyone doing that
probably deserves what they get.

Still waiting.. ;) Did we discuss this one: 1.0-2.3 <=> 1.0-2-3,
which is newer? My algorithm would say 1.0-2.3.

I don't think we discussed exactly that. I think your algorithm is
probably right here. However, you've now helped me find the problem I
was fishing for. My imaginary project separates versions with - and
build numbers with .; so I have

1-0.193
1-0.204
1-1.897

Oops! I need to release a bugfix to 1-0: 1-0-1.596

With your algorithm, we have (I think) 1-0-1.596 < 1-0.193, which is
wrong for my (crazy) versioning system. But, as I said, I deserve what I
get for doing this.

Correct;

1-0-1.596 = [1, [0, [1, 596]]]
1-0.193 = [1, [0, 193]]

comes down to comparing [1, 596] with 193.

It's easily changed, though I'm not sure what the impact would be.

And you would deserve it, definitely ;)

There will always be some corner case we don't quite cover correctly; I
don't think we should let this worry us or act as an argument against
improving the status quo, provided we get most sane cases covered. We
just need to make sure the exact algorithm is documented :).

I totally agree.

I don't think it would be unreasonable to expect a project's maven
versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so
jumping through hoops to make this work may not be worthwhile.

True. But as others suggested, when project leads are replaced,
version schemes may change also. Though I think that if that's the
case, then they'll probably stick to the current scheme until a final
(bugfix) release has been made, so you will probably never find
1.0alpha2 <=> 1.0-alpha-3, but rather 1.0alpha2 <=> 1.1-alpha-2. I
think this is a limitation we could easily impose.

Agreed.

Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc <
ga ? What happens when we've released an alpha, but want to
continue hacking on SNAPSHOTs before releasing another? we want
SNAPSHOT between rc and ga, no?

Yes we do. But, when trunk always has 2.0-SNAPSHOT, you don't know of
an alpha or beta or rc has been released yet. I'd say: 1.0-SNAPSHOT <
1.0-alpha-1-SNAPSHOT < 1.0-alpha-2-SNAPSHOT < ... < 1.0-rc1 <
1.0-rc2-SNAPSHOT.

Snapshots also have to be possible before the first alpha (which is
pretty common to do), and if we allow SNAPSHOT's to be present

everywhere (and use it as a qualifier, so: SNAPSHOT < alpha <
SNAPSHOT < beta <..), we can never compare with snapshots.

SNAPSHOT is a bit special anyway... If we have alpha < beta < SNAPSHOT <
ga, then people who want a SNAPSHOT will get the last snapshot before
the main release (regardless of the presence of alphas), and people who
don't will get the latest non-SNAPSHOT? I don't quite understand what
you mean here.

Well, we usually release say 1.0-SNAPSHOT first a few times, then
1.0-beta-1-SNAPSHOT,
then 1.0-beta-1, etc.

SNAPSHOT means 'working towards version'. It should be a suffix to the next
final
release made. So if your next release is 1.0-alpha-1, use 1.0-alpha-1-SNAPSHOT,
not 1.0-SNAPSHOT.

But then again, maybe there's no problem in using snapshots everywhere - you're
only
interested in the latest one anyway, and this could be a SNAPSHOT from
pre-1.0-alpha-X,
or a SNAPSHOT from pre 1.0. Guess it's not a problem after all.
I think the SNAPSHOT qualifier should be removed from my implementation, since it's not really

a qualifier. SNAPSHOT versions are resolved from the repository first anyway.

With this in mind, comparing 1.0-SNAPSHOT with 1.0-alpha-1 would cause problems.
Depending on wheter 1.0-SNAPSHOT is a pre-alpha-1 release, or a pre 1.0 release,
it would be older or newer.
Maybe whenever a 1.0-SNAPSHOT is encountered, it should also resolve to the
latest 1.0-*
version released.
For instance, we have in the repository, in order of deploying:

- 1.0-SNAPSHOT
- 1.0-alpha-1-SNAPSHOT
- 1.0-alpha-1

- 1.0-SNAPSHOT
- 1.0-rc-1

Then 1.0-SNAPSHOT should resolve to 1.0-rc-1. This requires some work on
snapshot resolution,
but SNAPSHOT in a dependency means 'get me the latest version' (whereas SNAPSHOT in the
project's version tag means: 'working towards').

From experience I'd say people start out with 1.0-SNAPSHOT, and later
do 1.0-rc-1. Then before the ga is released, they don't revert back
to 1.0-SNAPSHOT (or shouldn't, i've seen people do it). This produces
unpredictable results.

So your recommendation is, once you want to make the final release, to
go straight from 1.0-rc-N-SNAPSHOT to 1.0, without ever releasing
1.0-rc-N (and similarly for transition into alpha, beta and rc stages)?
That's fine, provided it's documented :).

Depends on the project's re

Re: ApacheCon Talks


Jason van Zyl wrote:

Hi,

Just checking in with folks to see if anyone is planning ApacheCon 
talks.


1. "fear the repository police". We will pick people in the audience and 
beat them with rolled up copies of the pom schema until they promise not 
to publish invalid metadata. we will start off with "Is there anyone 
here who works on commons-logging?",


2. Something on big project ant; ivy, import &c. Mostly how to use these 
concepts effectively and so have a scaled build that doesnt force you to 
throw away all your existing build process.


3. Work related: something on virtualization; how to use amazon EC2 to 
host apache httpd and the like, what works, what doesn't (persistence, 
mainly). We'd use smartfrog to manage the deployments and maybe show 
using linuxcoe/instalinux to create the amazon Xen image at build time 
based on the RPM list you have under SCM.


4. I've invited the TestNG people and Xavier of Ivy fame to submit 
proposals. Both would be good. BTW, there's lots of unhappiness in 
TestNG-users about SureFire; someone should talk to them about their needs.


-Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

2006-12-19 Thread Dennis Lundberg


Kenney Westerhof wrote:

Richard van der Hoff wrote:

Hi,


Carlos Sanchez wrote:

Sound like a lot of added complexity that will cause trouble to all
tooling on top of Maven


Can you justify that with an example, at all?


What about forcing the xml schema to a standard versioning system. If
it's used then you'll benefit from all Maven goodies. If you just use
a String Maven will do its best.

For instance


 1
 2
 1
 123



The problem is basically that this simply isn't powerful enough to 
cover all the various versioning schemes there are in the wild. 
Suggesting forcing everybody to conform to your idea of versioning 
isn't at all helpful; similarly imposing a complex mapping between 
upstream and maven versions for a project is unattractive.


I agree. As i said in another mail, something like this could be used to 
specify
a weird versioning scheme. Versions are ONLY needed for comparison, 
nothing else, so that's
where proper parsing and comparing comes into play. Limiting freedom in 
using version schemes just so we can compare them is not the way to go 
IMHO.


Furthermore you don't leave any scope for extension such as might be 
required for local modifications of a project.


Stéphane also suggested forcing a particular versioning convention on 
everybody - the same argument applies.


Regarding Kenney's proposal: as discussed on #maven, all sounds very 
sensible to me. I'm still fishing for, and failing to find, examples 
of failures for projects where people invert the precedence of . and 
-; however anyone doing that probably deserves what they get.


Still waiting.. ;)   Did we discuss this one: 1.0-2.3  <=> 1.0-2-3, 
which is newer? My algorithm would say 1.0-2.3.


I don't think it would be unreasonable to expect a project's maven 
versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping 
through hoops to make this work may not be worthwhile.


True. But as others suggested, when project leads are replaced, version 
schemes
may change also. Though I think that if that's the case, then they'll 
probably
stick to the current scheme until a final (bugfix) release has been 
made, so
you will probably never find 1.0alpha2 <=> 1.0-alpha-3, but rather 
1.0alpha2 <=> 1.1-alpha-2. I think this is a limitation we could easily 
impose.


Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ? 
What happens when we've released an alpha, but want to continue 
hacking on SNAPSHOTs before releasing another? we want SNAPSHOT 
between rc and ga, no?


Yes we do. But, when trunk always has 2.0-SNAPSHOT, you don't know of an 
alpha

or beta or rc has been released yet. I'd say:
1.0-SNAPSHOT < 1.0-alpha-1-SNAPSHOT < 1.0-alpha-2-SNAPSHOT < ... < 
1.0-rc1 < 1.0-rc2-SNAPSHOT.


Snapshots also have to be possible before the first alpha (which is 
pretty common to do),
and if we allow SNAPSHOT's to be present everywhere (and use it as a 
qualifier, so:
SNAPSHOT < alpha < SNAPSHOT < beta <..), we can never compare with 
snapshots.


 From experience I'd say people start out with 1.0-SNAPSHOT, and later 
do 1.0-rc-1. Then before
the ga is released, they don't revert back to 1.0-SNAPSHOT (or 
shouldn't, i've seen people do it). This

produces unpredictable results.


maven-site-plugin anyone? :)


Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
implementation, 2.0.1-xyz is newer than 2.0.1."? 


No it doesn't. The current implementation assumes 2.0.1 is newer than 
2.0.1-xyz.



To quote Barrie Treloar who quoted a book:

 quote BBWM page 60: "It is intended that the qualifier indicates a version
 prior to release"  
 thus 2.0.1-xyz < 2.0.1 is correct.

 The -INTERNAL was always meant to be a qualifier.
 Thus: 2.0-SNAPSHOT < 2.0-INTERNAL < 2.0
I'm missing some context here, but 'xyz' is not a KNOWN qualifier. Our 
qualifiers
are 'alpha', 'beta', 'rc, 'ga', 'sp'. If it's a random string, and we 
don't call it a qualifier,

it could well mean a newer version.

The problem is where to place strings that are unknown qualifiers:

 alpha < beta < rc < ga <  (here?) < "" < (here?) < sp < (here?)


I may just be misunderstanding your explanation, but if you could 
clarify what exactly happens when a given component isn't present, and 
for unrecognised qualifiers, that would be useful.


Right now: if a component is not present, in the case of:

integer <=> null:  integer==0 ? 0 : 1 (this fixes '2.0' <=> '2' which is 
0, and 2.1 <=> 2 which is 1)


list<=> null: does a compare for list <=> [empty list], which 
finally results in either integer <=> null or string <=> null


string <=> null:   see the 'alpha < beta' list above.

  Use the empty string instead of null, then compare 
string <=> "". So when comparing
  1-alpha with 1, this is the same as comparing 
"1-alpha" and "1-". Which one is newer
  depends on wheter 'string' is listed before or after 
the "" in the list above.


  Algorithm for string <=

Re: versioning

Carlos Sanchez wrote:

On 12/19/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:

> Whatever parser/validation code you write will need to be used in all
> tooling, like any IDE pom editor, pom converters,... you may say
> that's fine but think that tools could also be implemented in other
> languages.

I don't see why that's necessary - ArtifactVersion implementations are 
only used to resolve
version conflicts, limit ranges, and other stuff only necessary when 
running Maven.
You can mix and match any version strings you want using any IDE or 
pom editing tool. I don't
validate any version, I just parse it and that always works. It has 
some rules as to how
to interpret version components in order to be able to compare them, 
but again, that's just

needed for version conflict resolution within maven itself.

If you want maven to be able to tell you wheter some version is newer 
or older or equal to another

version, you have a few limitations on what version schemes you can use:

1) elements more to the left are more important than elements more to 
the right

2) some qualifiers have special meanings w.r.t. ordering

Other than that there are no limitations, unlike the current 
implementation.

imagine in the IDE you want to present an ordered list of available
artifacts, that will run outside of maven

Not our problem. ;) 

It can use maven-artifact's version implementation to sort the versions,
or get the source and port it to ruby or whatever language the IDE is written 
in,
and use that.

There's only 1 class here, which has 2 methods: the string constructor to parse 
the version,
and a compareTo interface (implementation of comparable). That's not a lot of 
code to
use in tooling.

-- Kenney

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning




ir. ing. Jan Dockx wrote:


On 19 Dec 2006, at 17:50, Kenney Westerhof wrote:

What tool uses those invariant annotations? Looks useful for 
application validation.


;-) Let's discuss that off-line.


cool, [EMAIL PROTECTED]://irc.codehaus.org/#maven

[snip]



...
...
[versionString]
true
...



What would be in the version string? Usually the first N digits denote 
incompatible
versions, later ones denote compatibility updates, for instance for 
all X: 1.2.X

is compatible.



Well, Maven wouldn't say. That's the point. The version scheme 
implementation deals with the [versionString], so Maven itself doesn't 
have to. Of course, most used version scheme's would be found 
implemented at central, and Maven would have a default (convention over 
configuration) which will probably be Apaches versioning practice.


Maven doesn't have to say. It should provide sensible default version comparing,
which is present. Next, version ranges should enable users to specify if they 
want
compatible versions or just the latest release or whatever. It's up to the
person writing the  tag to get acquainted with the version scheme 
used on
that project, and decide what kind of version(s) he'd want. 


Your solution works too, but it requires a pom change, and IMHO version ranges 
already
support this. 
In the case where it's impossible to specify a version range for some particular set of 
versions because the version scheme used by the dependency doesn't allow it, then that's

'not our problem'. May be harsh, but I opt for a generic version scheme 
implementation that
supports so many version schemes, that you have to try really hard to come up 
with one
that's so obscure that maven can't handle it.

-- Kenney

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

On 12/19/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:

> Whatever parser/validation code you write will need to be used in all
> tooling, like any IDE pom editor, pom converters,... you may say
> that's fine but think that tools could also be implemented in other
> languages.

I don't see why that's necessary - ArtifactVersion implementations are only 
used to resolve
version conflicts, limit ranges, and other stuff only necessary when running 
Maven.
You can mix and match any version strings you want using any IDE or pom editing 
tool. I don't
validate any version, I just parse it and that always works. It has some rules 
as to how
to interpret version components in order to be able to compare them, but again, 
that's just
needed for version conflict resolution within maven itself.

If you want maven to be able to tell you wheter some version is newer or older 
or equal to another
version, you have a few limitations on what version schemes you can use:

1) elements more to the left are more important than elements more to the right
2) some qualifiers have special meanings w.r.t. ordering

Other than that there are no limitations, unlike the current implementation.

imagine in the IDE you want to present an ordered list of available
artifacts, that will run outside of maven

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

2006-12-19 Thread Mark Hobson

On 19/12/06, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:

On 19 Dec 2006, at 17:50, Kenney Westerhof wrote:
> What tool uses those invariant annotations? Looks useful for
> application validation.

;-) Let's discuss that off-line.

How comes?  I'd be interested too.

Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

On 12/19/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:

Carlos Sanchez wrote:
> and almost all artifacts in repo can be expressed as 4 different
> alphanumeric sections, so no problem there,

And the ones that can't? We don't care about those? And the ones in
peoples private repositories?

the repository has some rules and you have to follow them to be
manageable, eg. you name jars artifactId-version.jar and not
otherwise. If there are version rules you'd have to follow, and I
don't see the problem in having a standardized version convention, as
we have standardized folder names.

--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

Carlos Sanchez wrote:

On 12/19/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:

Carlos Sanchez wrote:
> Sound like a lot of added complexity that will cause trouble to all
> tooling on top of Maven
>

How so? The current implementation is too complex, this one is pretty
straight forward - it allows for versions of any length.

I meant yours AND current one are both complex, although yours wins ;)

In complexity? Possibly ;) But added complexity means added flexibility, in 
this case.
The original code has all edge cases hardcoded.

Whatever parser/validation code you write will need to be used in all
tooling, like any IDE pom editor, pom converters,... you may say
that's fine but think that tools could also be implemented in other
languages.

I don't see why that's necessary - ArtifactVersion implementations are only 
used to resolve
version conflicts, limit ranges, and other stuff only necessary when running 
Maven.
You can mix and match any version strings you want using any IDE or pom editing 
tool. I don't
validate any version, I just parse it and that always works. It has some rules 
as to how
to interpret version components in order to be able to compare them, but again, 
that's just
needed for version conflict resolution within maven itself.

If you want maven to be able to tell you wheter some version is newer or older 
or equal to another
version, you have a few limitations on what version schemes you can use:

1) elements more to the left are more important than elements more to the right
2) some qualifiers have special meanings w.r.t. ordering

Other than that there are no limitations, unlike the current implementation.

(more below)

> What about forcing the xml schema to a standard versioning system. If
> it's used then you'll benefit from all Maven goodies. If you just use
> a String Maven will do its best.
>
> It's gonna be more complex for manual editing but being standard xml
> will be easier to implement
>

It's already implemented. ;) Plus my sample implementation supports 
the current (limited)
version scheme implementation and so far all others I've come across, 
which the current one

doesn't.

This is definitely too verbose. Plus, we cannot force a version 
numbering scheme
on people, since there are already big projects out there that have a 
good

version numbering scheme which doesn't fit in this one.

I agree is too verbose, but the same happens with  and all
the other tags that can be reduced, but losing simplicity. Not using
attributes also makes the pom verbose and nobody questions that.

As I said we can have a pure String representation for those projects
that don't want to follow our suggestion, but they won't have the
added features.

Partially true. having a string representation should provide for some 
flexible, sensible,
default processing. I don't agree that when you don't specify the complex 
version tag,
you have no version numbering at all, or just string compares, or even the 
current implementation.

Version strings have a pretty simple grammar, and what you're proposing is to 
specify another grammar,
where elements aren't separated by dots or dashes, but by xml tags.

I think that's a severe limitation compared to using version strings, and it 
doesn't add anything
to support other version schemes or support a different version ordering.

The complexity is not in the grammar, but in the version ordering.

The only solution that makes this customizable I've seen on this thread is the 
one where you
specify a 'version plugin' with a Version implementation that takes care of 
sorting for you.

-- Kenney

Though the tag you list above looks good, but not for version 
definitions, but
we could use something like that for version scheme specifications so 
we can validate

supplied versions, for instance in a super pom:

 type='string'>

   alpha
   beta

Or, I'd prefer XSD schema notation to specify the above. It could 
validate a version like this:

2.0-alpha-3 which is rendered as

(your example, sort of)

 1
 2
 alpha
 123

but users would just specify '2.0-alpha-3' in the pom.

-- Kenney

> On 12/18/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> The current versioning implementation is IMHO too 'tight'. For 
instance,

>> 2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of '2.0.0alpha1',
>> whereas this should
>> be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1.
>>
>> Here's a proposal:
>>
>> - don't use the current 4-digit limitation, but instead list with a
>> random amount of entries
>> - entries are separated by dots or dashes
>> - entries are separated by transition to/from alpha to numeric
>> - sub-lists are indicated by '-'
>> - entries can be either: string, integer, or sublist
>> - versions are compared entry by entry, where we have 3 options;
>>   * integer <=> integer: normal numerical compare
>>   * integer <=> string: integers are newer
>>   * integer <=> list: integers are newer
>>   * s

Re: versioning



On 19 Dec 2006, at 17:50, Kenney Westerhof wrote:


Hi,

ir. ing. Jan Dockx wrote:
Well, your schema does follow the Java standard (java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/ 
versioning2.html#wp89936>). That might be a good default. Maven  
could apply a strategy pattern to allow for other versioning  
schemes. Only 3 functions are needed, as far as I can see:

/**
 * @invar ! equals(null);
 * @invar ! isCompatible(null);
 * @invar ! isBetter(null);
 * @invar (forall Version v; equals(v) ==> isCompatible(v));
 * @invar (forall Version v; equals(v) ==> ! isBetter(v));
 * @invar (forall Version v; isBetter(v) ==> isCompatible(v));
 */
public interface Version {
  boolean isCompatible(Version other);
  boolean isBetter(Version other);
  boolean equals(Object other);
}


What tool uses those invariant annotations? Looks useful for  
application validation.


;-) Let's discuss that off-line.



(You can't extend Comparable, because the contract says that you  
need to have a result for all combinations of objects of a given  
type, and here only compatible versions are comparable).
The only thing left for dependency notes in a dependency listing  
is then to say whether you want compatible, better versions, or  
you want to stay with the exact version denoted. You don't have to  
specify here which versions you want, the dependency knows itself  
whether or not it is compatible and better than what you require.


...
...
[versionString]
true
...



What would be in the version string? Usually the first N digits  
denote incompatible
versions, later ones denote compatibility updates, for instance for  
all X: 1.2.X

is compatible.



Well, Maven wouldn't say. That's the point. The version scheme  
implementation deals with the [versionString], so Maven itself  
doesn't have to. Of course, most used version scheme's would be found  
implemented at central, and Maven would have a default (convention  
over configuration) which will probably be Apaches versioning practice.




Right now maven already handles this using version ranges:  
[1.2,1.3) indicates 1.2[.0] and

all other compatible versions (excluding alpha versions).

The POM of an artifact should than refer to a Version  
implementation. So, version implementations should be separate  
artifacts themselves.

...

...
...
[versionString]

[versionString]
...


Yeah, something like that would be useful - it should define a  
metadata file
indicating the version class implementations to use for that  
artifact. That was one

other possibility I was considering. It's probably more flexible.


And the version scheme for version schemes should be fixed by Maven.
We probably need a factory too for each version implementation:
public interface VersionFactory {
  Version parse(String versionString);
}


Yup. Or a one arg constructor with string - it'll probably be  
called using reflection anyway.


-- Kenney


On 19 Dec 2006, at 11:44, Carlos Sanchez wrote:

Sound like a lot of added complexity that will cause trouble to all
tooling on top of Maven

What about forcing the xml schema to a standard versioning  
system. If
it's used then you'll benefit from all Maven goodies. If you just  
use

a String Maven will do its best.

For instance


 1
 2
 1
 123


It's gonna be more complex for manual editing but being standard xml
will be easier to implement

On 12/18/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:


Hi,

The current versioning implementation is IMHO too 'tight'. For  
instance,
2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of  
'2.0.0alpha1', whereas this should

be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1.

Here's a proposal:

- don't use the current 4-digit limitation, but instead list  
with a random amount of entries

- entries are separated by dots or dashes
- entries are separated by transition to/from alpha to numeric
- sub-lists are indicated by '-'
- entries can be either: string, integer, or sublist
- versions are compared entry by entry, where we have 3 options;
  * integer <=> integer: normal numerical compare
  * integer <=> string: integers are newer
  * integer <=> list: integers are newer
  * string <=> string: if it's a qualifier, qualifier compare,  
else lexical compare,

 taking into account if either is a qualifier.
  * string <=> list: list is newer
  * list <=> list: recursion, same as a 'top-level' version  
compare. Where one list is shorter,
  '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 =>  
2.0-alpha <=> 2.0.0 = -1 (2.0 = newer))


Now for some examples to explain the rules above:

(note; i'm using the following notation:
   [1, 0] is a list with items 1, 0;
   [1, 0, [2, 3]] is a list with items 1, 0, [2, 3] where the  
latter is a sublist)


Version parsing:

'1.0':  [1, 0]
'1.0.0.0.0' [1, 0, 0, 0, 0]
'1.0-2.3':  [1, 0, [2, 3]]
'1.0-2-3':  [1, 0, [2, [3]]]

'1.0-alpha-1':  [1, 0, ["alpha", [1]]]
'1.0alpha1':

Re: versioning


Kenney Westerhof wrote:

Richard van der Hoff wrote:

Hi,


Carlos Sanchez wrote: Regarding Kenney's proposal: as discussed on
#maven, all sounds very sensible to me. I'm still fishing for, and
failing to find, examples of failures for projects where people
invert the precedence of . and -; however anyone doing that
probably deserves what they get.


Still waiting.. ;)   Did we discuss this one: 1.0-2.3  <=> 1.0-2-3, 
which is newer? My algorithm would say 1.0-2.3.


I don't think we discussed exactly that. I think your algorithm is
probably right here. However, you've now helped me find the problem I
was fishing for. My imaginary project separates versions with - and
build numbers with .; so I have

1-0.193
1-0.204
1-1.897

Oops! I need to release a bugfix to 1-0: 1-0-1.596

With your algorithm, we have (I think) 1-0-1.596 < 1-0.193, which is
wrong for my (crazy) versioning system. But, as I said, I deserve what I
get for doing this.

There will always be some corner case we don't quite cover correctly; I
don't think we should let this worry us or act as an argument against
improving the status quo, provided we get most sane cases covered. We 
just need to make sure the exact algorithm is documented :).



I don't think it would be unreasonable to expect a project's maven
 versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so
jumping through hoops to make this work may not be worthwhile.


True. But as others suggested, when project leads are replaced,
version schemes may change also. Though I think that if that's the
case, then they'll probably stick to the current scheme until a final
(bugfix) release has been made, so you will probably never find
1.0alpha2 <=> 1.0-alpha-3, but rather 1.0alpha2 <=> 1.1-alpha-2. I
think this is a limitation we could easily impose.


Agreed.


Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc <
ga ? What happens when we've released an alpha, but want to
continue hacking on SNAPSHOTs before releasing another? we want
SNAPSHOT between rc and ga, no?


Yes we do. But, when trunk always has 2.0-SNAPSHOT, you don't know of
an alpha or beta or rc has been released yet. I'd say: 1.0-SNAPSHOT <
1.0-alpha-1-SNAPSHOT < 1.0-alpha-2-SNAPSHOT < ... < 1.0-rc1 <
1.0-rc2-SNAPSHOT.

Snapshots also have to be possible before the first alpha (which is 
pretty common to do), and if we allow SNAPSHOT's to be present

everywhere (and use it as a qualifier, so: SNAPSHOT < alpha <
SNAPSHOT < beta <..), we can never compare with snapshots.


SNAPSHOT is a bit special anyway... If we have alpha < beta < SNAPSHOT < 
ga, then people who want a SNAPSHOT will get the last snapshot before 
the main release (regardless of the presence of alphas), and people who 
don't will get the latest non-SNAPSHOT? I don't quite understand what 
you mean here.



From experience I'd say people start out with 1.0-SNAPSHOT, and later
do 1.0-rc-1. Then before the ga is released, they don't revert back
to 1.0-SNAPSHOT (or shouldn't, i've seen people do it). This produces
unpredictable results.


So your recommendation is, once you want to make the final release, to 
go straight from 1.0-rc-N-SNAPSHOT to 1.0, without ever releasing 
1.0-rc-N (and similarly for transition into alpha, beta and rc stages)? 
That's fine, provided it's documented :).



Also, does "unknown(lexical sort) < ''" not conflict with "In my
sample implementation, 2.0.1-xyz is newer than 2.0.1."?


No it doesn't. The current implementation assumes 2.0.1 is newer than
 2.0.1-xyz.


So '' < unknown(lexical sort) ? Anyway, you say this is up for debate, fine.

--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning


Hi,

ir. ing. Jan Dockx wrote:
Well, your schema does follow the Java standard 
(). 
That might be a good default. Maven could apply a strategy pattern to 
allow for other versioning schemes. Only 3 functions are needed, as far 
as I can see:


/**
 * @invar ! equals(null);
 * @invar ! isCompatible(null);
 * @invar ! isBetter(null);
 * @invar (forall Version v; equals(v) ==> isCompatible(v));
 * @invar (forall Version v; equals(v) ==> ! isBetter(v));
 * @invar (forall Version v; isBetter(v) ==> isCompatible(v));
 */
public interface Version {

  boolean isCompatible(Version other);

  boolean isBetter(Version other);

  boolean equals(Object other);

}



What tool uses those invariant annotations? Looks useful for application 
validation.

(You can't extend Comparable, because the contract says that you need to 
have a result for all combinations of objects of a given type, and here 
only compatible versions are comparable).


The only thing left for dependency notes in a dependency listing is then 
to say whether you want compatible, better versions, or you want to stay 
with the exact version denoted. You don't have to specify here which 
versions you want, the dependency knows itself whether or not it is 
compatible and better than what you require.



...
...
[versionString]
true
...



What would be in the version string? Usually the first N digits denote 
incompatible
versions, later ones denote compatibility updates, for instance for all X: 1.2.X
is compatible.

Right now maven already handles this using version ranges: [1.2,1.3) indicates 
1.2[.0] and
all other compatible versions (excluding alpha versions).



The POM of an artifact should than refer to a Version implementation. 
So, version implementations should be separate artifacts themselves.


...

...
...
[versionString]

[versionString]
...



Yeah, something like that would be useful - it should define a metadata file
indicating the version class implementations to use for that artifact. That was 
one
other possibility I was considering. It's probably more flexible.


And the version scheme for version schemes should be fixed by Maven.


We probably need a factory too for each version implementation:

public interface VersionFactory {

  Version parse(String versionString);

}


Yup. Or a one arg constructor with string - it'll probably be called using 
reflection anyway.

-- Kenney




On 19 Dec 2006, at 11:44, Carlos Sanchez wrote:


Sound like a lot of added complexity that will cause trouble to all
tooling on top of Maven

What about forcing the xml schema to a standard versioning system. If
it's used then you'll benefit from all Maven goodies. If you just use
a String Maven will do its best.

For instance


 1
 2
 1
 123


It's gonna be more complex for manual editing but being standard xml
will be easier to implement

On 12/18/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:


Hi,

The current versioning implementation is IMHO too 'tight'. For instance,
2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of '2.0.0alpha1', 
whereas this should

be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1.

Here's a proposal:

- don't use the current 4-digit limitation, but instead list with a 
random amount of entries

- entries are separated by dots or dashes
- entries are separated by transition to/from alpha to numeric
- sub-lists are indicated by '-'
- entries can be either: string, integer, or sublist
- versions are compared entry by entry, where we have 3 options;
  * integer <=> integer: normal numerical compare
  * integer <=> string: integers are newer
  * integer <=> list: integers are newer
  * string <=> string: if it's a qualifier, qualifier compare, else 
lexical compare,

 taking into account if either is a qualifier.
  * string <=> list: list is newer
  * list <=> list: recursion, same as a 'top-level' version compare. 
Where one list is shorter,
  '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 => 
2.0-alpha <=> 2.0.0 = -1 (2.0 = newer))


Now for some examples to explain the rules above:

(note; i'm using the following notation:
   [1, 0] is a list with items 1, 0;
   [1, 0, [2, 3]] is a list with items 1, 0, [2, 3] where the latter 
is a sublist)


Version parsing:

'1.0':  [1, 0]
'1.0.0.0.0' [1, 0, 0, 0, 0]
'1.0-2.3':  [1, 0, [2, 3]]
'1.0-2-3':  [1, 0, [2, [3]]]

'1.0-alpha-1':  [1, 0, ["alpha", [1]]]
'1.0alpha1':[1, 0, ["alpha", [1]]] or [1, 0, "alpha", 1], which 
is the current implementation (see bottom)



String sorting (qualifiers)

SNAPSHOT < alpha < beta < gamma < rc < ga < unknown(lexical sort) < 
'' < sp


(ga = latest rc, final version
 '' = no qualifier, final version
 sp = service pack, improvement/addition on final release)

usually systems either use '' or ga, not both.

so 1.0-rc3 < 1.0-ga == 1.0 < 1.0-sp1 < 1.0.1


Comparing;

1)
  1.0

Re: Feedback Needed on Release Reporting Tool

2006-12-19 Thread John Tolentino

On 12/20/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:

Hi, some more comments:

First: very nice, extremely handy for voting.

Jason van Zyl wrote:
> On 18 Dec 06, at 10:19 PM 18 Dec 06, John Tolentino wrote:
>
>> Hi Everyone,
>>
>> Been working on a tool to generate reports for release candidates and
>> this is a mock of what it should look like:
>> http://people.apache.org/~jtolentino/release-reports/MockReport.html
>>
>> We can send this generated page to the dev list when we call for a
>> release.
>>
>> I appreciate any feedback so I can improve the reporting (and before I
>> go further into implementation).
>>
>
> I would link the "Issues Resolved for This Release" to the roadmap in
> the issue tracking system.
>

I agree. Maybe even use a JIRA/whateverIssueSystem embedded report (rss
feed for the jira changelog formatted in the site's style).

> I would also link each of the resolved issues to the issue tracking
> system so you can navigate from the report to the exact issue.

Right.

Ah! +1 That would be nice.

> Maybe some SCM information, what system is being used and the "label"
> instead of revision which is SVN specific and a link, if possible, to
> that revision in the SCM. For SVN and CVS this is easy with ViewCVS.

John's comment about labels: agreed. I only know 1 system that supports labels
and that's Clearcase; labels don't specify a fixed version. Perhaps a revision
number is better, or a tag/branch. Though all those can change.
For CVS, each file has it's own version history, so you should list all
source files and their versions, though there's no easy way to check that out.
Perhaps a CVS timestamp works best in that case - there can never be 2 commits
with the same timestamp AFAIK.

>
> That's all I can see at first glance. Though I think that getting
> everything easy to see in one page is a good goal. We can link to things
> like the docck report and the expanded view of deliverables. Get it all
> on one page and link. If the results are OK then people most likely
> won't look at them, but they can if they want. One clear page of the
> state of the release would be nice.

Right. I personally don't like raw maven output on such a page - the docck 
report plugin
should just generate a normal report page, preferrably embed it in this page.

I'll see what I can do on translating docck return values into a
suitable report.

What's the 'download link' for? I can see how that's useful for assembly 
releases,
like maven-2.0.x-bin.tar.gz, but for plugins/other loose artifacts, would it 
point
to the jar in the repository? Is that useful?

When asking for a vote, we're expected to supply binaries of the
release candidate. This URL would point to that staging site.

'Release date: 12/10/1815' wow, i didn't think they had computers back then ;)

Agusta Ada Byron's birthday :D

(I'd prefer ISO dates or a tztimestamp btw: 2006/12/10 or 2006/12/10 13:14:15 
CEST)

I see what you mean.

Another thought about the docck report: should we list that on the page at all?
I think that, and the license header stuff are just plugins that fail the build 
if
the project is not compliant. So we should assume that when those plugins are 
enabled/used,
the project satisfies the requirements. A link to the project (staging)site 
which already
contains all the reports should be enough, right?

We've created standards on documenting plugins. I think it would be
good for people to know that effort is being made to keep to those
standards. Would also make developers mindful that we should help on
the documentation of our work as well. Other than the plugins, it's
not required, but i know would really be appreciated by its users.

On the license, aren't this required by apache since October--or
earlier if my memory has failed me? Again, optional for other
projects.

We could make it an expandable section as well to keep things simple
and users interested in the detailed report could click on it for
viewing.

Also - when the release is made, will this page be available on the project 
site somewhere?
So people can see the project history, examine changelogs, etc.

I think it would be handy for people to know what fixes/new features
are included. Can be added in the Project Reports section.

-- Kenney

>
> Jason.
>
>> Thanks,
>> John
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL P

Re: versioning


Carlos Sanchez wrote:

and almost all artifacts in repo can be expressed as 4 different
alphanumeric sections, so no problem there,


And the ones that can't? We don't care about those? And the ones in 
peoples private repositories?



--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning


On 12/19/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:

Carlos Sanchez wrote:
> the other tags that can be reduced, but losing simplicity. Not using
> attributes also makes the pom verbose and nobody questions that.

They do, actually - it's been discussed here before.


let me rephrase, a more verbose pom was used for easier usability



> As I said we can have a pure String representation for those projects
> that don't want to follow our suggestion, but they won't have the
> added features.

What added features? The ability to compare version numbers? A bit
fundamental imho.


and almost all artifacts in repo can be expressed as 4 different
alphanumeric sections, so no problem there, i'm just talking about
splitting them in different sections rather than concatenate




--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

My proposal would solve that: -,
for instance (1.0-3.2) would work just fine. In this case spec versions
take precedence over impl versions, but that's generally what you want anyway.

-- kenney

ir. ing. Jan Dockx wrote:
Ah. Well. Most libraries (think Jakarta commons) have a spec side and an 
implementation side. According to the spec, we would need something like 
1.2.3-4567. The spec suggests, but does not limit to, a build number for 
the implementation identification. There is no problem with the 
major.minor.micro scheme for the spec version, but an overly restrictive 
Maven standard might rule out having 2 separate parts. I just wanted to 
say that Maven should look out for that (I do know that most important 
libs in the wild don't follow the standard, but that's something 
different -- eclipse is a bit cleaner than Apache in that respect).

On 19 Dec 2006, at 10:48, Tom Huybrechts wrote:

From the spec:

A version string is a series of positive numbers separated by periods.
The numbers are compared component by component from left to right. If
any number is greater than the corresponding number of the supplied
string the method returns true. If the number is less than it returns
false. If the corresponding numbers are equal the next number is
examined.

That shouldn't be a problem...

On 12/19/06, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:

I believe that Maven version number support should at least make it
possible to apply the specification / implementation version
numbering scheme that is part of the Java standard ().

On 19 Dec 2006, at 9:33, [EMAIL PROTECTED] wrote:

> Jason Dillon <[EMAIL PROTECTED]> schrieb am 19.12.2006 01:26:54:
>
>> I've seen projects switch back and forth... depends on who is in
>> power at the time and what style they like.  So it would be best if
>> mvn would be able comprehend:
>
> Since versions are such an important information in Maven, Maven
> should
> refuse version numbers which aren't easily comparable.
>
> How about forcing the contents of the version element in the POM to
> 1-3
> digits, separated by dots? That would "help" people who can't decide.
>
> After that, you can add something with "-" which maven will just
> string-compare (so alpha10 comes between alpha1 and alpha2).
>
> Regards,
>
> --
> Aaron Digulla
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

Well, your schema does follow the Java standard ().  
That might be a good default. Maven could apply a strategy pattern to  
allow for other versioning schemes. Only 3 functions are needed, as  
far as I can see:


/**
 * @invar ! equals(null);
 * @invar ! isCompatible(null);
 * @invar ! isBetter(null);
 * @invar (forall Version v; equals(v) ==> isCompatible(v));
 * @invar (forall Version v; equals(v) ==> ! isBetter(v));
 * @invar (forall Version v; isBetter(v) ==> isCompatible(v));
 */
public interface Version {

  boolean isCompatible(Version other);

  boolean isBetter(Version other);

  boolean equals(Object other);

}

(You can't extend Comparable, because the contract says that you need  
to have a result for all combinations of objects of a given type, and  
here only compatible versions are comparable).


The only thing left for dependency notes in a dependency listing is  
then to say whether you want compatible, better versions, or you want  
to stay with the exact version denoted. You don't have to specify  
here which versions you want, the dependency knows itself whether or  
not it is compatible and better than what you require.



...
...
[versionString]
true
...


The POM of an artifact should than refer to a Version implementation.  
So, version implementations should be separate artifacts themselves.


...

...
...
[versionString]

[versionString]
...

And the version scheme for version schemes should be fixed by Maven.


We probably need a factory too for each version implementation:

public interface VersionFactory {

  Version parse(String versionString);

}


On 19 Dec 2006, at 11:44, Carlos Sanchez wrote:


Sound like a lot of added complexity that will cause trouble to all
tooling on top of Maven

What about forcing the xml schema to a standard versioning system. If
it's used then you'll benefit from all Maven goodies. If you just use
a String Maven will do its best.

For instance


 1
 2
 1
 123


It's gonna be more complex for manual editing but being standard xml
will be easier to implement

On 12/18/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:


Hi,

The current versioning implementation is IMHO too 'tight'. For  
instance,
2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of  
'2.0.0alpha1', whereas this should

be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1.

Here's a proposal:

- don't use the current 4-digit limitation, but instead list with  
a random amount of entries

- entries are separated by dots or dashes
- entries are separated by transition to/from alpha to numeric
- sub-lists are indicated by '-'
- entries can be either: string, integer, or sublist
- versions are compared entry by entry, where we have 3 options;
  * integer <=> integer: normal numerical compare
  * integer <=> string: integers are newer
  * integer <=> list: integers are newer
  * string <=> string: if it's a qualifier, qualifier compare,  
else lexical compare,

 taking into account if either is a qualifier.
  * string <=> list: list is newer
  * list <=> list: recursion, same as a 'top-level' version  
compare. Where one list is shorter,
  '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 => 2.0- 
alpha <=> 2.0.0 = -1 (2.0 = newer))


Now for some examples to explain the rules above:

(note; i'm using the following notation:
   [1, 0] is a list with items 1, 0;
   [1, 0, [2, 3]] is a list with items 1, 0, [2, 3] where the  
latter is a sublist)


Version parsing:

'1.0':  [1, 0]
'1.0.0.0.0' [1, 0, 0, 0, 0]
'1.0-2.3':  [1, 0, [2, 3]]
'1.0-2-3':  [1, 0, [2, [3]]]

'1.0-alpha-1':  [1, 0, ["alpha", [1]]]
'1.0alpha1':[1, 0, ["alpha", [1]]] or [1, 0, "alpha", 1],  
which is the current implementation (see bottom)



String sorting (qualifiers)

SNAPSHOT < alpha < beta < gamma < rc < ga < unknown(lexical sort)  
< '' < sp


(ga = latest rc, final version
 '' = no qualifier, final version
 sp = service pack, improvement/addition on final release)

usually systems either use '' or ga, not both.

so 1.0-rc3 < 1.0-ga == 1.0 < 1.0-sp1 < 1.0.1


Comparing;

1)
  1.0-SNAPSHOT   <=>   1.0
  [1, 0, [SNAPSHOT]] <=>   [1, 0]

the first 2 items are equal, the last is assumed to be 0 for the  
right hand, and thus is newer.


2)
  1.0-beta-3<=>  1.0-alpha-4

  [1, 0, ["beta", [3]]] <=> [1, 0, ["alpha", [4]]]

  same here, then "beta" is newer then "alpha" so the first half wins

3)
  1.0-2.3  <=>  1.0-2-3
  [1, 0, [2, 3]]   <=>  [1, 0, [2, [3]]]
first 2 items are the same, then this is left;
  [2, 3]  <=>   [2, [3]]
  first item is the same, second item: the left list wins since  
the right one is a sublist.
  So 1.0-2.3 is newer than 1.0-2-3 (which seems right: -[digit]  
usually indicates a maintainer update,
  and '.' here a bugfix version, though i doubt this will be a  
valid use

Re: Feedback Needed on Release Reporting Tool


Hi, some more comments:

First: very nice, extremely handy for voting.

Jason van Zyl wrote:

On 18 Dec 06, at 10:19 PM 18 Dec 06, John Tolentino wrote:


Hi Everyone,

Been working on a tool to generate reports for release candidates and
this is a mock of what it should look like:
http://people.apache.org/~jtolentino/release-reports/MockReport.html

We can send this generated page to the dev list when we call for a 
release.


I appreciate any feedback so I can improve the reporting (and before I
go further into implementation).



I would link the "Issues Resolved for This Release" to the roadmap in 
the issue tracking system.




I agree. Maybe even use a JIRA/whateverIssueSystem embedded report (rss
feed for the jira changelog formatted in the site's style).

I would also link each of the resolved issues to the issue tracking 
system so you can navigate from the report to the exact issue.


Right.

Maybe some SCM information, what system is being used and the "label" 
instead of revision which is SVN specific and a link, if possible, to 
that revision in the SCM. For SVN and CVS this is easy with ViewCVS.


John's comment about labels: agreed. I only know 1 system that supports labels
and that's Clearcase; labels don't specify a fixed version. Perhaps a revision
number is better, or a tag/branch. Though all those can change.
For CVS, each file has it's own version history, so you should list all
source files and their versions, though there's no easy way to check that out.
Perhaps a CVS timestamp works best in that case - there can never be 2 commits
with the same timestamp AFAIK.



That's all I can see at first glance. Though I think that getting 
everything easy to see in one page is a good goal. We can link to things 
like the docck report and the expanded view of deliverables. Get it all 
on one page and link. If the results are OK then people most likely 
won't look at them, but they can if they want. One clear page of the 
state of the release would be nice.


Right. I personally don't like raw maven output on such a page - the docck 
report plugin
should just generate a normal report page, preferrably embed it in this page.

What's the 'download link' for? I can see how that's useful for assembly 
releases,
like maven-2.0.x-bin.tar.gz, but for plugins/other loose artifacts, would it 
point
to the jar in the repository? Is that useful?

'Release date: 12/10/1815' wow, i didn't think they had computers back then ;)
(I'd prefer ISO dates or a tztimestamp btw: 2006/12/10 or 2006/12/10 13:14:15 
CEST)

Another thought about the docck report: should we list that on the page at all?
I think that, and the license header stuff are just plugins that fail the build 
if
the project is not compliant. So we should assume that when those plugins are 
enabled/used,
the project satisfies the requirements. A link to the project (staging)site 
which already
contains all the reports should be enough, right?

Also - when the release is made, will this page be available on the project 
site somewhere?
So people can see the project history, examine changelogs, etc.

-- Kenney



Jason.


Thanks,
John

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack

2006-12-19 Thread Graham Leggett

On Tue, December 19, 2006 5:15 pm, Bhupendra Bhardwaj wrote:

>> The most simple solution right now is probably to add
>> http://repo1.maven.org/eclipse/ to your list of repositories in
>> settings.xml.

> Not really. Because the solution I was looking for was to package my RCP
> app
> for all platforms and the repo1.maven.org/eclipse only has swt jar for
> win32
> platform.

And the solution to that is to point eclipse:make-artifacts at the eclipse
deltapack, and import those jars into the repository as well. This worked
for us.

Regards,
Graham
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning


Carlos Sanchez wrote:

the other tags that can be reduced, but losing simplicity. Not using
attributes also makes the pom verbose and nobody questions that.


They do, actually - it's been discussed here before.


As I said we can have a pure String representation for those projects
that don't want to follow our suggestion, but they won't have the
added features.


What added features? The ability to compare version numbers? A bit 
fundamental imho.



--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Feedback Needed on Release Reporting Tool



On 19 Dec 06, at 10:38 AM 19 Dec 06, John Casey wrote:


On 12/19/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:



Maybe some SCM information, what system is being used and the "label"
instead of revision which is SVN specific and a link, if possible, to
that revision in the SCM. For SVN and CVS this is easy with ViewCVS.




IMO, it needs to be more than a label. Labels can be moved in most SCM
systems, which makes this label a floating point. While it would  
definitely
be good to have the label in there somewhere, it also makes a lot  
of sense
to me to have specific revisions (SVN name; versions in CVS, not  
sure what
nomenclature is for other systems...) that identifies exactly which  
version

of each souce file is included in the binary.



Yah, by "label" I mean something like the revision in SVN which is  
exact.


Jason.


Otherwise, very impressive!

-john



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

Ah. Well. Most libraries (think Jakarta commons) have a spec side and  
an implementation side. According to the spec, we would need  
something like 1.2.3-4567. The spec suggests, but does not limit to,  
a build number for the implementation identification. There is no  
problem with the major.minor.micro scheme for the spec version, but  
an overly restrictive Maven standard might rule out having 2 separate  
parts. I just wanted to say that Maven should look out for that (I do  
know that most important libs in the wild don't follow the standard,  
but that's something different -- eclipse is a bit cleaner than  
Apache in that respect).

On 19 Dec 2006, at 10:48, Tom Huybrechts wrote:

From the spec:

A version string is a series of positive numbers separated by periods.
The numbers are compared component by component from left to right. If
any number is greater than the corresponding number of the supplied
string the method returns true. If the number is less than it returns
false. If the corresponding numbers are equal the next number is
examined.

That shouldn't be a problem...

On 12/19/06, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:

I believe that Maven version number support should at least make it
possible to apply the specification / implementation version
numbering scheme that is part of the Java standard ().

On 19 Dec 2006, at 9:33, [EMAIL PROTECTED] wrote:

> Jason Dillon <[EMAIL PROTECTED]> schrieb am 19.12.2006  
01:26:54:

>
>> I've seen projects switch back and forth... depends on who is in
>> power at the time and what style they like.  So it would be  
best if

>> mvn would be able comprehend:
>
> Since versions are such an important information in Maven, Maven
> should
> refuse version numbers which aren't easily comparable.
>
> How about forcing the contents of the version element in the POM to
> 1-3
> digits, separated by dots? That would "help" people who can't  
decide.

>
> After that, you can add something with "-" which maven will just
> string-compare (so alpha10 comes between alpha1 and alpha2).
>
> Regards,
>
> --
> Aaron Digulla
>
>  
-

> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Feedback Needed on Release Reporting Tool

2006-12-19 Thread John Casey


On 12/19/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:



Maybe some SCM information, what system is being used and the "label"
instead of revision which is SVN specific and a link, if possible, to
that revision in the SCM. For SVN and CVS this is easy with ViewCVS.




IMO, it needs to be more than a label. Labels can be moved in most SCM
systems, which makes this label a floating point. While it would definitely
be good to have the label in there somewhere, it also makes a lot of sense
to me to have specific revisions (SVN name; versions in CVS, not sure what
nomenclature is for other systems...) that identifies exactly which version
of each souce file is included in the binary.

Otherwise, very impressive!

-john

Re: downloading eclipse runtime binary or RCP delta pack

2006-12-19 Thread Bhupendra Bhardwaj


On 12/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


> So, what is the way forward?

The most simple solution right now is probably to add
http://repo1.maven.org/eclipse/ to your list of repositories in
settings.xml.




Not really. Because the solution I was looking for was to package my RCP app
for all platforms and the repo1.maven.org/eclipse only has swt jar for win32
platform.

Regards,
Bhupendra

Regards,


--
Aaron Digulla

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

2006-12-19 Thread Max Bowsher

Barrie Treloar wrote:
>> I've had to comment out one assert: 2.0.1-xyz < 2.0.1. I think
>> generally this is not the case. For example,
>> the wiki guide to patching plugins states that you could patch a
>> plugin and change it's version to 2.0-INTERNAL.
>> In this case, 2.0 would be newer than 2.0-INTERNAL, which renders the
>> wiki description invalid. In my sample
>> implementation, 2.0.1-xyz is newer than 2.0.1.
> 
> To quote BBWM page 60: "It is intended that the qualifier indicates a
> version
> prior to release" thus
>   2.0.1-xyz < 2.0.1
> is correct.
> The -INTERNAL was always meant to be a qualifier.
> Thus:
>  2.0-SNAPSHOT < 2.0-INTERNAL < 2.0

Except, that's not have the Maven 2.0.4 code treats them. It does:

  2.0-INTERNAL < 2.0-SNAPSHOT < 2.0

i.e. the qualifiers are compared lexicographically, and 'I' < 'S'.

Max.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

2006-12-19 Thread Max Bowsher

[EMAIL PROTECTED] wrote:
> After that, you can add something with "-" which maven will just 
> string-compare (so alpha10 comes between alpha1 and alpha2).

Not true, actually. Maven actually has some weird extra logic that kicks
in when one string component is a prefix of the other, such that actually:

   alpha10 < alpha1 < alpha2

Yes, that's bizarre. But it is what it actually does.

Max.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Feedback Needed on Release Reporting Tool


On 18 Dec 06, at 10:19 PM 18 Dec 06, John Tolentino wrote:


Hi Everyone,

Been working on a tool to generate reports for release candidates and
this is a mock of what it should look like:
http://people.apache.org/~jtolentino/release-reports/MockReport.html

We can send this generated page to the dev list when we call for a  
release.


I appreciate any feedback so I can improve the reporting (and before I
go further into implementation).



I would link the "Issues Resolved for This Release" to the roadmap in  
the issue tracking system.


I would also link each of the resolved issues to the issue tracking  
system so you can navigate from the report to the exact issue.


Maybe some SCM information, what system is being used and the "label"  
instead of revision which is SVN specific and a link, if possible, to  
that revision in the SCM. For SVN and CVS this is easy with ViewCVS.


That's all I can see at first glance. Though I think that getting  
everything easy to see in one page is a good goal. We can link to  
things like the docck report and the expanded view of deliverables.  
Get it all on one page and link. If the results are OK then people  
most likely won't look at them, but they can if they want. One clear  
page of the state of the release would be nice.


Jason.


Thanks,
John

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

> 
>   1
>   2
>   1
>   123
> 

It's just as simple to specify a regexp which defines what is allowed as 
the text child for the version element.

Do not break everything up into one element. That's an XML sickness from 
the DTD era (or rather the pre-XSD/Schema era).

Regards,

-- 
Aaron Digulla


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack

> So, what is the way forward?

The most simple solution right now is probably to add 
http://repo1.maven.org/eclipse/ to your list of repositories in 
settings.xml.

Regards,

-- 
Aaron Digulla

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JavaOne talks


Hi,

More conference stuff. For JavaOne I have submitted a talk about Team  
Collaboration and Developer productivity and a talk on a large Ant  
conversion and the benefits derived from the conversion. This talk  
will be co-presented by an Architect at the large financial services  
company for whom the conversion was done. Might be good to organize  
some standard BOFs here as well.


Jason.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ApacheCon Talks


Hi,

Just checking in with folks to see if anyone is planning ApacheCon  
talks. I'm planning on doing the introduction to Maven talk, and I'm  
talking with Rod Coffin about working with him on his Enterprise  
Maven talk and I would also like to once again organize the BOFs I  
did the last time, "Maven Community BOF", and "Enterprise Maven BOF".  
Just trying to organize with others before submitting everything.


Jason.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ApacheCon Talks


Hi,

Just checking in with folks to see if anyone is planning ApacheCon  
talks. I'm planning on doing the introduction to Maven talk, and I'm  
talking with Rod Coffin about working with him on his Enterprise  
Maven talk and I would also like to once again organize the BOFs I  
did the last time, "Maven Community BOF", and "Enterprise Maven BOF".  
Just trying to organize with others before submitting everything.


Jason.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning


On 12/19/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:



Carlos Sanchez wrote:
> Sound like a lot of added complexity that will cause trouble to all
> tooling on top of Maven
>

How so? The current implementation is too complex, this one is pretty
straight forward - it allows for versions of any length.



I meant yours AND current one are both complex, although yours wins ;)

Whatever parser/validation code you write will need to be used in all
tooling, like any IDE pom editor, pom converters,... you may say
that's fine but think that tools could also be implemented in other
languages.




> What about forcing the xml schema to a standard versioning system. If
> it's used then you'll benefit from all Maven goodies. If you just use
> a String Maven will do its best.
>
> It's gonna be more complex for manual editing but being standard xml
> will be easier to implement
>

It's already implemented. ;) Plus my sample implementation supports the current 
(limited)
version scheme implementation and so far all others I've come across, which the 
current one
doesn't.

This is definitely too verbose. Plus, we cannot force a version numbering scheme
on people, since there are already big projects out there that have a good
version numbering scheme which doesn't fit in this one.


I agree is too verbose, but the same happens with  and all
the other tags that can be reduced, but losing simplicity. Not using
attributes also makes the pom verbose and nobody questions that.

As I said we can have a pure String representation for those projects
that don't want to follow our suggestion, but they won't have the
added features.



Though the tag you list above looks good, but not for version definitions, but
we could use something like that for version scheme specifications so we can 
validate
supplied versions, for instance in a super pom:


 
 
 
 
   alpha
   beta
 
 


Or, I'd prefer XSD schema notation to specify the above. It could validate a 
version like this:

2.0-alpha-3 which is rendered as

(your example, sort of)

 1
 2
 alpha
 123


but users would just specify '2.0-alpha-3' in the pom.

-- Kenney

> On 12/18/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> The current versioning implementation is IMHO too 'tight'. For instance,
>> 2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of '2.0.0alpha1',
>> whereas this should
>> be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1.
>>
>> Here's a proposal:
>>
>> - don't use the current 4-digit limitation, but instead list with a
>> random amount of entries
>> - entries are separated by dots or dashes
>> - entries are separated by transition to/from alpha to numeric
>> - sub-lists are indicated by '-'
>> - entries can be either: string, integer, or sublist
>> - versions are compared entry by entry, where we have 3 options;
>>   * integer <=> integer: normal numerical compare
>>   * integer <=> string: integers are newer
>>   * integer <=> list: integers are newer
>>   * string <=> string: if it's a qualifier, qualifier compare, else
>> lexical compare,
>>  taking into account if either is a qualifier.
>>   * string <=> list: list is newer
>>   * list <=> list: recursion, same as a 'top-level' version compare.
>> Where one list is shorter,
>>   '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 =>
>> 2.0-alpha <=> 2.0.0 = -1 (2.0 = newer))
>>
>> Now for some examples to explain the rules above:
>>
>> (note; i'm using the following notation:
>>[1, 0] is a list with items 1, 0;
>>[1, 0, [2, 3]] is a list with items 1, 0, [2, 3] where the latter
>> is a sublist)
>>
>> Version parsing:
>>
>> '1.0':  [1, 0]
>> '1.0.0.0.0' [1, 0, 0, 0, 0]
>> '1.0-2.3':  [1, 0, [2, 3]]
>> '1.0-2-3':  [1, 0, [2, [3]]]
>>
>> '1.0-alpha-1':  [1, 0, ["alpha", [1]]]
>> '1.0alpha1':[1, 0, ["alpha", [1]]] or [1, 0, "alpha", 1], which is
>> the current implementation (see bottom)
>>
>>
>> String sorting (qualifiers)
>>
>> SNAPSHOT < alpha < beta < gamma < rc < ga < unknown(lexical sort) < ''
>> < sp
>>
>> (ga = latest rc, final version
>>  '' = no qualifier, final version
>>  sp = service pack, improvement/addition on final release)
>>
>> usually systems either use '' or ga, not both.
>>
>> so 1.0-rc3 < 1.0-ga == 1.0 < 1.0-sp1 < 1.0.1
>>
>>
>> Comparing;
>>
>> 1)
>>   1.0-SNAPSHOT   <=>   1.0
>>   [1, 0, [SNAPSHOT]] <=>   [1, 0]
>>
>> the first 2 items are equal, the last is assumed to be 0 for the right
>> hand, and thus is newer.
>>
>> 2)
>>   1.0-beta-3<=>  1.0-alpha-4
>>
>>   [1, 0, ["beta", [3]]] <=> [1, 0, ["alpha", [4]]]
>>
>>   same here, then "beta" is newer then "alpha" so the first half wins
>>
>> 3)
>>   1.0-2.3  <=>  1.0-2-3
>>   [1, 0, [2, 3]]   <=>  [1, 0, [2, [3]]]
>> first 2 items are the same, then this is left;
>>   [2, 3]  <=>   [2, [3]]
>>   first item is the same, second item: the left list wins since the
>> right one is a sublist.
>>   So 1.0-2.3 is newer than 1.0-2-3 (which s

Re: Maven and Fedora

On 19 Dec 06, at 5:52 AM 19 Dec 06, Steve Loughran wrote:

Jason van Zyl wrote:

Yah, I don't buy it. I don't know anyone who uses RPMs to do  
anything with Java.

Nobody who works java does, but the goal is to let people who work  
with OSS systems use Java apps the way they work with C++, Perl,  
python, mono and ruby code --with one central management tool and  
without caring what language they are writtien on.

I would have to be frank and say I'm not really interested in the  
lowest common denominator. The mail from the complainer has no  
qualification whatsoever. People have complained in the past about  
everything from Make, Ant, and now Maven. What is ridiculous is that  
the project itself, in this case JLine, moved to Maven because it's  
easier for them and JPackage people are complaining because it's no  
long easy for them.

Jason.

ps, from the jpackage mail list:

---

 Original Message 
Subject: Re: [JPackage-discuss] Jline update
Date: Mon, 18 Dec 2006 06:13:04 -0500
From: David Walluck
Reply-To: Discussion about JPackage project [EMAIL PROTECTED]>

To: Discussion about JPackage project <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alexander Kurtakov wrote:
> I'm trying to package the JRuby 0.9.2 release for jpackage. I  
have already
> made a spec file for jvyaml which is a prerequisite for the JRuby 
(attached to
> the mail). I've tried to update the Jline package but due to its  
change of
> build process (from ant to maven) I've failed so can somebody  
help me.

Someone just needs to create build.xml files for all these
maven-dependent packages. Either some generic build.xml, or a maven to
ant build.xml tool. I thought maven itself had the ability to do that,
but if it requires maven to not  require maven, isn't that a bit  
pointless?

I hate maven because it makes my life so much more difficult. You  
think
as a package builder a tool that is supposed to build things would  
make

your life easier. Not only doesn't it make it easier, but how many new
dependencies does it pull in? Probably more than 100 new packages are
required to build/install maven.

- --
Sincerely,

David Walluck

-

Its not that the jpackage people want to use maven. its that  
without that support anything that uses maven doensnt build any  
more. When projects switch from Ant to maven, they drop off gump,  
they drop out of jpackage. As far as the rest of the OSS community  
is concerned, they drop off the network.

-Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning


Richard van der Hoff wrote:

Hi,


Carlos Sanchez wrote:

Sound like a lot of added complexity that will cause trouble to all
tooling on top of Maven


Can you justify that with an example, at all?


What about forcing the xml schema to a standard versioning system. If
it's used then you'll benefit from all Maven goodies. If you just use
a String Maven will do its best.

For instance


 1
 2
 1
 123



The problem is basically that this simply isn't powerful enough to cover 
all the various versioning schemes there are in the wild. Suggesting 
forcing everybody to conform to your idea of versioning isn't at all 
helpful; similarly imposing a complex mapping between upstream and maven 
versions for a project is unattractive.


I agree. As i said in another mail, something like this could be used to specify
a weird versioning scheme. Versions are ONLY needed for comparison, nothing 
else, so that's
where proper parsing and comparing comes into play. Limiting freedom in using version schemes 
just so we can compare them is not the way to go IMHO.


Furthermore you don't leave any scope for extension such as might be 
required for local modifications of a project.


Stéphane also suggested forcing a particular versioning convention on 
everybody - the same argument applies.


Regarding Kenney's proposal: as discussed on #maven, all sounds very 
sensible to me. I'm still fishing for, and failing to find, examples of 
failures for projects where people invert the precedence of . and -; 
however anyone doing that probably deserves what they get.


Still waiting.. ;)   Did we discuss this one: 1.0-2.3  <=> 1.0-2-3, which is newer? 
My algorithm would say 1.0-2.3.


I don't think it would be unreasonable to expect a project's maven 
versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping 
through hoops to make this work may not be worthwhile.


True. But as others suggested, when project leads are replaced, version schemes
may change also. Though I think that if that's the case, then they'll probably
stick to the current scheme until a final (bugfix) release has been made, so
you will probably never find 1.0alpha2 <=> 1.0-alpha-3, but rather 
1.0alpha2 <=> 1.1-alpha-2. I think this is a limitation we could easily impose.


Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ? 
What happens when we've released an alpha, but want to continue hacking 
on SNAPSHOTs before releasing another? we want SNAPSHOT between rc and 
ga, no?


Yes we do. But, when trunk always has 2.0-SNAPSHOT, you don't know of an alpha
or beta or rc has been released yet. I'd say: 


1.0-SNAPSHOT < 1.0-alpha-1-SNAPSHOT < 1.0-alpha-2-SNAPSHOT < ... < 1.0-rc1 < 
1.0-rc2-SNAPSHOT.

Snapshots also have to be possible before the first alpha (which is pretty 
common to do),
and if we allow SNAPSHOT's to be present everywhere (and use it as a qualifier, 
so:
SNAPSHOT < alpha < SNAPSHOT < beta <..), we can never compare with snapshots.

From experience I'd say people start out with 1.0-SNAPSHOT, and later do 
1.0-rc-1. Then before
the ga is released, they don't revert back to 1.0-SNAPSHOT (or shouldn't, i've 
seen people do it). This
produces unpredictable results.


Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
implementation, 2.0.1-xyz is newer than 2.0.1."? 


No it doesn't. The current implementation assumes 2.0.1 is newer than 2.0.1-xyz.


To quote Barrie Treloar who quoted a book:

 quote BBWM page 60: "It is intended that the qualifier indicates a version
 prior to release" 
 
 thus 2.0.1-xyz < 2.0.1 is correct.

 The -INTERNAL was always meant to be a qualifier.
 Thus: 2.0-SNAPSHOT < 2.0-INTERNAL < 2.0 


I'm missing some context here, but 'xyz' is not a KNOWN qualifier. Our 
qualifiers
are 'alpha', 'beta', 'rc, 'ga', 'sp'. If it's a random string, and we don't 
call it a qualifier,
it could well mean a newer version.

The problem is where to place strings that are unknown qualifiers:

 alpha < beta < rc < ga <  (here?) < "" < (here?) < sp < (here?)


I may just be 
misunderstanding your explanation, but if you could clarify what exactly 
happens when a given component isn't present, and for unrecognised 
qualifiers, that would be useful.


Right now: if a component is not present, in the case of:

integer <=> null:  integer==0 ? 0 : 1 (this fixes '2.0' <=> '2' which is 0, and 2.1 
<=> 2 which is 1)

list<=> null: does a compare for list <=> [empty list], which finally results in either 
integer <=> null or string <=> null

string <=> null:   see the 'alpha < beta' list above.

  Use the empty string instead of null, then compare string <=> 
"". So when comparing
  1-alpha with 1, this is the same as comparing "1-alpha" and 
"1-". Which one is newer
  depends on wheter 'string' is listed before or after the "" 
in the list above.

  Algorithm for string <=> string:

  Construct a string for the left hand s

Re: The Future of the Release Process.


robert burrell donkin wrote:

On 12/19/06, Steve Loughran <[EMAIL PROTECTED]> wrote:




I'd like to see POM auditing in there somewhere.


+1

henri's been talking about adding this to RAT. IMHO this should be
implemented as a separate component so that it could be used by a
variety of applications: for example, it might be interesting to be
able to apply policy rules as part of subversion commits or staging
updates.



I have a colleague who has been converting all the POMs and .class files 
in the repository to RDF, ready for auditing. We are


1. planning an apache con EU talk, "fear the repository police".
2. looking to get management approval to hand the code to the MIT Simile 
project (e.g. Stefano)
3. Thinking of something to audit the metadata. Maybe in prolog (my 
choice), maybe something else.


Working title "repo-man". This not only lets us have a good name, it 
gives us good quotes

"It's 4 A.M., do you know where your jar is?"
"You don't even know what's in your own trunk! And you know what? I 
think you're afraid to find out! "


-steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning




Stephane Nicoll wrote:

On 12/19/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:

Stéphane also suggested forcing a particular versioning convention on
everybody - the same argument applies.


I am not sure that's what I meant. If we want to be able to compare
versions we need to standardize things. That sounds obvious to me.
Maven is about standardization, I think it would be good if we tackle
the component numbering scheme.



Standardization is good. But, we don't need a standard versioning scheme just 
to compare
different versions, because when versions are compared, they are always for the 
same artifact.
We can assume that people use a consistent versioning scheme for one project. 
If they don't then
maven can't help them. 


I think that the best option would be to provide a defaulting and
allowing anyone to plug in a custom scheme (and the related algorithm
used to compare the versions)


I've proposed this too, a while back, at the wiki (so +1) :)

The default handling would have to be as robust as possible, allowing for as 
much usecases
as we can, without the code being too complex, and without the need to 
customize often.
Convention over configuration should prevail - or in this case, default 
algorithms over
configuration.

So we should definitely support pluggable versioning schemes, someday, but for 
now I think
(without having to modify the pom), my parsing/comparing proposal is a step in 
the right direction
to be as generic and flexible as we can to support whatever schemes are out 
there and used widely
right now. At least, that was my goal, and I still would like to see some 
examples of schemes
that this one doesn't handle properly.

-- Kenney



WDYT?

Stéphane





Regarding Kenney's proposal: as discussed on #maven, all sounds very
sensible to me. I'm still fishing for, and failing to find, examples of
failures for projects where people invert the precedence of . and -;
however anyone doing that probably deserves what they get.

I don't think it would be unreasonable to expect a project's maven
versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping
through hoops to make this work may not be worthwhile.

Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ?
What happens when we've released an alpha, but want to continue hacking
on SNAPSHOTs before releasing another? we want SNAPSHOT between rc and
ga, no?

Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
implementation, 2.0.1-xyz is newer than 2.0.1."? I may just be
misunderstanding your explanation, but if you could clarify what exactly
happens when a given component isn't present, and for unrecognised
qualifiers, that would be useful.

I've found the current scheme quite limited, and certainly capable of
producing unexpected results, so I'm definitely in favour of making some
changes here.

Best regards,

Richard

--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning




[EMAIL PROTECTED] wrote:

Jason Dillon <[EMAIL PROTECTED]> schrieb am 19.12.2006 01:26:54:

I've seen projects switch back and forth... depends on who is in 
power at the time and what style they like.  So it would be best if 
mvn would be able comprehend:


Since versions are such an important information in Maven, Maven should 
refuse version numbers which aren't easily comparable.


How about forcing the contents of the version element in the POM to 1-3 
digits, separated by dots? That would "help" people who can't decide.


After that, you can add something with "-" which maven will just 
string-compare (so alpha10 comes between alpha1 and alpha2).


That's unacceptable, alpha1 < alpha2 < alpha10. 
We don't want to force versioning schemes on projects; that way you can never package Jboss and Eclipse

jars AND be compatible with all the versions out there already.



Regards,



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning




Carlos Sanchez wrote:

Sound like a lot of added complexity that will cause trouble to all
tooling on top of Maven



How so? The current implementation is too complex, this one is pretty
straight forward - it allows for versions of any length.


What about forcing the xml schema to a standard versioning system. If
it's used then you'll benefit from all Maven goodies. If you just use
a String Maven will do its best.

For instance


 1
 2
 1
 123


It's gonna be more complex for manual editing but being standard xml
will be easier to implement



It's already implemented. ;) Plus my sample implementation supports the current 
(limited)
version scheme implementation and so far all others I've come across, which the 
current one
doesn't.

This is definitely too verbose. Plus, we cannot force a version numbering scheme 
on people, since there are already big projects out there that have a good

version numbering scheme which doesn't fit in this one.

Though the tag you list above looks good, but not for version definitions, but
we could use something like that for version scheme specifications so we can 
validate
supplied versions, for instance in a super pom:






  alpha
  beta




Or, I'd prefer XSD schema notation to specify the above. It could validate a 
version like this:

2.0-alpha-3 which is rendered as 


(your example, sort of)

1
2
alpha
123


but users would just specify '2.0-alpha-3' in the pom.

-- Kenney


On 12/18/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:


Hi,

The current versioning implementation is IMHO too 'tight'. For instance,
2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of '2.0.0alpha1', 
whereas this should

be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1.

Here's a proposal:

- don't use the current 4-digit limitation, but instead list with a 
random amount of entries

- entries are separated by dots or dashes
- entries are separated by transition to/from alpha to numeric
- sub-lists are indicated by '-'
- entries can be either: string, integer, or sublist
- versions are compared entry by entry, where we have 3 options;
  * integer <=> integer: normal numerical compare
  * integer <=> string: integers are newer
  * integer <=> list: integers are newer
  * string <=> string: if it's a qualifier, qualifier compare, else 
lexical compare,

 taking into account if either is a qualifier.
  * string <=> list: list is newer
  * list <=> list: recursion, same as a 'top-level' version compare. 
Where one list is shorter,
  '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 => 
2.0-alpha <=> 2.0.0 = -1 (2.0 = newer))


Now for some examples to explain the rules above:

(note; i'm using the following notation:
   [1, 0] is a list with items 1, 0;
   [1, 0, [2, 3]] is a list with items 1, 0, [2, 3] where the latter 
is a sublist)


Version parsing:

'1.0':  [1, 0]
'1.0.0.0.0' [1, 0, 0, 0, 0]
'1.0-2.3':  [1, 0, [2, 3]]
'1.0-2-3':  [1, 0, [2, [3]]]

'1.0-alpha-1':  [1, 0, ["alpha", [1]]]
'1.0alpha1':[1, 0, ["alpha", [1]]] or [1, 0, "alpha", 1], which is 
the current implementation (see bottom)



String sorting (qualifiers)

SNAPSHOT < alpha < beta < gamma < rc < ga < unknown(lexical sort) < '' 
< sp


(ga = latest rc, final version
 '' = no qualifier, final version
 sp = service pack, improvement/addition on final release)

usually systems either use '' or ga, not both.

so 1.0-rc3 < 1.0-ga == 1.0 < 1.0-sp1 < 1.0.1


Comparing;

1)
  1.0-SNAPSHOT   <=>   1.0
  [1, 0, [SNAPSHOT]] <=>   [1, 0]

the first 2 items are equal, the last is assumed to be 0 for the right 
hand, and thus is newer.


2)
  1.0-beta-3<=>  1.0-alpha-4

  [1, 0, ["beta", [3]]] <=> [1, 0, ["alpha", [4]]]

  same here, then "beta" is newer then "alpha" so the first half wins

3)
  1.0-2.3  <=>  1.0-2-3
  [1, 0, [2, 3]]   <=>  [1, 0, [2, [3]]]
first 2 items are the same, then this is left;
  [2, 3]  <=>   [2, [3]]
  first item is the same, second item: the left list wins since the 
right one is a sublist.
  So 1.0-2.3 is newer than 1.0-2-3 (which seems right: -[digit] 
usually indicates a maintainer update,
  and '.' here a bugfix version, though i doubt this will be a valid 
usecase).


4)
   1.0-alpha-2  <=>  1.0alpha2

   The current implementation parses this as:

   [1, 0, [alpha, [2]]] <=>  [1, 0, alpha, 2]
   The right one is newer.

   If we change parsing '1.0alpha2' by using sublists on alpha<->digit 
transition, both will parse

   as [1, 0, ["alpha", [2]]. I think this is preferrable.

   we may need to flatten the list or assume alpha<->digit transitions 
create a new sublist.



So, I've given both a way to represent versions in a generic way, and 
an algorithm to compare versions.
Replacing DefaultArtifactVersion is easy enough (see bottom), though 
ranges may be a bit more complicated.


This scheme will support the eclipse version numbering: 
http://wiki.eclipse.org/index.php/Version_Numbering
(basically: major.m

Re: The Future of the Release Process.

2006-12-19 Thread robert burrell donkin


On 12/19/06, Steve Loughran <[EMAIL PROTECTED]> wrote:




I'd like to see POM auditing in there somewhere.


+1

henri's been talking about adding this to RAT. IMHO this should be
implemented as a separate component so that it could be used by a
variety of applications: for example, it might be interesting to be
able to apply policy rules as part of subversion commits or staging
updates.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

2006-12-19 Thread Stephane Nicoll


On 12/19/06, Richard van der Hoff <[EMAIL PROTECTED]> wrote:

Stéphane also suggested forcing a particular versioning convention on
everybody - the same argument applies.


I am not sure that's what I meant. If we want to be able to compare
versions we need to standardize things. That sounds obvious to me.
Maven is about standardization, I think it would be good if we tackle
the component numbering scheme.

I think that the best option would be to provide a defaulting and
allowing anyone to plug in a custom scheme (and the related algorithm
used to compare the versions)

WDYT?

Stéphane





Regarding Kenney's proposal: as discussed on #maven, all sounds very
sensible to me. I'm still fishing for, and failing to find, examples of
failures for projects where people invert the precedence of . and -;
however anyone doing that probably deserves what they get.

I don't think it would be unreasonable to expect a project's maven
versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping
through hoops to make this work may not be worthwhile.

Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ?
What happens when we've released an alpha, but want to continue hacking
on SNAPSHOTs before releasing another? we want SNAPSHOT between rc and
ga, no?

Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
implementation, 2.0.1-xyz is newer than 2.0.1."? I may just be
misunderstanding your explanation, but if you could clarify what exactly
happens when a given component isn't present, and for unrecognised
qualifiers, that would be useful.

I've found the current scheme quite limited, and certainly capable of
producing unexpected results, so I'm definitely in favour of making some
changes here.

Best regards,

Richard

--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning


Carlos Sanchez wrote:

Sound like a lot of added complexity that will cause trouble to all
tooling on top of Maven


Can you justify that with an example, at all?


What about forcing the xml schema to a standard versioning system. If
it's used then you'll benefit from all Maven goodies. If you just use
a String Maven will do its best.

For instance


 1
 2
 1
 123



The problem is basically that this simply isn't powerful enough to cover 
all the various versioning schemes there are in the wild. Suggesting 
forcing everybody to conform to your idea of versioning isn't at all 
helpful; similarly imposing a complex mapping between upstream and maven 
versions for a project is unattractive.


Furthermore you don't leave any scope for extension such as might be 
required for local modifications of a project.


Stéphane also suggested forcing a particular versioning convention on 
everybody - the same argument applies.


Regarding Kenney's proposal: as discussed on #maven, all sounds very 
sensible to me. I'm still fishing for, and failing to find, examples of 
failures for projects where people invert the precedence of . and -; 
however anyone doing that probably deserves what they get.


I don't think it would be unreasonable to expect a project's maven 
versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping 
through hoops to make this work may not be worthwhile.


Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ? 
What happens when we've released an alpha, but want to continue hacking 
on SNAPSHOTs before releasing another? we want SNAPSHOT between rc and 
ga, no?


Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
implementation, 2.0.1-xyz is newer than 2.0.1."? I may just be 
misunderstanding your explanation, but if you could clarify what exactly 
happens when a given component isn't present, and for unrecognised 
qualifiers, that would be useful.


I've found the current scheme quite limited, and certainly capable of 
producing unexpected results, so I'm definitely in favour of making some 
changes here.


Best regards,

Richard

--
Richard van der Hoff <[EMAIL PROTECTED]>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The Future of the Release Process.


On 12/19/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:

Hello Joakim,

I like this discussion, I am a big fan of automating the release
process.

I also have some hands on experience being RM for Ant 1.6 and 1.7.

For Ant 1.7, we are using what you call the staged release process.

When I prepare a build, I have to assume that the vote on the
binaries will be positive and prepare everything with a release
version in mind.

Tagging the release should to my opinion happen between preparing and
staging the release.

To make sure everything is clean, the SVN sandbox could be recreated
based on the tag.

When I did my first build of ANT 1.7.0 last week, someone checked
code in between the time when I created my SVN sandbox and the time
when I created my tag.
In the end, this change was included in the tag but not in my build.
Bad ...  See [1] the command used to create the tag



This cannot happen if you make a tag based from your local working
copy instead of trunk
The release plugin already does this.

http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html

tom


Also, creating a branch for a release is optional. Right now we are
releasing Ant 1.7.0 from the trunk, and we
do not have a ANT_17_BRANCH.

Suggested modifications for your staged release process :

 c) 'prepare' release (occurs once)
   * Create a branch using provided Branch ID for this release.
   * Update poms in branch to provided Release Version ID.
+* Optionally update documentation in branch to provided
Release Version ID.
   * Update poms in trunk to provided Next Development
Version ID.

  +  d) tag the release (occurs 1 or more times)

  +  e) create a new SVN sandbox using the tag created in d)

  -  d) stage release (occurs 1 or more times)
  +  f) 'stage' release (occurs 1 or more times)


It would be cool if you could persist your ideas concerning the
release process to a document in SVN or to a Wiki page.

Regards,

Antoine


[1]
svn copy https://svn.apache.org/repos/asf/ant/core/trunk \
 https://svn.apache.org/repos/asf/ant/core/tags/ANT_170 \
 -m "Tagging version 1.7.0 of Ant"

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The Future of the Release Process.

2006-12-19 Thread Antoine Levy-Lambert


Hello Joakim,

I like this discussion, I am a big fan of automating the release  
process.


I also have some hands on experience being RM for Ant 1.6 and 1.7.

For Ant 1.7, we are using what you call the staged release process.

When I prepare a build, I have to assume that the vote on the  
binaries will be positive and prepare everything with a release  
version in mind.


Tagging the release should to my opinion happen between preparing and  
staging the release.


To make sure everything is clean, the SVN sandbox could be recreated  
based on the tag.


When I did my first build of ANT 1.7.0 last week, someone checked  
code in between the time when I created my SVN sandbox and the time  
when I created my tag.
In the end, this change was included in the tag but not in my build.  
Bad ...  See [1] the command used to create the tag


Also, creating a branch for a release is optional. Right now we are  
releasing Ant 1.7.0 from the trunk, and we

do not have a ANT_17_BRANCH.

Suggested modifications for your staged release process :

c) 'prepare' release (occurs once)
  * Create a branch using provided Branch ID for this release.
  * Update poms in branch to provided Release Version ID.
+* Optionally update documentation in branch to provided  
Release Version ID.
  * Update poms in trunk to provided Next Development  
Version ID.


 +  d) tag the release (occurs 1 or more times)

 +  e) create a new SVN sandbox using the tag created in d)

 -  d) stage release (occurs 1 or more times)
 +  f) 'stage' release (occurs 1 or more times)


It would be cool if you could persist your ideas concerning the  
release process to a document in SVN or to a Wiki page.


Regards,

Antoine


[1]
svn copy https://svn.apache.org/repos/asf/ant/core/trunk \
https://svn.apache.org/repos/asf/ant/core/tags/ANT_170 \
-m "Tagging version 1.7.0 of Ant"

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The Future of the Release Process.


Joakim Erdfelt wrote:

This is just a synopsis email about the future of the release process.

  Disclaimer: I am not attempting to set policy, just to get discussion
going,
  document it, and work towards the ideal toolchain that
make the
  future of apache releases smooth, consistent, and resilient



This is good, but some people out there are very sensitive to their 
build tools dictating policy, so get a broad consensus on this before 
shipping .


One issue is that I believe apache requires the PMC to vote on a built 
up redistributable artifact. You dont vote before you release, you 
build, stick it in staging, download it, test it and then finally say 
"we ship this one".


I'd like to see POM auditing in there somewhere.



Desired End Goal:

  This discussion will revolve around the apache process for official
  releases of projects.

   1) Releases are non-SNAPSHOT.
   2) All releases shall be voted on.
  * Call a vote on the appropriate dev@ mailing list.
  * Wait 72 hours.
  * If unanimous +1 vote by 7 or more PMC members, then release
can occur before 72 hour window is up.
  * Document the following in the vote:
a) Project Name
b) Project Version in Subversion.
c) Desired Release Version ID.
d) Expected Next Development Version ID.
e) Age of development version (days since last non-snapshot release)
f) Downstream snapshot dependencies that might cause problems.
g) Jiras that have been closed/resolved for this release.
f) Tasks that have been completed in SCM but do not appear in the
   Jira completion list.
g) URL to jira completion report for this version.
h) SCM revision being voted on.
  * If a change occurs to the project, the vote should be updated
with the change and a new vote started. (this resets the 72 hours)
This only consitutes changes that occur in the project itself,
not downstream dependencies.
   2) A Released project will contain the following files.
  Example directory contents of a project artifact 'foo', version '1.0'
  * foo-1.0.pom(pom / metadata for artifact)
  * foo-1.0.jar(actual binary artifact)
  * foo-1.0-sources.jar(source code for artifact)
  * foo-1.0-javadoc.jar(javadoc for artifact)
   3) Each released file will be signed using the (apache.org) gpg signature
  of the commitor doing the release.
   4) Each released file and gpg signature will have a hashcode generated
  for the file (managed by wagon) in SHA1 and MD5 format.
   5) All jar files produced (binary, sources, and javadoc) will contain the
  following mandatory files:
  * META-INF/LICENSE.txt
  * META-INF/NOTICE.txt
   6) All source files in the sources.jar files will contain the following
  header.
  ---(snip)---
  Licensed to the Apache Software Foundation (ASF) under one
  or more contributor license agreements.  See the NOTICE file
  distributed with this work for additional information
  regarding copyright ownership.  The ASF licenses this file
  to you under the Apache License, Version 2.0 (the
  "License"); you may not use this file except in compliance
  with the License.  You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing,
  software distributed under the License is distributed on an
  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  KIND, either express or implied.  See the License for the
  specific language governing permissions and limitations
  under the License.
  ---(snip)---

Techniques:

  1) Original release plugin process.
 This is the release:prepare and release:perform technique.

 This technique does the following...
   a) Gather information about release IDs.
  * Release Version ID
  * Tag ID
  * Next Development Version ID
   a) Updates the poms in trunk to the provided Release Version ID.
   b) Tags these updated poms in subversion using the provided Tag ID.
   c) Updates the poms in trunk to the provided Next Development
Version ID.
   d) Builds the release using the Subversion Tag.
  * clean
  * integration-test
  * install
  * site
  * deploy (binary and site)

  2) Staged release process
 This process uses a staging workflow, there is no plugin for this
 process (yet).

 The benefits of this process is that a real binary is being blessed.
 This process also provides a way to resolve problems that occur
 during the release process.

 It goes like this...
   a) Call vote
   b) Wait on approval.
   c) Collect release information.
  * Release Version ID
  * Tag/Branch ID
  * Next Development Version ID
   c) 'prepare'

Re: Maven and Fedora

Jason van Zyl wrote:

Yah, I don't buy it. I don't know anyone who uses RPMs to do anything 
with Java.

Nobody who works java does, but the goal is to let people who work with 
OSS systems use Java apps the way they work with C++, Perl, python, mono 
and ruby code --with one central management tool and without caring what 
language they are writtien on.

ps, from the jpackage mail list:

---

 Original Message 
Subject: Re: [JPackage-discuss] Jline update
Date: Mon, 18 Dec 2006 06:13:04 -0500
From: David Walluck
Reply-To: Discussion about JPackage project <[EMAIL PROTECTED]>
To: Discussion about JPackage project <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alexander Kurtakov wrote:
> I'm trying to package the JRuby 0.9.2 release for jpackage. I have 
already
> made a spec file for jvyaml which is a prerequisite for the 
JRuby(attached to
> the mail). I've tried to update the Jline package but due to its 
change of

> build process (from ant to maven) I've failed so can somebody help me.

Someone just needs to create build.xml files for all these
maven-dependent packages. Either some generic build.xml, or a maven to
ant build.xml tool. I thought maven itself had the ability to do that,
but if it requires maven to not  require maven, isn't that a bit pointless?

I hate maven because it makes my life so much more difficult. You think
as a package builder a tool that is supposed to build things would make
your life easier. Not only doesn't it make it easier, but how many new
dependencies does it pull in? Probably more than 100 new packages are
required to build/install maven.

- --
Sincerely,

David Walluck

-

Its not that the jpackage people want to use maven. its that without 
that support anything that uses maven doensnt build any more. When 
projects switch from Ant to maven, they drop off gump, they drop out of 
jpackage. As far as the rest of the OSS community is concerned, they 
drop off the network.

-Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning


Sound like a lot of added complexity that will cause trouble to all
tooling on top of Maven

What about forcing the xml schema to a standard versioning system. If
it's used then you'll benefit from all Maven goodies. If you just use
a String Maven will do its best.

For instance


 1
 2
 1
 123


It's gonna be more complex for manual editing but being standard xml
will be easier to implement

On 12/18/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:


Hi,

The current versioning implementation is IMHO too 'tight'. For instance,
2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of '2.0.0alpha1', whereas 
this should
be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1.

Here's a proposal:

- don't use the current 4-digit limitation, but instead list with a random 
amount of entries
- entries are separated by dots or dashes
- entries are separated by transition to/from alpha to numeric
- sub-lists are indicated by '-'
- entries can be either: string, integer, or sublist
- versions are compared entry by entry, where we have 3 options;
  * integer <=> integer: normal numerical compare
  * integer <=> string: integers are newer
  * integer <=> list: integers are newer
  * string <=> string: if it's a qualifier, qualifier compare, else lexical 
compare,
 taking into account if either is a qualifier.
  * string <=> list: list is newer
  * list <=> list: recursion, same as a 'top-level' version compare. Where one 
list is shorter,
  '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 => 2.0-alpha <=> 
2.0.0 = -1 (2.0 = newer))

Now for some examples to explain the rules above:

(note; i'm using the following notation:
   [1, 0] is a list with items 1, 0;
   [1, 0, [2, 3]] is a list with items 1, 0, [2, 3] where the latter is a 
sublist)

Version parsing:

'1.0':  [1, 0]
'1.0.0.0.0' [1, 0, 0, 0, 0]
'1.0-2.3':  [1, 0, [2, 3]]
'1.0-2-3':  [1, 0, [2, [3]]]

'1.0-alpha-1':  [1, 0, ["alpha", [1]]]
'1.0alpha1':[1, 0, ["alpha", [1]]] or [1, 0, "alpha", 1], which is the 
current implementation (see bottom)


String sorting (qualifiers)

SNAPSHOT < alpha < beta < gamma < rc < ga < unknown(lexical sort) < '' < sp

(ga = latest rc, final version
 '' = no qualifier, final version
 sp = service pack, improvement/addition on final release)

usually systems either use '' or ga, not both.

so 1.0-rc3 < 1.0-ga == 1.0 < 1.0-sp1 < 1.0.1


Comparing;

1)
  1.0-SNAPSHOT   <=>   1.0
  [1, 0, [SNAPSHOT]] <=>   [1, 0]

the first 2 items are equal, the last is assumed to be 0 for the right hand, 
and thus is newer.

2)
  1.0-beta-3<=>  1.0-alpha-4

  [1, 0, ["beta", [3]]] <=> [1, 0, ["alpha", [4]]]

  same here, then "beta" is newer then "alpha" so the first half wins

3)
  1.0-2.3  <=>  1.0-2-3
  [1, 0, [2, 3]]   <=>  [1, 0, [2, [3]]]
first 2 items are the same, then this is left;
  [2, 3]  <=>   [2, [3]]
  first item is the same, second item: the left list wins since the right one 
is a sublist.
  So 1.0-2.3 is newer than 1.0-2-3 (which seems right: -[digit] usually 
indicates a maintainer update,
  and '.' here a bugfix version, though i doubt this will be a valid usecase).

4)
   1.0-alpha-2  <=>  1.0alpha2

   The current implementation parses this as:

   [1, 0, [alpha, [2]]] <=>  [1, 0, alpha, 2]
   The right one is newer.

   If we change parsing '1.0alpha2' by using sublists on alpha<->digit 
transition, both will parse
   as [1, 0, ["alpha", [2]]. I think this is preferrable.

   we may need to flatten the list or assume alpha<->digit transitions create a 
new sublist.


So, I've given both a way to represent versions in a generic way, and an 
algorithm to compare versions.
Replacing DefaultArtifactVersion is easy enough (see bottom), though ranges may 
be a bit more complicated.

This scheme will support the eclipse version numbering: 
http://wiki.eclipse.org/index.php/Version_Numbering
(basically: major.minor.bugfix.qualifier: [major, minor, bugfix, qualifier]
and Jboss: http://docs.jboss.org/process-guide/en/html/release-procedure.html,
(basically: X.YY.ZZ.Q*, for instance 1.2.3.alpha4: [1, 2, 3, "alpha", 4]

Maven:  major.minor(.bugfix)?(-(alpha|beta|rc)-X)? which will be:
[ major, minor, bugfix?, [ alpha|beta|rc, [X] ]

I'll probably miss some usecases or got some things wrong, but if we do not support 
some sort of 
tag in the POM, we want to be able to accommodate versioning in a most generic 
way, and I think this comes close.

I've created an implementation[1] and a unit test[2].

I've had to comment out one assert: 2.0.1-xyz < 2.0.1. I think generally this 
is not the case. For example,
the wiki guide to patching plugins states that you could patch a plugin and 
change it's version to 2.0-INTERNAL.
In this case, 2.0 would be newer than 2.0-INTERNAL, which renders the wiki 
description invalid. In my sample
implementation, 2.0.1-xyz is newer than 2.0.1.
Though should this be required, the code is easily modified to reflect this.

So, WDYT?

Re: maven2 and NTLM


Brett Porter wrote:

google says...

http.auth.ntlm.domain

http://java.sun.com/j2se/1.5.0/docs/guide/net/properties.html

Could be worth exposing this via the settings into the lightweight 
wagon, and passing the equivalent to the httpclient wagon via it's 
authenticators.


- Brett


FWIW, Ant1.7.0 final has rolled back support for the java1.5 automatic 
proxy stuff. It didnt work and it broke odd things like Oracle's JDBC 
driver.


We really need a commons-proxy-setup project that
 -correctly determines proxy settings on the main systems (windows, 
mac, unix, gnome, kde)

 -maybe: interprets autoconf files if bsf+rhino or java6 is present
 -shares user overrides in a single consistent place (file or, 
java.util.prefs)

 -lets classes listen for proxy change events
 -is smart enough to bypass the proxy if its hostname doesnt resolve, 
or the port isnt open


Anyone interested in working on this?

-steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven and Gentoo


Alistair Bush wrote:
After browsing thru the conversation relating to Maven and Fedora I thought I 
would put in the Gentoo Linux's perspective.




(snip)

Sadly we only have support for ant presently.  


I wouldnt say sadly :)


To accomplish this we had to 
implement some funky build.xml rewriting to ensure that -source & -target 
were being passed to javac.


Ant1.7 lets you do this just by specifying some system properties which 
all java/javadoc declarations which dont specify a required version will 
pick up.


ant.build.javac.source  	Source-level version number  	Default source 
value for /
ant.build.javac.target 	Class-compatibility version number 	Default 
target value for /


This avoids having to create a new compiler implemenation class that 
wraps your inner compiler, and setting that compiler's classname with 
the build.compiler property.


-Steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

From the spec:

A version string is a series of positive numbers separated by periods.
The numbers are compared component by component from left to right. If
any number is greater than the corresponding number of the supplied
string the method returns true. If the number is less than it returns
false. If the corresponding numbers are equal the next number is
examined.

That shouldn't be a problem...

On 12/19/06, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:

I believe that Maven version number support should at least make it
possible to apply the specification / implementation version
numbering scheme that is part of the Java standard ().

On 19 Dec 2006, at 9:33, [EMAIL PROTECTED] wrote:

> Jason Dillon <[EMAIL PROTECTED]> schrieb am 19.12.2006 01:26:54:
>
>> I've seen projects switch back and forth... depends on who is in
>> power at the time and what style they like.  So it would be best if
>> mvn would be able comprehend:
>
> Since versions are such an important information in Maven, Maven
> should
> refuse version numbers which aren't easily comparable.
>
> How about forcing the contents of the version element in the POM to
> 1-3
> digits, separated by dots? That would "help" people who can't decide.
>
> After that, you can add something with "-" which maven will just
> string-compare (so alpha10 comes between alpha1 and alpha2).
>
> Regards,
>
> --
> Aaron Digulla
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

I believe that Maven version number support should at least make it  
possible to apply the specification / implementation version  
numbering scheme that is part of the Java standard (java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/ 
versioning2.html#wp89936>).





On 19 Dec 2006, at 9:33, [EMAIL PROTECTED] wrote:


Jason Dillon <[EMAIL PROTECTED]> schrieb am 19.12.2006 01:26:54:


I've seen projects switch back and forth... depends on who is in
power at the time and what style they like.  So it would be best if
mvn would be able comprehend:


Since versions are such an important information in Maven, Maven  
should

refuse version numbers which aren't easily comparable.

How about forcing the contents of the version element in the POM to  
1-3

digits, separated by dots? That would "help" people who can't decide.

After that, you can add something with "-" which maven will just
string-compare (so alpha10 comes between alpha1 and alpha2).

Regards,

--
Aaron Digulla

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

2006-12-19 Thread Stephane Nicoll


On 12/19/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

I've seen projects switch back and forth... depends on who is in
power at the time and what style they like.  So it would be best if
mvn would be able comprehend:

 1.0alpha2 < 1.0-alpha-3



I disagree. I don't think it will help maven users if we start
implementing algorithms like this. Why don't we describe the standard
way of specifying a version number? The examples kenney had provided
in his previous email sound a good start to me.

If one want to use another version numbering (such as your example
above) too bad. Now at least he would be aware that version comparison
might not work. We can't predit all scenario anyway.

WDYT?

Stéphane



--jason


On Dec 18, 2006, at 3:41 PM, Barrie Treloar wrote:

>> - don't use the current 4-digit limitation, but instead list with
>> a random amount of entries
>> - entries are separated by dots or dashes
>> - entries are separated by transition to/from alpha to numeric
>> - sub-lists are indicated by '-'
>> - entries can be either: string, integer, or sublist
>> - versions are compared entry by entry, where we have 3 options;
>>   * integer <=> integer: normal numerical compare
>>   * integer <=> string: integers are newer
>>   * integer <=> list: integers are newer
>>   * string <=> string: if it's a qualifier, qualifier compare,
>> else lexical compare,
>>  taking into account if either is a qualifier.
>>   * string <=> list: list is newer
>>   * list <=> list: recursion, same as a 'top-level' version
>> compare. Where one list is shorter,
>>   '0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 => 2.0-
>> alpha <=> 2.0.0 = -1 (2.0 = newer))
>
> The edge cases around the examples like 1.0alpha2 and 1.0-alpha-2 are
> bit beyond how I would use things so I can't really comment.  However
> I would expect a project to be self consistent so it doesn't really
> matter if 1.0alpha2 is newer than 1.0-alpha-2, just as long as
> 1.0alpha2 < 1.0alpha3 and 1.0-alpha-2 < 1.0-alpha-3 which the rules
> cater for.
>
> Everything else seems reasonable and the examples appear to make sense
> and parse the way I would expect things to work.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack

2006-12-19 Thread Bhupendra Bhardwaj


Hi all,

So, what is the way forward?
Is that till we have the feature Graham is working on (downloading eclipse
jars from links like
http://download.eclipse.org/eclipse/downloads/drops/R-3.2.1-200609210945/)
we have to download those jars seperately from those urls and may be put in
the project's lib dir and then bundle our RCP apps for distribution?

For things like eclipse plugin jars, who is supposed to be taking care of
having updates jars in the maven repo?
- is it the specific project team (like eclipse project people), who should
take care of it  or
- it the maven team or
- projects which need to use them should follow some process to get it in
the maven. I don't this is the option as it will make things messy and
inconsistent versions in the repo.


Regards,
Bhupendra



On 12/19/06, Tom Huybrechts <[EMAIL PROTECTED]> wrote:


On 12/19/06, Graham Leggett <[EMAIL PROTECTED]> wrote:
> On Tue, December 19, 2006 10:24 am, [EMAIL PROTECTED] wrote:
>
> > =8*O I beg your pardon? I looked in JIRA but couldn't find a report
about
> > this. Is there? If not, I'd open one. ;-)
> >
> > The idea that you'll never have to fix a broken POM/JAR/whatever is
just
> > ridiculous. :-) As I understand it, the repo admins are just very
> > reluctant to modify already published artefacts.
>
> That's what I meant, yes.
>
> As it turns out, someone has already published the full eclipse tree to
> repo1, so all this is moot :)
>

No it's not - the Eclipse artifacts are published to a separate
repository and are not yet integrated into the main repository.

> Regards,
> Graham
> --
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack


On 12/19/06, Graham Leggett <[EMAIL PROTECTED]> wrote:

On Tue, December 19, 2006 10:24 am, [EMAIL PROTECTED] wrote:

> =8*O I beg your pardon? I looked in JIRA but couldn't find a report about
> this. Is there? If not, I'd open one. ;-)
>
> The idea that you'll never have to fix a broken POM/JAR/whatever is just
> ridiculous. :-) As I understand it, the repo admins are just very
> reluctant to modify already published artefacts.

That's what I meant, yes.

As it turns out, someone has already published the full eclipse tree to
repo1, so all this is moot :)



No it's not - the Eclipse artifacts are published to a separate
repository and are not yet integrated into the main repository.


Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack

2006-12-19 Thread Graham Leggett

On Tue, December 19, 2006 10:24 am, [EMAIL PROTECTED] wrote:

> =8*O I beg your pardon? I looked in JIRA but couldn't find a report about
> this. Is there? If not, I'd open one. ;-)
>
> The idea that you'll never have to fix a broken POM/JAR/whatever is just
> ridiculous. :-) As I understand it, the repo admins are just very
> reluctant to modify already published artefacts.

That's what I meant, yes.

As it turns out, someone has already published the full eclipse tree to
repo1, so all this is moot :)

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack

On 12/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

"Graham Leggett" <[EMAIL PROTECTED]> schrieb am 18.12.2006 17:53:54:

> The problem I saw posted recently about this was that once published,
the
> repository is cast in stone, including errors.

=8*O I beg your pardon? I looked in JIRA but couldn't find a report about
this. Is there? If not, I'd open one. ;-)

The idea that you'll never have to fix a broken POM/JAR/whatever is just
ridiculous. :-) As I understand it, the repo admins are just very
reluctant to modify already published artefacts.

The repository IS cast in stone. Deployed POMs are not updated since
clients do not expect them to change and will not check for updates
(nor should they). This is an integral part of build reproducibility.

The only way to fix a broken artifact is by uploading a new version.

Tom

Regards,

--
Aaron Digulla

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: versioning

Jason Dillon <[EMAIL PROTECTED]> schrieb am 19.12.2006 01:26:54:

> I've seen projects switch back and forth... depends on who is in 
> power at the time and what style they like.  So it would be best if 
> mvn would be able comprehend:

Since versions are such an important information in Maven, Maven should 
refuse version numbers which aren't easily comparable.

How about forcing the contents of the version element in the POM to 1-3 
digits, separated by dots? That would "help" people who can't decide.

After that, you can add something with "-" which maven will just 
string-compare (so alpha10 comes between alpha1 and alpha2).

Regards,

-- 
Aaron Digulla

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack