[VOTE] Release Maven 2.0.5

[Fabrice Bellingard-3]

Hi Jason,

I've just tested Maven 2.0.5 on complex projects, and I've had 2 problems
who broke the builds.

The first is about dependency resolution. In the dependency tree of one of
my projects, I have 2 versions of the same lib at the same depth: version
3.1 and 2.1. With Maven 2.0.4, version 3.1 is selected for compiling and
testing, which is what I want. With Maven 2.0.5, version 2.1 is selected,
which breaks my unit tests because the code requires version 3.1 to run. I'm
not sure if this is a bug or not - maybe this resolution principle was to be
the default behaviour, but the fact is that there's a difference between
2.0.4 and 2.0.5. I've looked (quickly) into JIRA roadmap, but haven't found
any fixed issue related to that.

I had the second problem when executing the Checkstyle plugin (version 2.1).
So I dug a bit to see if this could be related to maven core or not, and
here is what I found.
I isolated the code that breaks the build in the checkstyle plugin: it
happens when the plugin tries to load my Checkstyle configuration file,
which is actually located in a JAR that is specified in the build
extensions. The code lies in the Locator#resolveLocation() method:

                *// Attempt a Resource.
*                 URL url =
*this*.getClass().getClassLoader().getResource( location );

This code returns null for the "url" variable, which in turns breaks the
plugin because it doesn't find any configuration file.
I haven't had the time to dig more into it, but I found the following issue
that might be related to this problem: "MNG-2228 : Classloader problem
loading jars from build extensions"<http://jira.codehaus.org/browse/MNG-2228>.
Brett and Carlos worked on it and fixed it, so maybe they could tell more
about it.


Apart from that, everything else works perfectly. Maybe some of us can tell
a bit more about those problems?

Cheers,
Fabrice.

On 1/12/07, Jason van Zyl <jason@...> wrote:

>
> Hi,
>
> The entire release is staged here:
>
> http://people.apache.org/~jvanzyl/maven-2.0.5/
>
> The assemblies that people are interested in are staged here:
>
> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-
> core/2.0.5/
>
> Here is the JIRA roadmap:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?
> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
> order=DESC
>
> That's about it. Play around with it, if there are things wrong and
> I'll fix stuff. We haven't released in so long there very well may be
> some problems.
>
> We should probably let it sit until Tuesday as most folks won't try
> it out over the weekend.
>
> +1
>
> Thanks,
>
> Jason.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Brian E Fox]

 
>I had the second problem when executing the Checkstyle plugin (version
2.1).
>So I dug a bit to see if this could be related to maven core or not,
and here is what I found.
>I isolated the code that breaks the build in the checkstyle plugin: it
happens when the plugin tries to load my Checkstyle configuration file,
which is actually >>located in a JAR that is specified in the build
extensions. The code lies in the Locator#resolveLocation() method:

That's curious because in a previous snapshot, I had the exact same
problem: http://jira.codehaus.org/browse/mng-2749 but it was fixed and I
verified my build with the previous snapshot as well as the release
artifact below.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kenney Westerhof-3]

Dennis Lundberg wrote:

> Jason,
>
> Would you consider upgrading the dependency on modello-maven-plugin in
> maven-model to alpha-13 (or alpha-14 if that is released) for this
> release? It would bring in a couple of nice features for the generated
> documentation. If not, I'll add it to JIRA for 2.0.6.
>
> Also I found a couple of typos in maven.mdo that I fixed in trunk and
> the 2.0.x branch. Is it OK if I merge these into the 2.0.5 tag as well?
>

Hi,

tags cannot change, ever. In the best case a new release is cut, old tag
deleted, and a new one created. I think it depends on wheter the vote passes
if this could get into 2.0.5. The next release is planned pretty soon (1 to 2 weeks),
so I think it's best to schedule those two issues for 2.0.6.

-- Kenney

> Jason van Zyl wrote:
>> Hi,
>>
>> The entire release is staged here:
>>
>> http://people.apache.org/~jvanzyl/maven-2.0.5/
>>
>> The assemblies that people are interested in are staged here:
>>
>> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/ 
>>
>>
>> Here is the JIRA roadmap:
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC 
>>
>>
>> That's about it. Play around with it, if there are things wrong and
>> I'll fix stuff. We haven't released in so long there very well may be
>> some problems.
>>
>> We should probably let it sit until Tuesday as most folks won't try it
>> out over the weekend.
>>
>> +1
>>
>> Thanks,
>>
>> Jason.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Emmanuel Venisse]

+1. It works fine for me.

Emmanuel

Jason van Zyl a écrit :

> Hi,
>
> The entire release is staged here:
>
> http://people.apache.org/~jvanzyl/maven-2.0.5/
>
> The assemblies that people are interested in are staged here:
>
> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/ 
>
>
> Here is the JIRA roadmap:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC 
>
>
> That's about it. Play around with it, if there are things wrong and I'll
> fix stuff. We haven't released in so long there very well may be some
> problems.
>
> We should probably let it sit until Tuesday as most folks won't try it
> out over the weekend.
>
> +1
>
> Thanks,
>
> Jason.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

On 14 Jan 07, at 4:37 PM 14 Jan 07, Dennis Lundberg wrote:

> Jason,
>
> Would you consider upgrading the dependency on modello-maven-plugin  
> in maven-model to alpha-13 (or alpha-14 if that is released) for  
> this release? It would bring in a couple of nice features for the  
> generated documentation. If not, I'll add it to JIRA for 2.0.6.
>
> Also I found a couple of typos in maven.mdo that I fixed in trunk  
> and the 2.0.x branch. Is it OK if I merge these into the 2.0.5 tag  
> as well?
>

Add them to 2.0.6, I would prefer not re-rolling it unless there is a  
show stopper. We'll do a 2.0.6 pretty soon after this.

jason.

> Jason van Zyl wrote:
>> Hi,
>> The entire release is staged here:
>> http://people.apache.org/~jvanzyl/maven-2.0.5/
>> The assemblies that people are interested in are staged here:
>> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/ 
>> maven-core/2.0.5/ Here is the JIRA roadmap:
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?
>> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
>> order=DESC That's about it. Play around with it, if there are  
>> things wrong and I'll fix stuff. We haven't released in so long  
>> there very well may be some problems.
>> We should probably let it sit until Tuesday as most folks won't  
>> try it out over the weekend.
>> +1
>> Thanks,
>> Jason.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Max Bowsher-4]

Kenney Westerhof wrote:
> tags cannot change, ever.

The maven-2.0.5 tag already has been changed a bit since creation.

The perpetual tension between burning publicly visible version numbers,
and retaining unique identity of versions strikes again. Unfortunately,
it's a problem without any obvious solution :-/ .

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

On 15 Jan 07, at 6:29 AM 15 Jan 07, Fabrice Bellingard wrote:

> Hi Jason,
>
> I've just tested Maven 2.0.5 on complex projects, and I've had 2  
> problems
> who broke the builds.
>
> The first is about dependency resolution. In the dependency tree of  
> one of
> my projects, I have 2 versions of the same lib at the same depth:  
> version
> 3.1 and 2.1. With Maven 2.0.4, version 3.1 is selected for  
> compiling and
> testing, which is what I want. With Maven 2.0.5, version 2.1 is  
> selected,
> which breaks my unit tests because the code requires version 3.1 to  
> run. I'm
> not sure if this is a bug or not - maybe this resolution principle  
> was to be
> the default behaviour, but the fact is that there's a difference  
> between
> 2.0.4 and 2.0.5. I've looked (quickly) into JIRA roadmap, but  
> haven't found
> any fixed issue related to that.

I myself have intentionally stayed away from artifact resolution on  
the branch so do you have a test project I can use. I need to be able  
to reproduce your problem and turn it into some form of test. So I  
can see what's going on and so it doesn't regress again, if it is  
indeed a regression.

>
> I had the second problem when executing the Checkstyle plugin  
> (version 2.1).
> So I dug a bit to see if this could be related to maven core or  
> not, and
> here is what I found.
> I isolated the code that breaks the build in the checkstyle plugin: it
> happens when the plugin tries to load my Checkstyle configuration  
> file,
> which is actually located in a JAR that is specified in the build
> extensions. The code lies in the Locator#resolveLocation() method:
>
>                *// Attempt a Resource.
> *                 URL url =
> *this*.getClass().getClassLoader().getResource( location );
>
> This code returns null for the "url" variable, which in turns  
> breaks the
> plugin because it doesn't find any configuration file.
> I haven't had the time to dig more into it, but I found the  
> following issue
> that might be related to this problem: "MNG-2228 : Classloader problem
> loading jars from build extensions"<http://jira.codehaus.org/browse/ 
> MNG-2228>.
> Brett and Carlos worked on it and fixed it, so maybe they could  
> tell more
> about it.
>
>

That doesn't sound good though 2.0.4 and 2.0.5 both use the same  
versions of classworlds and plexus so you're sure you have the same  
version of the checkstyle plugin there?

> Apart from that, everything else works perfectly. Maybe some of us  
> can tell
> a bit more about those problems?
>
> Cheers,
> Fabrice.
>
> On 1/12/07, Jason van Zyl <jason@...> wrote:
>>
>> Hi,
>>
>> The entire release is staged here:
>>
>> http://people.apache.org/~jvanzyl/maven-2.0.5/
>>
>> The assemblies that people are interested in are staged here:
>>
>> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-
>> core/2.0.5/
>>
>> Here is the JIRA roadmap:
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?
>> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
>> order=DESC
>>
>> That's about it. Play around with it, if there are things wrong and
>> I'll fix stuff. We haven't released in so long there very well may be
>> some problems.
>>
>> We should probably let it sit until Tuesday as most folks won't try
>> it out over the weekend.
>>
>> +1
>>
>> Thanks,
>>
>> Jason.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

On 15 Jan 07, at 8:56 AM 15 Jan 07, Max Bowsher wrote:

> Kenney Westerhof wrote:
>> tags cannot change, ever.
>
> The maven-2.0.5 tag already has been changed a bit since creation.
>

The only way we'll move toward having releases be perfect is to do  
lots of them.

> The perpetual tension between burning publicly visible version  
> numbers,
> and retaining unique identity of versions strikes again.  
> Unfortunately,
> it's a problem without any obvious solution :-/ .
>

It's not a publicly visible, it's in a staging repository. A small  
addition of a build number (revision number) to the distribution will  
soon clearly separate versions.

We will get there very soon.

Jason.

> Max.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Vincent Siveton]

Hi,

+1 works fine for me

But I confirmed DOXIA-90 for 2.0.5. Is it a known issue on core?

Cheers,

Vincent

2007/1/12, Jason van Zyl <jason@...>:

> Hi,
>
> The entire release is staged here:
>
> http://people.apache.org/~jvanzyl/maven-2.0.5/
>
> The assemblies that people are interested in are staged here:
>
> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-
> core/2.0.5/
>
> Here is the JIRA roadmap:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?
> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
> order=DESC
>
> That's about it. Play around with it, if there are things wrong and
> I'll fix stuff. We haven't released in so long there very well may be
> some problems.
>
> We should probably let it sit until Tuesday as most folks won't try
> it out over the weekend.
>
> +1
>
> Thanks,
>
> Jason.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Wendy Smoak-3]

On 1/15/07, Fabrice Bellingard <bellingard@...> wrote:

> The first is about dependency resolution. In the dependency tree of one of
> my projects, I have 2 versions of the same lib at the same depth: version
> 3.1 and 2.1.  With Maven 2.0.4, version 3.1 is selected for compiling and
> testing, which is what I want. With Maven 2.0.5, version 2.1 is selected,
> which breaks my unit tests because the code requires version 3.1 to run. I'm
> not sure if this is a bug or not - maybe this resolution principle was to be
> the default behaviour, but the fact is that there's a difference between
> 2.0.4 and 2.0.5. I've looked (quickly) into JIRA roadmap, but haven't found
> any fixed issue related to that.

IIRC, Maven 2.0.4's behavior with two versions of the same dependency
at the same depth was undefined.  Now, it's supposed to be
predictable.

Can someone confirm?  (And explain how to predict what 2.0.5 will do
in this situation?)

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mperham]

+1

Tested against our build and appears to work identically to 2.0.4.

On 1/12/07, Jason van Zyl <jason@...> wrote:

> Hi,
>
> The entire release is staged here:
>
> http://people.apache.org/~jvanzyl/maven-2.0.5/
>
> The assemblies that people are interested in are staged here:
>
> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-
> core/2.0.5/
>
> Here is the JIRA roadmap:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?
> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
> order=DESC
>
> That's about it. Play around with it, if there are things wrong and
> I'll fix stuff. We haven't released in so long there very well may be
> some problems.
>
> We should probably let it sit until Tuesday as most folks won't try
> it out over the weekend.
>
> +1
>
> Thanks,
>
> Jason.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Trygve Laugstøl apache]

Trygve Laugstøl wrote:

> Jason van Zyl wrote:
>> Hi,
>>
>> The entire release is staged here:
>>
>> http://people.apache.org/~jvanzyl/maven-2.0.5/
>>
>> The assemblies that people are interested in are staged here:
>>
>> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/ 
>>
>>
>> Here is the JIRA roadmap:
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC 
>>
>>
>> That's about it. Play around with it, if there are things wrong and
>> I'll fix stuff. We haven't released in so long there very well may be
>> some problems.
>>
>> We should probably let it sit until Tuesday as most folks won't try it
>> out over the weekend.
>
> I'm waiting until I've tried it out on my projects.

Testes and a serious bug was found. It seems that Maven tries to check
for SNAPSHOT plugin updates on every run instead of the expected daily
interval.

I've verified that it do check on every update by using truss (use
strace on linux) on Solaris:

$ truss -t connect mvn -Dmaven.test.skip=true install
[INFO] Scanning for projects...
[INFO]
----------------------------------------------------------------------------
[INFO] Building Unnamed - no.java.monitor:monitor-core:jar:1.0-SNAPSHOT
[INFO]    task-segment: [install]
[INFO]
----------------------------------------------------------------------------
[INFO] artifact org.apache.maven.plugins:maven-resources-plugin:
checking for updates from codehaus-snapshots
/1:     connect(8, 0xFFBFBAF4, 16, SOV_DEFAULT)         = 0
/1:     connect(7, 0xFFBFBD98, 16, SOV_DEFAULT)         = 0
[INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking
for updates from codehaus-snapshots
/1:     connect(7, 0xFFBFBD80, 16, SOV_DEFAULT)         = 0
[INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
for updates from codehaus-snapshots
/1:     connect(9, 0xFFBFBD98, 16, SOV_DEFAULT)         = 0
[INFO] artifact org.apache.maven.plugins:maven-jar-plugin: checking for
updates from codehaus-snapshots
/1:     connect(7, 0xFFBFBD80, 16, SOV_DEFAULT)         = 0
[INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking
for updates from codehaus-snapshots
[INFO] [plexus:descriptor {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING]
         Artifact junit:junit:jar:3.8.1:test retains local scope 'test'
overriding broader scope 'compile'
         given by a dependency. If this is not intended, modify or
remove the local scope.

So I'm -1 on this revision until this issue is resolved :'(

The issue was confirmed by other devs on IRC aswell.

--
Trygve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Kenney Westerhof-3]

Hi,

I've fixed this bug a while back on trunk but haven't merged it to
the branch.

The cause is that for non-existing metadata files at the checked repositories,
no local metadata file is written. The 'daily' policy uses the timestamp for
that file to see if it should update again, which it always does since
the timestamp is 0 for non-existent files.

I've fixed this by creating a metadata file even if there's no metadata, but
I wanted to test more since it's different behaviour. The file is written without
a <version> tag (version is null), and there was an explicit unit test for that.
It all seems to work fine though.

I can merge this to trunk.

-- Kenney

Trygve Laugstøl wrote:

> Trygve Laugstøl wrote:
>> Jason van Zyl wrote:
>>> Hi,
>>>
>>> The entire release is staged here:
>>>
>>> http://people.apache.org/~jvanzyl/maven-2.0.5/
>>>
>>> The assemblies that people are interested in are staged here:
>>>
>>> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/ 
>>>
>>>
>>> Here is the JIRA roadmap:
>>>
>>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC 
>>>
>>>
>>> That's about it. Play around with it, if there are things wrong and
>>> I'll fix stuff. We haven't released in so long there very well may be
>>> some problems.
>>>
>>> We should probably let it sit until Tuesday as most folks won't try
>>> it out over the weekend.
>>
>> I'm waiting until I've tried it out on my projects.
>
> Testes and a serious bug was found. It seems that Maven tries to check
> for SNAPSHOT plugin updates on every run instead of the expected daily
> interval.
>
> I've verified that it do check on every update by using truss (use
> strace on linux) on Solaris:
>
> $ truss -t connect mvn -Dmaven.test.skip=true install
> [INFO] Scanning for projects...
> [INFO]
> ----------------------------------------------------------------------------
>
> [INFO] Building Unnamed - no.java.monitor:monitor-core:jar:1.0-SNAPSHOT
> [INFO]    task-segment: [install]
> [INFO]
> ----------------------------------------------------------------------------
>
> [INFO] artifact org.apache.maven.plugins:maven-resources-plugin:
> checking for updates from codehaus-snapshots
> /1:     connect(8, 0xFFBFBAF4, 16, SOV_DEFAULT)         = 0
> /1:     connect(7, 0xFFBFBD98, 16, SOV_DEFAULT)         = 0
> [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking
> for updates from codehaus-snapshots
> /1:     connect(7, 0xFFBFBD80, 16, SOV_DEFAULT)         = 0
> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
> for updates from codehaus-snapshots
> /1:     connect(9, 0xFFBFBD98, 16, SOV_DEFAULT)         = 0
> [INFO] artifact org.apache.maven.plugins:maven-jar-plugin: checking for
> updates from codehaus-snapshots
> /1:     connect(7, 0xFFBFBD80, 16, SOV_DEFAULT)         = 0
> [INFO] artifact org.apache.maven.plugins:maven-install-plugin: checking
> for updates from codehaus-snapshots
> [INFO] [plexus:descriptor {execution: default}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING]
>         Artifact junit:junit:jar:3.8.1:test retains local scope 'test'
> overriding broader scope 'compile'
>         given by a dependency. If this is not intended, modify or remove
> the local scope.
>
> So I'm -1 on this revision until this issue is resolved :'(
>
> The issue was confirmed by other devs on IRC aswell.
>
> --
> Trygve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

On 15 Jan 07, at 11:19 AM 15 Jan 07, Kenney Westerhof wrote:

> Hi,
>
> I've fixed this bug a while back on trunk but haven't merged it to
> the branch.
>
> The cause is that for non-existing metadata files at the checked  
> repositories,
> no local metadata file is written. The 'daily' policy uses the  
> timestamp for
> that file to see if it should update again, which it always does since
> the timestamp is 0 for non-existent files.
>
> I've fixed this by creating a metadata file even if there's no  
> metadata, but
> I wanted to test more since it's different behaviour. The file is  
> written without
> a <version> tag (version is null), and there was an explicit unit  
> test for that.
> It all seems to work fine though.
>
> I can merge this to trunk.
>

That would be great, then we can try Trygve's little test. Eventually  
we'll need a TimeSource that uses the system clock for runtime and a  
mock source for testing so we can make sure this doesn't happen again.

Jason.

> -- Kenney
>
> Trygve Laugstøl wrote:
>> Trygve Laugstøl wrote:
>>> Jason van Zyl wrote:
>>>> Hi,
>>>>
>>>> The entire release is staged here:
>>>>
>>>> http://people.apache.org/~jvanzyl/maven-2.0.5/
>>>>
>>>> The assemblies that people are interested in are staged here:
>>>>
>>>> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/ 
>>>> maven-core/2.0.5/
>>>>
>>>> Here is the JIRA roadmap:
>>>>
>>>> http://jira.codehaus.org/secure/IssueNavigator.jspa?
>>>> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
>>>> order=DESC
>>>>
>>>> That's about it. Play around with it, if there are things wrong  
>>>> and I'll fix stuff. We haven't released in so long there very  
>>>> well may be some problems.
>>>>
>>>> We should probably let it sit until Tuesday as most folks won't  
>>>> try it out over the weekend.
>>>
>>> I'm waiting until I've tried it out on my projects.
>> Testes and a serious bug was found. It seems that Maven tries to  
>> check for SNAPSHOT plugin updates on every run instead of the  
>> expected daily interval.
>> I've verified that it do check on every update by using truss (use  
>> strace on linux) on Solaris:
>> $ truss -t connect mvn -Dmaven.test.skip=true install
>> [INFO] Scanning for projects...
>> [INFO]  
>> ---------------------------------------------------------------------
>> ------- [INFO] Building Unnamed - no.java.monitor:monitor-core:jar:
>> 1.0-SNAPSHOT
>> [INFO]    task-segment: [install]
>> [INFO]  
>> ---------------------------------------------------------------------
>> ------- [INFO] artifact org.apache.maven.plugins:maven-resources-
>> plugin: checking for updates from codehaus-snapshots
>> /1:     connect(8, 0xFFBFBAF4, 16, SOV_DEFAULT)         = 0
>> /1:     connect(7, 0xFFBFBD98, 16, SOV_DEFAULT)         = 0
>> [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin:  
>> checking for updates from codehaus-snapshots
>> /1:     connect(7, 0xFFBFBD80, 16, SOV_DEFAULT)         = 0
>> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin:  
>> checking for updates from codehaus-snapshots
>> /1:     connect(9, 0xFFBFBD98, 16, SOV_DEFAULT)         = 0
>> [INFO] artifact org.apache.maven.plugins:maven-jar-plugin:  
>> checking for updates from codehaus-snapshots
>> /1:     connect(7, 0xFFBFBD80, 16, SOV_DEFAULT)         = 0
>> [INFO] artifact org.apache.maven.plugins:maven-install-plugin:  
>> checking for updates from codehaus-snapshots
>> [INFO] [plexus:descriptor {execution: default}]
>> [INFO] [resources:resources]
>> [INFO] Using default encoding to copy filtered resources.
>> [WARNING]
>>         Artifact junit:junit:jar:3.8.1:test retains local scope  
>> 'test' overriding broader scope 'compile'
>>         given by a dependency. If this is not intended, modify or  
>> remove the local scope.
>> So I'm -1 on this revision until this issue is resolved :'(
>> The issue was confirmed by other devs on IRC aswell.
>> --
>> Trygve
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

I revert the branch, apply the fix, redo the release and call for  
another vote.

Fabrice can you please check again on your builds and make sure it's  
not something with the checkstyle plugin.

Jason.


In the
On 15 Jan 07, at 11:40 AM 15 Jan 07, Jason van Zyl wrote:

>
> On 15 Jan 07, at 11:19 AM 15 Jan 07, Kenney Westerhof wrote:
>
>> Hi,
>>
>> I've fixed this bug a while back on trunk but haven't merged it to
>> the branch.
>>
>> The cause is that for non-existing metadata files at the checked  
>> repositories,
>> no local metadata file is written. The 'daily' policy uses the  
>> timestamp for
>> that file to see if it should update again, which it always does  
>> since
>> the timestamp is 0 for non-existent files.
>>
>> I've fixed this by creating a metadata file even if there's no  
>> metadata, but
>> I wanted to test more since it's different behaviour. The file is  
>> written without
>> a <version> tag (version is null), and there was an explicit unit  
>> test for that.
>> It all seems to work fine though.
>>
>> I can merge this to trunk.
>>
>
> That would be great, then we can try Trygve's little test.  
> Eventually we'll need a TimeSource that uses the system clock for  
> runtime and a mock source for testing so we can make sure this  
> doesn't happen again.
>
> Jason.
>
>> -- Kenney
>>
>> Trygve Laugstøl wrote:
>>> Trygve Laugstøl wrote:
>>>> Jason van Zyl wrote:
>>>>> Hi,
>>>>>
>>>>> The entire release is staged here:
>>>>>
>>>>> http://people.apache.org/~jvanzyl/maven-2.0.5/
>>>>>
>>>>> The assemblies that people are interested in are staged here:
>>>>>
>>>>> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/ 
>>>>> maven-core/2.0.5/
>>>>>
>>>>> Here is the JIRA roadmap:
>>>>>
>>>>> http://jira.codehaus.org/secure/IssueNavigator.jspa?
>>>>> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
>>>>> order=DESC
>>>>>
>>>>> That's about it. Play around with it, if there are things wrong  
>>>>> and I'll fix stuff. We haven't released in so long there very  
>>>>> well may be some problems.
>>>>>
>>>>> We should probably let it sit until Tuesday as most folks won't  
>>>>> try it out over the weekend.
>>>>
>>>> I'm waiting until I've tried it out on my projects.
>>> Testes and a serious bug was found. It seems that Maven tries to  
>>> check for SNAPSHOT plugin updates on every run instead of the  
>>> expected daily interval.
>>> I've verified that it do check on every update by using truss  
>>> (use strace on linux) on Solaris:
>>> $ truss -t connect mvn -Dmaven.test.skip=true install
>>> [INFO] Scanning for projects...
>>> [INFO]  
>>> --------------------------------------------------------------------
>>> -------- [INFO] Building Unnamed - no.java.monitor:monitor-
>>> core:jar:1.0-SNAPSHOT
>>> [INFO]    task-segment: [install]
>>> [INFO]  
>>> --------------------------------------------------------------------
>>> -------- [INFO] artifact org.apache.maven.plugins:maven-resources-
>>> plugin: checking for updates from codehaus-snapshots
>>> /1:     connect(8, 0xFFBFBAF4, 16, SOV_DEFAULT)         = 0
>>> /1:     connect(7, 0xFFBFBD98, 16, SOV_DEFAULT)         = 0
>>> [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin:  
>>> checking for updates from codehaus-snapshots
>>> /1:     connect(7, 0xFFBFBD80, 16, SOV_DEFAULT)         = 0
>>> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin:  
>>> checking for updates from codehaus-snapshots
>>> /1:     connect(9, 0xFFBFBD98, 16, SOV_DEFAULT)         = 0
>>> [INFO] artifact org.apache.maven.plugins:maven-jar-plugin:  
>>> checking for updates from codehaus-snapshots
>>> /1:     connect(7, 0xFFBFBD80, 16, SOV_DEFAULT)         = 0
>>> [INFO] artifact org.apache.maven.plugins:maven-install-plugin:  
>>> checking for updates from codehaus-snapshots
>>> [INFO] [plexus:descriptor {execution: default}]
>>> [INFO] [resources:resources]
>>> [INFO] Using default encoding to copy filtered resources.
>>> [WARNING]
>>>         Artifact junit:junit:jar:3.8.1:test retains local scope  
>>> 'test' overriding broader scope 'compile'
>>>         given by a dependency. If this is not intended, modify or  
>>> remove the local scope.
>>> So I'm -1 on this revision until this issue is resolved :'(
>>> The issue was confirmed by other devs on IRC aswell.
>>> --
>>> Trygve
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[baerrach]

On 1/16/07, Jason van Zyl <jason@...> wrote:

>
> On 15 Jan 07, at 8:56 AM 15 Jan 07, Max Bowsher wrote:
>
> > Kenney Westerhof wrote:
> >> tags cannot change, ever.
> >
> > The maven-2.0.5 tag already has been changed a bit since creation.
> >
>
> The only way we'll move toward having releases be perfect is to do
> lots of them.

I would like to discuss this more, I've started another thread to do so.

See http://www.nabble.com/The-process-for-tags%2C-release-candidates%2C-final-releases--tf3017795s177.html

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey]

IIRC, the order in which dependencies are declared effectively becomes the
tie-breaker when two dependency versions are declared at the same depth...so
if:

A -> B, C
B -> D (v2)
C -> D (v3)

and A declares the following:

<dependencies>
  <dependency>
    [...]
    <artifactId>B</artifactId>
  </dependency>
  <dependency>
    [...]
    <artifactId>C</artifactId>
  </dependency>
</dependencies>

then Maven should choose D (v2) because B is declared first in the POM.

As I recall, that's how the change should function.

-john

On 1/15/07, Wendy Smoak <wsmoak@...> wrote:

>
> On 1/15/07, Fabrice Bellingard <bellingard@...> wrote:
>
> > The first is about dependency resolution. In the dependency tree of one
> of
> > my projects, I have 2 versions of the same lib at the same depth:
> version
> > 3.1 and 2.1.  With Maven 2.0.4, version 3.1 is selected for compiling
> and
> > testing, which is what I want. With Maven 2.0.5, version 2.1 is
> selected,
> > which breaks my unit tests because the code requires version 3.1 to run.
> I'm
> > not sure if this is a bug or not - maybe this resolution principle was
> to be
> > the default behaviour, but the fact is that there's a difference between
> > 2.0.4 and 2.0.5. I've looked (quickly) into JIRA roadmap, but haven't
> found
> > any fixed issue related to that.
>
> IIRC, Maven 2.0.4's behavior with two versions of the same dependency
> at the same depth was undefined.  Now, it's supposed to be
> predictable.
>
> Can someone confirm?  (And explain how to predict what 2.0.5 will do
> in this situation?)
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Fabrice Bellingard-3]

On 1/15/07, Jason van Zyl <jason@...> wrote:
>
>
> I myself have intentionally stayed away from artifact resolution on
> the branch so do you have a test project I can use. I need to be able
> to reproduce your problem and turn it into some form of test. So I
> can see what's going on and so it doesn't regress again, if it is
> indeed a regression.


I managed to reproduce the problem on a very simple project. I will send you
the ZIP in a few minutes. In the archive, you will find a project that has 3
dependecies:
  A -> D v2.1
  B -> D v3
  C (has no transitive dependency to D)
In the project, I call a class that exists in D v3 but not in D v2.1. If you
launch "mvn clean compile" with M2.0.4, the build is successful, but not
with M2.0.5.
And the most surprising: if you remove dependency C, then both builds
break...


That doesn't sound good though 2.0.4 and 2.0.5 both use the same
> versions of classworlds and plexus so you're sure you have the same
> version of the checkstyle plugin there?
>
>
Yes, I saw that both Maven 2.0.4 and 2.0.5 use the same version of
classworlds, that's why I don't really know what to think about it. But I
checked the log: the same version of the Checkstyle plugin is used in both
cases.
I will send you the log so that you can check.


Fabrice.

[Geoffrey De Smet]

+1: no problems here

--
With kind regards,
Geoffrey De Smet

Jason van Zyl schreef:

> Hi,
>
> The entire release is staged here:
>
> http://people.apache.org/~jvanzyl/maven-2.0.5/
>
> The assemblies that people are interested in are staged here:
>
> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/ 
>
>
> Here is the JIRA roadmap:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC 
>
>
> That's about it. Play around with it, if there are things wrong and I'll
> fix stuff. We haven't released in so long there very well may be some
> problems.
>
> We should probably let it sit until Tuesday as most folks won't try it
> out over the weekend.
>
> +1
>
> Thanks,
>
> Jason.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

We found a problem, so I'm rolling another release and will call a  
vote tomorrow.

Jason.

On 17 Jan 07, at 9:24 AM 17 Jan 07, Geoffrey De Smet wrote:

> +1: no problems here
>
> --
> With kind regards,
> Geoffrey De Smet
>
> Jason van Zyl schreef:
>> Hi,
>> The entire release is staged here:
>> http://people.apache.org/~jvanzyl/maven-2.0.5/
>> The assemblies that people are interested in are staged here:
>> http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/ 
>> maven-core/2.0.5/ Here is the JIRA roadmap:
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?
>> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
>> order=DESC That's about it. Play around with it, if there are  
>> things wrong and I'll fix stuff. We haven't released in so long  
>> there very well may be some problems.
>> We should probably let it sit until Tuesday as most folks won't  
>> try it out over the weekend.
>> +1
>> Thanks,
>> Jason.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...