date:20110527

Re: svn commit: r1127446 - in /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org: apache/maven/tck/ReproducesPlexusBug.java codehaus/plexus/util/IOUtilTest.java

2011-05-27 Thread Stephen Connolly

yeah m-shade-p was my plan anyway!

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 27 May 2011 22:14, "Mark Struberg"  wrote:
> hi simo!
>
> the maven-shade-plugin can do the same thing:
>
> http://maven.apache.org/plugins/maven-shade-plugin/
>
> LieGrue,
> strub
>
> --- On Fri, 5/27/11, Simone Tripodi  wrote:
>
>> From: Simone Tripodi 
>> Subject: Re: svn commit: r1127446 - in
/maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org:
apache/maven/tck/ReproducesPlexusBug.java
codehaus/plexus/util/IOUtilTest.java
>> To: "Maven Developers List" 
>> Date: Friday, May 27, 2011, 9:10 PM
>> Hi Stephen,
>> I accidentally raw your message and noticed you need to
>> shade
>> commons-* stuff; I don't know if it could help for your
>> purposes, but
>> I suggest you jarjar'ing[1] commons-* jars via the proposed
>> plugin
>> because you can even relocate classes inside packages and
>> really avoid
>> any kind of conflict.
>> HTH and sorry for interfering!
>> All the best, have a nice day,
>> Simo
>>
>> [1] http://sonatype.github.com/jarjar-maven-plugin/
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Wed, May 25, 2011 at 11:32 AM, Stephen Connolly
>> 
>> wrote:
>> > FYI
>> >
>> > here is my thinking on the release plan
>> >
>> > first release will shade all the commons-* stuff
>> inside so that we
>> > don't conflict with anyone using older versions of
>> commons-* and
>> > should be 100% compatibile (warts and all) with
>> plexus-utils
>> >
>> > for the second release we will add a MethodRule that
>> flips the
>> > @ReproducesPlexusBug test cases so that we can fix
>> them! (i.e. remove
>> > all the hack code like my infinite loop generator). At
>> this point all
>> > the methods will be @deprecated with the suggested
>> commons-*
>> > replacement method (because we will have removed the
>> bugs)
>> >
>> > for the third release we will remove the shading
>> >
>> > at that point we should have a nice pure shim layer
>> >
>> > On 25 May 2011 10:10,  
>> wrote:
>> >> Author: stephenc
>> >> Date: Wed May 25 09:10:46 2011
>> >> New Revision: 1127446
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=1127446&view=rev
>> >> Log:
>> >> Adding an annotation to mark test cases that are
>> verifying (warts and all) compatibility with Plexus Utils by
>> ensuring the same buggy behaviour
>> >>
>> >> Added:
>> >>
>>
 
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
>> >> Modified:
>> >>
>>
 
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
>> >>
>> >> Added:
>>
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
>> >> URL:
http://svn.apache.org/viewvc/maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java?rev=1127446&view=auto
>> >>
>>
==
>> >> ---
>>
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
>> (added)
>> >> +++
>>
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
>> Wed May 25 09:10:46 2011
>> >> @@ -0,0 +1,17 @@
>> >> +package org.apache.maven.tck;
>> >> +
>> >> +import java.lang.annotation.ElementType;
>> >> +import java.lang.annotation.Retention;
>> >> +import java.lang.annotation.RetentionPolicy;
>> >> +import java.lang.annotation.Target;
>> >> +
>> >> +/**
>> >> + * This annotation marks test cases where we are
>> testing buggy behaviour we will want to fix but need to
>> reproduce
>> >> + * to establish compatibility.
>> >> + */
>> >> +@Retention( RetentionPolicy.RUNTIME )
>> >> +@Target( ElementType.METHOD )
>> >> +public @interface ReproducesPlexusBug
>> >> +{
>> >> +String value();
>> >> +}
>> >>
>> >> Modified:
>>
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
>> >> URL:
http://svn.apache.org/viewvc/maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java?rev=1127446&r1=1127445&r2=1127446&view=diff
>> >>
>>
==
>> >> ---
>>
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
>> (original)
>> >> +++
>>
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
>> Wed May 25 09:10:46 2011
>> >> @@ -19,6 +19,7 @@ package
>> org.codehaus.plexus.util;
>> >>  * under the License.
>> >>

Re: svn commit: r1127446 - in /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org: apache/maven/tck/ReproducesPlexusBug.java codehaus/plexus/util/IOUtilTest.java

2011-05-27 Thread Mark Struberg

hi simo!

the maven-shade-plugin can do the same thing:

http://maven.apache.org/plugins/maven-shade-plugin/

LieGrue,
strub

--- On Fri, 5/27/11, Simone Tripodi  wrote:

> From: Simone Tripodi 
> Subject: Re: svn commit: r1127446 - in 
> /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org:
>  apache/maven/tck/ReproducesPlexusBug.java 
> codehaus/plexus/util/IOUtilTest.java
> To: "Maven Developers List" 
> Date: Friday, May 27, 2011, 9:10 PM
> Hi Stephen,
> I accidentally raw your message and noticed you need to
> shade
> commons-* stuff; I don't know if it could help for your
> purposes, but
> I suggest you jarjar'ing[1] commons-* jars via the proposed
> plugin
> because you can even relocate classes inside packages and
> really avoid
> any kind of conflict.
> HTH and sorry for interfering!
> All the best, have a nice day,
> Simo
> 
> [1] http://sonatype.github.com/jarjar-maven-plugin/
> 
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
> 
> 
> 
> On Wed, May 25, 2011 at 11:32 AM, Stephen Connolly
> 
> wrote:
> > FYI
> >
> > here is my thinking on the release plan
> >
> > first release will shade all the commons-* stuff
> inside so that we
> > don't conflict with anyone using older versions of
> commons-* and
> > should be 100% compatibile (warts and all) with
> plexus-utils
> >
> > for the second release we will add a MethodRule that
> flips the
> > @ReproducesPlexusBug test cases so that we can fix
> them! (i.e. remove
> > all the hack code like my infinite loop generator). At
> this point all
> > the methods will be @deprecated with the suggested
> commons-*
> > replacement method (because we will have removed the
> bugs)
> >
> > for the third release we will remove the shading
> >
> > at that point we should have a nice pure shim layer
> >
> > On 25 May 2011 10:10,  
> wrote:
> >> Author: stephenc
> >> Date: Wed May 25 09:10:46 2011
> >> New Revision: 1127446
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1127446&view=rev
> >> Log:
> >> Adding an annotation to mark test cases that are
> verifying (warts and all) compatibility with Plexus Utils by
> ensuring the same buggy behaviour
> >>
> >> Added:
> >>  
>  maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
> >> Modified:
> >>  
>  maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
> >>
> >> Added:
> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
> >> URL: 
> >> http://svn.apache.org/viewvc/maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java?rev=1127446&view=auto
> >>
> ==
> >> ---
> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
> (added)
> >> +++
> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
> Wed May 25 09:10:46 2011
> >> @@ -0,0 +1,17 @@
> >> +package org.apache.maven.tck;
> >> +
> >> +import java.lang.annotation.ElementType;
> >> +import java.lang.annotation.Retention;
> >> +import java.lang.annotation.RetentionPolicy;
> >> +import java.lang.annotation.Target;
> >> +
> >> +/**
> >> + * This annotation marks test cases where we are
> testing buggy behaviour we will want to fix but need to
> reproduce
> >> + * to establish compatibility.
> >> + */
> >> +@Retention( RetentionPolicy.RUNTIME )
> >> +@Target( ElementType.METHOD )
> >> +public @interface ReproducesPlexusBug
> >> +{
> >> +    String value();
> >> +}
> >>
> >> Modified:
> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
> >> URL: 
> >> http://svn.apache.org/viewvc/maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java?rev=1127446&r1=1127445&r2=1127446&view=diff
> >>
> ==
> >> ---
> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
> (original)
> >> +++
> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
> Wed May 25 09:10:46 2011
> >> @@ -19,6 +19,7 @@ package
> org.codehaus.plexus.util;
> >>  * under the License.
> >>  */
> >>
> >> +import org.apache.maven.tck.ReproducesPlexusBug;
> >>  import org.junit.Test;
> >>
> >>  import java.io.BufferedInputStream;
> >> @@ -393,6 +394,7 @@ public class IOUtilTest
> >>     }
> >>
> >>     @Test( timeout = 150 )
> >> +    @ReproducesPlexusBug( "Should not infinite
> loop" )
> >>     public void
> toStringEmptyByteArrayZeroBufSz()
> >

Re: svn commit: r1127446 - in /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org: apache/maven/tck/ReproducesPlexusBug.java codehaus/plexus/util/IOUtilTest.java

2011-05-27 Thread Simone Tripodi

Hi Stephen,
I accidentally raw your message and noticed you need to shade
commons-* stuff; I don't know if it could help for your purposes, but
I suggest you jarjar'ing[1] commons-* jars via the proposed plugin
because you can even relocate classes inside packages and really avoid
any kind of conflict.
HTH and sorry for interfering!
All the best, have a nice day,
Simo

[1] http://sonatype.github.com/jarjar-maven-plugin/

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Wed, May 25, 2011 at 11:32 AM, Stephen Connolly
 wrote:
> FYI
>
> here is my thinking on the release plan
>
> first release will shade all the commons-* stuff inside so that we
> don't conflict with anyone using older versions of commons-* and
> should be 100% compatibile (warts and all) with plexus-utils
>
> for the second release we will add a MethodRule that flips the
> @ReproducesPlexusBug test cases so that we can fix them! (i.e. remove
> all the hack code like my infinite loop generator). At this point all
> the methods will be @deprecated with the suggested commons-*
> replacement method (because we will have removed the bugs)
>
> for the third release we will remove the shading
>
> at that point we should have a nice pure shim layer
>
> On 25 May 2011 10:10,   wrote:
>> Author: stephenc
>> Date: Wed May 25 09:10:46 2011
>> New Revision: 1127446
>>
>> URL: http://svn.apache.org/viewvc?rev=1127446&view=rev
>> Log:
>> Adding an annotation to mark test cases that are verifying (warts and all) 
>> compatibility with Plexus Utils by ensuring the same buggy behaviour
>>
>> Added:
>>    
>> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
>> Modified:
>>    
>> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
>>
>> Added: 
>> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
>> URL: 
>> http://svn.apache.org/viewvc/maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java?rev=1127446&view=auto
>> ==
>> --- 
>> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
>>  (added)
>> +++ 
>> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/apache/maven/tck/ReproducesPlexusBug.java
>>  Wed May 25 09:10:46 2011
>> @@ -0,0 +1,17 @@
>> +package org.apache.maven.tck;
>> +
>> +import java.lang.annotation.ElementType;
>> +import java.lang.annotation.Retention;
>> +import java.lang.annotation.RetentionPolicy;
>> +import java.lang.annotation.Target;
>> +
>> +/**
>> + * This annotation marks test cases where we are testing buggy behaviour we 
>> will want to fix but need to reproduce
>> + * to establish compatibility.
>> + */
>> +@Retention( RetentionPolicy.RUNTIME )
>> +@Target( ElementType.METHOD )
>> +public @interface ReproducesPlexusBug
>> +{
>> +    String value();
>> +}
>>
>> Modified: 
>> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
>> URL: 
>> http://svn.apache.org/viewvc/maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java?rev=1127446&r1=1127445&r2=1127446&view=diff
>> ==
>> --- 
>> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
>>  (original)
>> +++ 
>> maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/IOUtilTest.java
>>  Wed May 25 09:10:46 2011
>> @@ -19,6 +19,7 @@ package org.codehaus.plexus.util;
>>  * under the License.
>>  */
>>
>> +import org.apache.maven.tck.ReproducesPlexusBug;
>>  import org.junit.Test;
>>
>>  import java.io.BufferedInputStream;
>> @@ -393,6 +394,7 @@ public class IOUtilTest
>>     }
>>
>>     @Test( timeout = 150 )
>> +    @ReproducesPlexusBug( "Should not infinite loop" )
>>     public void toStringEmptyByteArrayZeroBufSz()
>>         throws Exception
>>     {
>> @@ -420,6 +422,7 @@ public class IOUtilTest
>>     }
>>
>>     @Test( timeout = 150 )
>> +    @ReproducesPlexusBug( "Should not infinite loop" )
>>     public void toStringByteArrayZeroBufSz()
>>         throws Exception
>>     {
>> @@ -655,6 +658,7 @@ public class IOUtilTest
>>     }
>>
>>     @Test( timeout = 150 )
>> +    @ReproducesPlexusBug( "Should not infinite loop" )
>>     public void toStringEmptyByteArrayValidEncodingZeroBufSz()
>>         throws Exception
>>     {
>> @@ -682,6 +686,7 @@ public class IOUtilTest
>>     }
>>
>>     @Test( timeout = 150 )
>> +    @ReproducesPlexusBug( "Should not infinite loop" )
>>     public void

Re: Handling of unrecognised version qualifiers

2011-05-27 Thread Paul Gier

On 05/27/2011 11:44 AM, Mark Struberg wrote:
> It's about
> 
> 1.0 
>   vs 
> 1.0-RC (Release Candidate)  
>   vs
> 1.0-MR (Maintenance Release)
> 
> right?
> 

Yes.  RC is recognized by Maven 3 as earlier than GA (or no qualifier).
 MR is not recognized by Maven 3 and is assumed to be later than GA.


> I think one solution is in general equally good as the other since there is 
> no generally working solution.
> 
> 
> Thus I'd also strongly +1 for re-establishing the old behaviour. Otherwise 
> we'd break backward compatibility. Also note that this code was (is still?) 
> duplicated a few times over the whole codebase - and also got 'cloned' in 
> plugins.
> 
> Maven3 is warning about non-pinned versions anyway, so it's really mostly 
> about old mvn2 projects which would suddenly be broken in mvn3.
> 
> LieGrue,
> strub
> 
> --- On Fri, 5/27/11, John Casey  wrote:
> 
>> From: John Casey 
>> Subject: Re: Handling of unrecognised version qualifiers
>> To: "Maven Developers List" 
>> Date: Friday, May 27, 2011, 4:31 PM
>>
>>
>> On 5/27/11 12:02 PM, Paul Gier wrote:
>>> Maven 3 currently treats unrecognised version
>> qualifiers as newer
>>> releases than the GA release.  For example:
>>>
>>> 1.0 is older than 1.0-xyz
>>>
>>> It also looks like this was reversed at some point,
>> since there is a
>>> test case commented out on line 117 that expects the
>> opposite behaviour
>>> [1].  So is the current behaviour correct? 
>> Or does the commented test
>>> case mean that this ordering will be reversed at some
>> point in the future?
>>>
>>> My personal preference is that we replace the
>> commented test case with
>>> one testing for the reverse order, so that we prevent
>> this from changing
>>> in the future.  So all unrecognised qualifiers
>> are treated as patch
>>> releases, and considered newer than the GA release.
>>
>> FWIW, I completely agree. We have a use case where existing
>> artifacts need to be rebuilt, in order to provide separate
>> testing/signing/etc.
>>
>> I think we need to formalize methods for specifying
>> versions that allow proper sorting in two different
>> scenarios:
>>
>> 1. rebuilds, which I think the current (accidental?)
>> sorting of 1.0-myco-1 as more recent than 1.0 handles
>> neatly. This should be formalized in the version spec.
>>
>> 2. patched, pre-release builds, such as when a company has
>> developed a patch for a version of some project, but this
>> patch hasn't been incorporated into an official release yet.
>> In this case, using something like 1.0-m1-myco might signify
>> that this is a patch/milestone build of 1.0 (so, pre-1.0)
>> created by 'myco'...and, sort as "older" than 1.0. Again,
>> something like this should be formalized in our version
>> spec.
>>
>> Just my $0.02
>>
>>>
>>> Thanks!
>>>
>>> [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
>>>
>>>
>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>> -- John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> Blog: http://www.johnofalltrades.name/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Handling of unrecognised version qualifiers

2011-05-27 Thread John Casey

On 5/27/11 1:03 PM, Benson Margulies wrote:

This seems to me to call out for an 'extension point' that supplies an
object that implements a protocol for making version decisions.

That would bring up the issue of how Maven switches between version
schemes on the fly when resolving transitive dependencies...and, whether
a given newcomer to the project could build it with a plain old vanilla
version of Maven.

On Fri, May 27, 2011 at 12:31 PM, John Casey wrote:

On 5/27/11 12:02 PM, Paul Gier wrote:

Maven 3 currently treats unrecognised version qualifiers as newer
releases than the GA release. For example:

1.0 is older than 1.0-xyz

It also looks like this was reversed at some point, since there is a
test case commented out on line 117 that expects the opposite behaviour
[1]. So is the current behaviour correct? Or does the commented test
case mean that this ordering will be reversed at some point in the future?

My personal preference is that we replace the commented test case with
one testing for the reverse order, so that we prevent this from changing
in the future. So all unrecognised qualifiers are treated as patch
releases, and considered newer than the GA release.

FWIW, I completely agree. We have a use case where existing artifacts need
to be rebuilt, in order to provide separate testing/signing/etc.

I think we need to formalize methods for specifying versions that allow
proper sorting in two different scenarios:

1. rebuilds, which I think the current (accidental?) sorting of 1.0-myco-1
as more recent than 1.0 handles neatly. This should be formalized in the
version spec.

2. patched, pre-release builds, such as when a company has developed a patch
for a version of some project, but this patch hasn't been incorporated into
an official release yet. In this case, using something like 1.0-m1-myco
might signify that this is a patch/milestone build of 1.0 (so, pre-1.0)
created by 'myco'...and, sort as "older" than 1.0. Again, something like
this should be formalized in our version spec.

Just my $0.02

Thanks!

[1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Handling of unrecognised version qualifiers

2011-05-27 Thread John Casey




On 5/27/11 1:16 PM, Mark Struberg wrote:

not sure if that would scale.

One dependency is using CR as acronym for 'candidate release' another is using 
it for 'correctional release' or something.

Since there is no fixed list, this would really be hard to impl.
In fact it's mostly about sub-numbers (split with a '-').


There may not be a fixed list in absolute terms, but it's easy enough to 
fit into mainstream use cases without much extra work.


In my case, I'm talking about

1.0-RC1 (release candidate)
.
1.0 (community release)
.
1.0-myco-1 (verification/signed REBUILD of community release; 1st
.   independent rebuild of 1.0 codebase from 'myco')
.
1.0-myco-2 (patches to 1.0 community release; 2nd build of 1.0 codebase
.   from 'myco')
.
1.1

I'm less concerned with making One Version Scheme to Rule Them All, and 
more interested in defining a path for these use cases in our Maven-ish 
version scheme, so if folks are interested in using the mainstream 
version scheme, that scheme is enough to cope with real world 
scenarios...regardless of whether some people don't like *how* it copes.




LieGrue,
strub

--- On Fri, 5/27/11, Benson Margulies  wrote:


From: Benson Margulies
Subject: Re: Handling of unrecognised version qualifiers
To: "Maven Developers List"
Date: Friday, May 27, 2011, 5:03 PM
This seems to me to call out for an
'extension point' that supplies an
object that implements a protocol for making version
decisions.

On Fri, May 27, 2011 at 12:31 PM, John Casey
wrote:



On 5/27/11 12:02 PM, Paul Gier wrote:


Maven 3 currently treats unrecognised version

qualifiers as newer

releases than the GA release.  For example:

1.0 is older than 1.0-xyz

It also looks like this was reversed at some

point, since there is a

test case commented out on line 117 that expects

the opposite behaviour

[1].  So is the current behaviour correct?  Or

does the commented test

case mean that this ordering will be reversed at

some point in the future?


My personal preference is that we replace the

commented test case with

one testing for the reverse order, so that we

prevent this from changing

in the future.  So all unrecognised qualifiers

are treated as patch

releases, and considered newer than the GA

release.


FWIW, I completely agree. We have a use case where

existing artifacts need

to be rebuilt, in order to provide separate

testing/signing/etc.


I think we need to formalize methods for specifying

versions that allow

proper sorting in two different scenarios:

1. rebuilds, which I think the current (accidental?)

sorting of 1.0-myco-1

as more recent than 1.0 handles neatly. This should be

formalized in the

version spec.

2. patched, pre-release builds, such as when a company

has developed a patch

for a version of some project, but this patch hasn't

been incorporated into

an official release yet. In this case, using something

like 1.0-m1-myco

might signify that this is a patch/milestone build of

1.0 (so, pre-1.0)

created by 'myco'...and, sort as "older" than 1.0.

Again, something like

this should be formalized in our version spec.

Just my $0.02



Thanks!


[1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807



-

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/



-

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Handling of unrecognised version qualifiers

2011-05-27 Thread Mark Struberg

not sure if that would scale. 

One dependency is using CR as acronym for 'candidate release' another is using 
it for 'correctional release' or something.

Since there is no fixed list, this would really be hard to impl.
In fact it's mostly about sub-numbers (split with a '-').

LieGrue,
strub

--- On Fri, 5/27/11, Benson Margulies  wrote:

> From: Benson Margulies 
> Subject: Re: Handling of unrecognised version qualifiers
> To: "Maven Developers List" 
> Date: Friday, May 27, 2011, 5:03 PM
> This seems to me to call out for an
> 'extension point' that supplies an
> object that implements a protocol for making version
> decisions.
> 
> On Fri, May 27, 2011 at 12:31 PM, John Casey 
> wrote:
> >
> >
> > On 5/27/11 12:02 PM, Paul Gier wrote:
> >>
> >> Maven 3 currently treats unrecognised version
> qualifiers as newer
> >> releases than the GA release.  For example:
> >>
> >> 1.0 is older than 1.0-xyz
> >>
> >> It also looks like this was reversed at some
> point, since there is a
> >> test case commented out on line 117 that expects
> the opposite behaviour
> >> [1].  So is the current behaviour correct?  Or
> does the commented test
> >> case mean that this ordering will be reversed at
> some point in the future?
> >>
> >> My personal preference is that we replace the
> commented test case with
> >> one testing for the reverse order, so that we
> prevent this from changing
> >> in the future.  So all unrecognised qualifiers
> are treated as patch
> >> releases, and considered newer than the GA
> release.
> >
> > FWIW, I completely agree. We have a use case where
> existing artifacts need
> > to be rebuilt, in order to provide separate
> testing/signing/etc.
> >
> > I think we need to formalize methods for specifying
> versions that allow
> > proper sorting in two different scenarios:
> >
> > 1. rebuilds, which I think the current (accidental?)
> sorting of 1.0-myco-1
> > as more recent than 1.0 handles neatly. This should be
> formalized in the
> > version spec.
> >
> > 2. patched, pre-release builds, such as when a company
> has developed a patch
> > for a version of some project, but this patch hasn't
> been incorporated into
> > an official release yet. In this case, using something
> like 1.0-m1-myco
> > might signify that this is a patch/milestone build of
> 1.0 (so, pre-1.0)
> > created by 'myco'...and, sort as "older" than 1.0.
> Again, something like
> > this should be formalized in our version spec.
> >
> > Just my $0.02
> >
> >>
> >> Thanks!
> >>
> >>
> >> [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
> >>
> >>
> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> > --
> > John Casey
> > Developer, PMC Member - Apache Maven (http://maven.apache.org)
> > Blog: http://www.johnofalltrades.name/
> >
> >
> -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Handling of unrecognised version qualifiers

2011-05-27 Thread Benson Margulies

This seems to me to call out for an 'extension point' that supplies an
object that implements a protocol for making version decisions.

On Fri, May 27, 2011 at 12:31 PM, John Casey  wrote:
>
>
> On 5/27/11 12:02 PM, Paul Gier wrote:
>>
>> Maven 3 currently treats unrecognised version qualifiers as newer
>> releases than the GA release.  For example:
>>
>> 1.0 is older than 1.0-xyz
>>
>> It also looks like this was reversed at some point, since there is a
>> test case commented out on line 117 that expects the opposite behaviour
>> [1].  So is the current behaviour correct?  Or does the commented test
>> case mean that this ordering will be reversed at some point in the future?
>>
>> My personal preference is that we replace the commented test case with
>> one testing for the reverse order, so that we prevent this from changing
>> in the future.  So all unrecognised qualifiers are treated as patch
>> releases, and considered newer than the GA release.
>
> FWIW, I completely agree. We have a use case where existing artifacts need
> to be rebuilt, in order to provide separate testing/signing/etc.
>
> I think we need to formalize methods for specifying versions that allow
> proper sorting in two different scenarios:
>
> 1. rebuilds, which I think the current (accidental?) sorting of 1.0-myco-1
> as more recent than 1.0 handles neatly. This should be formalized in the
> version spec.
>
> 2. patched, pre-release builds, such as when a company has developed a patch
> for a version of some project, but this patch hasn't been incorporated into
> an official release yet. In this case, using something like 1.0-m1-myco
> might signify that this is a patch/milestone build of 1.0 (so, pre-1.0)
> created by 'myco'...and, sort as "older" than 1.0. Again, something like
> this should be formalized in our version spec.
>
> Just my $0.02
>
>>
>> Thanks!
>>
>>
>> [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Handling of unrecognised version qualifiers

2011-05-27 Thread Mark Struberg

It's about

1.0 
  vs 
1.0-RC (Release Candidate)  
  vs
1.0-MR (Maintenance Release)

right?

I think one solution is in general equally good as the other since there is no 
generally working solution.


Thus I'd also strongly +1 for re-establishing the old behaviour. Otherwise we'd 
break backward compatibility. Also note that this code was (is still?) 
duplicated a few times over the whole codebase - and also got 'cloned' in 
plugins.

Maven3 is warning about non-pinned versions anyway, so it's really mostly about 
old mvn2 projects which would suddenly be broken in mvn3.

LieGrue,
strub

--- On Fri, 5/27/11, John Casey  wrote:

> From: John Casey 
> Subject: Re: Handling of unrecognised version qualifiers
> To: "Maven Developers List" 
> Date: Friday, May 27, 2011, 4:31 PM
> 
> 
> On 5/27/11 12:02 PM, Paul Gier wrote:
> > Maven 3 currently treats unrecognised version
> qualifiers as newer
> > releases than the GA release.  For example:
> > 
> > 1.0 is older than 1.0-xyz
> > 
> > It also looks like this was reversed at some point,
> since there is a
> > test case commented out on line 117 that expects the
> opposite behaviour
> > [1].  So is the current behaviour correct? 
> Or does the commented test
> > case mean that this ordering will be reversed at some
> point in the future?
> > 
> > My personal preference is that we replace the
> commented test case with
> > one testing for the reverse order, so that we prevent
> this from changing
> > in the future.  So all unrecognised qualifiers
> are treated as patch
> > releases, and considered newer than the GA release.
> 
> FWIW, I completely agree. We have a use case where existing
> artifacts need to be rebuilt, in order to provide separate
> testing/signing/etc.
> 
> I think we need to formalize methods for specifying
> versions that allow proper sorting in two different
> scenarios:
> 
> 1. rebuilds, which I think the current (accidental?)
> sorting of 1.0-myco-1 as more recent than 1.0 handles
> neatly. This should be formalized in the version spec.
> 
> 2. patched, pre-release builds, such as when a company has
> developed a patch for a version of some project, but this
> patch hasn't been incorporated into an official release yet.
> In this case, using something like 1.0-m1-myco might signify
> that this is a patch/milestone build of 1.0 (so, pre-1.0)
> created by 'myco'...and, sort as "older" than 1.0. Again,
> something like this should be formalized in our version
> spec.
> 
> Just my $0.02
> 
> > 
> > Thanks!
> > 
> > [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
> > 
> >
> -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> 
> -- John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Handling of unrecognised version qualifiers

2011-05-27 Thread John Casey

On 5/27/11 12:02 PM, Paul Gier wrote:

Maven 3 currently treats unrecognised version qualifiers as newer
releases than the GA release. For example:

1.0 is older than 1.0-xyz

FWIW, I completely agree. We have a use case where existing artifacts
need to be rebuilt, in order to provide separate testing/signing/etc.

I think we need to formalize methods for specifying versions that allow
proper sorting in two different scenarios:

1. rebuilds, which I think the current (accidental?) sorting of
1.0-myco-1 as more recent than 1.0 handles neatly. This should be
formalized in the version spec.

2. patched, pre-release builds, such as when a company has developed a
patch for a version of some project, but this patch hasn't been
incorporated into an official release yet. In this case, using something
like 1.0-m1-myco might signify that this is a patch/milestone build of
1.0 (so, pre-1.0) created by 'myco'...and, sort as "older" than 1.0.
Again, something like this should be formalized in our version spec.

Just my $0.02

Thanks!

[1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Interested in helping a research study on Eclipse?

2011-05-27 Thread Mohsen Vakilian

Hi

I'm Mohsen, a PhD student working with Prof. Ralph Johnson at the University of 
Illinois at Urbana-Champaign (UIUC). Together with my team mates [1], we are 
conducting a research study to better understand how developers, across 
different 
projects, interact with the Eclipse IDE for evolving and maintaining their 
code. We are 
extending this invitation to Java developers and would greatly appreciate and 
value 
your participation and help in our research study.

To participate you should be at least 18 years old and use the Eclipse IDE for 
Java 
development. As a participant, we ask that you complete a short survey and 
install 
our Eclipse plug-in called CodingSpectator [2].

CodingSpectator monitors programming interactions non-intrusively in the 
background 
and periodically uploads it to a secure server at UIUC. To get a representative 
perspective of how you interact with Eclipse, we would appreciate if you could 
install 
CodingSpectator for two months. Rest assured that we are taking the utmost 
measures to protect your privacy and confidentiality.

If you are interested, you may sign up at 
, which contains our 
consent 
form with all the details and procedures of our research study.

Your participation will help us greatly as we try to better understand how 
developers 
interact with their IDE's so we can propose improvements which fit better with 
their 
mindsets.

Thanks in advance for your time! Please do not hesitate to contact me 
(mvaki...@illinois.edu) if you have any questions or comments. More information 
can 
also be found at our FAQ [3]. Feel free to forward this invitation to anyone 
who might 
be interested in participating in this study.

--
Mohsen Vakilian
& the CodingSpectator team

[1] http://codingspectator.cs.illinois.edu/People
[2] http://codingspectator.cs.illinois.edu
[3] http://codingspectator.cs.illinois.edu/FAQ

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Handling of unrecognised version qualifiers

2011-05-27 Thread Paul Gier

Maven 3 currently treats unrecognised version qualifiers as newer
releases than the GA release.  For example:

1.0 is older than 1.0-xyz

It also looks like this was reversed at some point, since there is a
test case commented out on line 117 that expects the opposite behaviour
[1].  So is the current behaviour correct?  Or does the commented test
case mean that this ordering will be reversed at some point in the future?

My personal preference is that we replace the commented test case with
one testing for the reverse order, so that we prevent this from changing
in the future.  So all unrecognised qualifiers are treated as patch
releases, and considered newer than the GA release.

Thanks!

[1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java

2011-05-27 Thread Lukas Theussl




Daniel Kulp wrote:

On Friday, May 27, 2011 9:32:20 AM Benson Margulies wrote:

That's interesting. *how* did it break that build?


Honestly, I didn't really dig into it.   I just noticed in the pom that you
updated the asm version to 3.3.1, but you didn't update the asm-common version
to match it.On a whim, I just updated it as well and the it test passed.
Apparently they need to be kept in sync.

In anycase, for your information, (and mine as I keep forgetting this) it's
good to run "mvn install -Drun-its" to run the integration tests as well.


[That should be -Prun-its]

FYI I have ticked the option "Send separate email to the person who 
broke the build" in Jenkins so next time you should get a note directly 
from there. :)



Cheers,
-Lukas



Dan




On Fri, May 27, 2011 at 8:49 AM, Daniel Kulp  wrote:

On Friday, May 27, 2011 4:37:45 AM Lukas Theussl wrote:

Daniel,

This commit breaks jenkins:

https://builds.apache.org//view/M-R/view/Maven/job/maven-plugins-ITs-2.x
/

and I also see it locally, can you review?


I  committed a fix and re-triggered a Jenkins build and it looks OK now.
Thanks for the heads up!   I always forget about the ITs.

I'll blame Benson, it was his patch...  ;-)


Dan


Thanks,
-Lukas

dk...@apache.org wrote:

Author: dkulp
Date: Thu May 26 14:30:55 2011
New Revision: 1127943

URL: http://svn.apache.org/viewvc?rev=1127943&view=rev
Log:
[MSHADE-99] Update to latest ASM to fix error message
Add javadoc
Patch from Benson Margulies applied

Modified:
  maven/plugins/trunk/maven-shade-plugin/pom.xml

  maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/mave
n/plugins/shade/DefaultShader.java

  maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/mav
en/plugins/shade/Shader.java

Modified: maven/plugins/trunk/maven-shade-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/po
m. xml?rev=1127943&r1=1127942&r2=1127943&view=diff
==
== == --- maven/plugins/trunk/maven-shade-plugin/pom.xml
(original) +++ maven/plugins/trunk/maven-shade-plugin/pom.xml Thu May
26 14:30:55 2011 @@ -97,7 +97,7 @@ under the License.

   

 asm
 asm

-3.2
+3.3.1

   
   

 asm

Modified:
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
pl ugins/shade/DefaultShader.java URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/sr
c/
main/java/org/apache/maven/plugins/shade/DefaultShader.java?rev=11279
43&r 1=1127942&r2=1127943&view=diff
==
== == ---
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
pl ugins/shade/DefaultShader.java (original) +++
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
pl ugins/shade/DefaultShader.java Thu May 26 14:30:55 2011 @@ -36,6
+36,7 @@ import java.util.regex.Matcher;

   import java.util.regex.Pattern;
   import java.util.zip.ZipException;

+import org.apache.maven.plugin.MojoExecutionException;

   import org.apache.maven.plugins.shade.relocation.Relocator;
   import
   org.apache.maven.plugins.shade.resource.ManifestResourceTransformer;
   import org.apache.maven.plugins.shade.resource.ResourceTransformer;

@@ -57,7 +58,7 @@ public class DefaultShader

   {

   public void shade( Set jars, File uberJar, List filters, List
   relocators, List resourceTransformers )

-throws IOException
+throws IOException, MojoExecutionException

   {

   Set resources = new HashSet();

@@ -241,7 +242,7 @@ public class DefaultShader

   private void addRemappedClass( RelocatorRemapper remapper,
   JarOutputStream jos, File jar, String name,

  InputStream is )

-throws IOException
+throws IOException, MojoExecutionException

   {

   if ( !remapper.hasRelocators() )
   {

@@ -264,7 +265,12 @@ public class DefaultShader

   ClassVisitor cv = new TempRemappingClassAdapter( cw,
remapper );

-cr.accept( cv, ClassReader.EXPAND_FRAMES );
+try {
+   cr.accept( cv, ClassReader.EXPAND_FRAMES );
+} catch ( Throwable ise ) {
+   throw new MojoExecutionException ("Error in ASM processing
class " +   + name, ise );
+}

   byte[] renamedClass = cw.toByteArray();

Modified:
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
pl ugins/shade/Shader.java URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/sr
c/
main/java/org/apache/maven/plugins/shade/Shader.java?rev=1127943&r1=1
1279 42&r2=1127943&view=diff
==
== == ---
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
pl ugins/shade/Shader.java (original) +++
maven/plugins/trunk/maven-shade-plugin/s

Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java

2011-05-27 Thread Daniel Kulp

On Friday, May 27, 2011 9:32:20 AM Benson Margulies wrote:
> That's interesting. *how* did it break that build?

Honestly, I didn't really dig into it.   I just noticed in the pom that you 
updated the asm version to 3.3.1, but you didn't update the asm-common version 
to match it.On a whim, I just updated it as well and the it test passed.  
Apparently they need to be kept in sync.  

In anycase, for your information, (and mine as I keep forgetting this) it's 
good to run "mvn install -Drun-its" to run the integration tests as well.

Dan



> On Fri, May 27, 2011 at 8:49 AM, Daniel Kulp  wrote:
> > On Friday, May 27, 2011 4:37:45 AM Lukas Theussl wrote:
> >> Daniel,
> >> 
> >> This commit breaks jenkins:
> >> 
> >> https://builds.apache.org//view/M-R/view/Maven/job/maven-plugins-ITs-2.x
> >> /
> >> 
> >> and I also see it locally, can you review?
> > 
> > I  committed a fix and re-triggered a Jenkins build and it looks OK now.
> > Thanks for the heads up!   I always forget about the ITs.
> > 
> > I'll blame Benson, it was his patch...  ;-)
> > 
> > 
> > Dan
> > 
> >> Thanks,
> >> -Lukas
> >> 
> >> dk...@apache.org wrote:
> >> > Author: dkulp
> >> > Date: Thu May 26 14:30:55 2011
> >> > New Revision: 1127943
> >> > 
> >> > URL: http://svn.apache.org/viewvc?rev=1127943&view=rev
> >> > Log:
> >> > [MSHADE-99] Update to latest ASM to fix error message
> >> > Add javadoc
> >> > Patch from Benson Margulies applied
> >> > 
> >> > Modified:
> >> >  maven/plugins/trunk/maven-shade-plugin/pom.xml
> >> >
> >> >  maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/mave
> >> > n/plugins/shade/DefaultShader.java
> >> >
> >> >  maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/mav
> >> > en/plugins/shade/Shader.java
> >> > 
> >> > Modified: maven/plugins/trunk/maven-shade-plugin/pom.xml
> >> > URL:
> >> > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/po
> >> > m. xml?rev=1127943&r1=1127942&r2=1127943&view=diff
> >> > ==
> >> > == == --- maven/plugins/trunk/maven-shade-plugin/pom.xml
> >> > (original) +++ maven/plugins/trunk/maven-shade-plugin/pom.xml Thu May
> >> > 26 14:30:55 2011 @@ -97,7 +97,7 @@ under the License.
> >> > 
> >> >   
> >> > 
> >> > asm
> >> > asm
> >> > 
> >> > -3.2
> >> > +3.3.1
> >> > 
> >> >   
> >> >   
> >> > 
> >> > asm
> >> > 
> >> > Modified:
> >> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
> >> > pl ugins/shade/DefaultShader.java URL:
> >> > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/sr
> >> > c/
> >> > main/java/org/apache/maven/plugins/shade/DefaultShader.java?rev=11279
> >> > 43&r 1=1127942&r2=1127943&view=diff
> >> > ==
> >> > == == ---
> >> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
> >> > pl ugins/shade/DefaultShader.java (original) +++
> >> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/
> >> > pl ugins/shade/DefaultShader.java Thu May 26 14:30:55 2011 @@ -36,6
> >> > +36,7 @@ import java.util.regex.Matcher;
> >> > 
> >> >   import java.util.regex.Pattern;
> >> >   import java.util.zip.ZipException;
> >> > 
> >> > +import org.apache.maven.plugin.MojoExecutionException;
> >> > 
> >> >   import org.apache.maven.plugins.shade.relocation.Relocator;
> >> >   import
> >> >   org.apache.maven.plugins.shade.resource.ManifestResourceTransformer;
> >> >   import org.apache.maven.plugins.shade.resource.ResourceTransformer;
> >> > 
> >> > @@ -57,7 +58,7 @@ public class DefaultShader
> >> > 
> >> >   {
> >> > 
> >> >   public void shade( Set jars, File uberJar, List filters, List
> >> >   relocators, List resourceTransformers )
> >> > 
> >> > -throws IOException
> >> > +throws IOException, MojoExecutionException
> >> > 
> >> >   {
> >> > 
> >> >   Set resources = new HashSet();
> >> > 
> >> > @@ -241,7 +242,7 @@ public class DefaultShader
> >> > 
> >> >   private void addRemappedClass( RelocatorRemapper remapper,
> >> >   JarOutputStream jos, File jar, String name,
> >> > 
> >> >  InputStream is )
> >> > 
> >> > -throws IOException
> >> > +throws IOException, MojoExecutionException
> >> > 
> >> >   {
> >> > 
> >> >   if ( !remapper.hasRelocators() )
> >> >   {
> >> > 
> >> > @@ -264,7 +265,12 @@ public class DefaultShader
> >> > 
> >> >   ClassVisitor cv = new TempRemappingClassAdapter( cw,
> >> > remapper );
> >> > 
> >> > -cr.accept( cv, ClassReader.EXPAND_FRAMES );
> >> > +try {
> >> > +   cr.accept( cv, ClassReader.EXPAND_FRAMES );
> >> > +} catch ( Throwable ise ) {
> >> > +   throw new MojoExecutionException ("Error in ASM processing
> >> > class " +   + name, i

Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java

2011-05-27 Thread Benson Margulies

That's interesting. *how* did it break that build?

On Fri, May 27, 2011 at 8:49 AM, Daniel Kulp  wrote:
> On Friday, May 27, 2011 4:37:45 AM Lukas Theussl wrote:
>> Daniel,
>>
>> This commit breaks jenkins:
>>
>> https://builds.apache.org//view/M-R/view/Maven/job/maven-plugins-ITs-2.x/
>>
>> and I also see it locally, can you review?
>
> I  committed a fix and re-triggered a Jenkins build and it looks OK now.
> Thanks for the heads up!   I always forget about the ITs.
>
> I'll blame Benson, it was his patch...  ;-)
>
>
> Dan
>
>
>
>
>>
>> Thanks,
>> -Lukas
>>
>> dk...@apache.org wrote:
>> > Author: dkulp
>> > Date: Thu May 26 14:30:55 2011
>> > New Revision: 1127943
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1127943&view=rev
>> > Log:
>> > [MSHADE-99] Update to latest ASM to fix error message
>> > Add javadoc
>> > Patch from Benson Margulies applied
>> >
>> > Modified:
>> >      maven/plugins/trunk/maven-shade-plugin/pom.xml
>> >      maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/mave
>> >      n/plugins/shade/DefaultShader.java
>> >      maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/mav
>> >      en/plugins/shade/Shader.java
>> >
>> > Modified: maven/plugins/trunk/maven-shade-plugin/pom.xml
>> > URL:
>> > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/pom.
>> > xml?rev=1127943&r1=1127942&r2=1127943&view=diff
>> > 
>> > == --- maven/plugins/trunk/maven-shade-plugin/pom.xml (original)
>> > +++ maven/plugins/trunk/maven-shade-plugin/pom.xml Thu May 26 14:30:55
>> > 2011 @@ -97,7 +97,7 @@ under the License.
>> >
>> >       
>> >
>> >         asm
>> >         asm
>> >
>> > -3.2
>> > +3.3.1
>> >
>> >       
>> >       
>> >
>> >         asm
>> >
>> > Modified:
>> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
>> > ugins/shade/DefaultShader.java URL:
>> > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/src/
>> > main/java/org/apache/maven/plugins/shade/DefaultShader.java?rev=1127943&r
>> > 1=1127942&r2=1127943&view=diff
>> > 
>> > == ---
>> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
>> > ugins/shade/DefaultShader.java (original) +++
>> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
>> > ugins/shade/DefaultShader.java Thu May 26 14:30:55 2011 @@ -36,6 +36,7 @@
>> > import java.util.regex.Matcher;
>> >
>> >   import java.util.regex.Pattern;
>> >   import java.util.zip.ZipException;
>> >
>> > +import org.apache.maven.plugin.MojoExecutionException;
>> >
>> >   import org.apache.maven.plugins.shade.relocation.Relocator;
>> >   import
>> >   org.apache.maven.plugins.shade.resource.ManifestResourceTransformer;
>> >   import org.apache.maven.plugins.shade.resource.ResourceTransformer;
>> >
>> > @@ -57,7 +58,7 @@ public class DefaultShader
>> >
>> >   {
>> >
>> >       public void shade( Set jars, File uberJar, List filters, List
>> >       relocators, List resourceTransformers )
>> >
>> > -        throws IOException
>> > +        throws IOException, MojoExecutionException
>> >
>> >       {
>> >
>> >           Set resources = new HashSet();
>> >
>> > @@ -241,7 +242,7 @@ public class DefaultShader
>> >
>> >       private void addRemappedClass( RelocatorRemapper remapper,
>> >       JarOutputStream jos, File jar, String name,
>> >
>> >                                      InputStream is )
>> >
>> > -        throws IOException
>> > +        throws IOException, MojoExecutionException
>> >
>> >       {
>> >
>> >           if ( !remapper.hasRelocators() )
>> >           {
>> >
>> > @@ -264,7 +265,12 @@ public class DefaultShader
>> >
>> >           ClassVisitor cv = new TempRemappingClassAdapter( cw, remapper
>> >           );
>> >
>> > -        cr.accept( cv, ClassReader.EXPAND_FRAMES );
>> > +        try {
>> > +           cr.accept( cv, ClassReader.EXPAND_FRAMES );
>> > +        } catch ( Throwable ise ) {
>> > +           throw new MojoExecutionException ("Error in ASM processing
>> > class " +                           + name, ise );
>> > +        }
>> >
>> >           byte[] renamedClass = cw.toByteArray();
>> >
>> > Modified:
>> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
>> > ugins/shade/Shader.java URL:
>> > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/src/
>> > main/java/org/apache/maven/plugins/shade/Shader.java?rev=1127943&r1=11279
>> > 42&r2=1127943&view=diff
>> > 
>> > == ---
>> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
>> > ugins/shade/Shader.java (original) +++
>> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
>> > ugins/shade/Shader.java Thu May 26 14:30:55 2011 @@ -24,11 +24,26 @@
>> > import java.io.IOEx

Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java

2011-05-27 Thread Daniel Kulp

On Friday, May 27, 2011 4:37:45 AM Lukas Theussl wrote:
> Daniel,
> 
> This commit breaks jenkins:
> 
> https://builds.apache.org//view/M-R/view/Maven/job/maven-plugins-ITs-2.x/
> 
> and I also see it locally, can you review?

I  committed a fix and re-triggered a Jenkins build and it looks OK now.  
Thanks for the heads up!   I always forget about the ITs.

I'll blame Benson, it was his patch...  ;-)


Dan




> 
> Thanks,
> -Lukas
> 
> dk...@apache.org wrote:
> > Author: dkulp
> > Date: Thu May 26 14:30:55 2011
> > New Revision: 1127943
> > 
> > URL: http://svn.apache.org/viewvc?rev=1127943&view=rev
> > Log:
> > [MSHADE-99] Update to latest ASM to fix error message
> > Add javadoc
> > Patch from Benson Margulies applied
> > 
> > Modified:
> >  maven/plugins/trunk/maven-shade-plugin/pom.xml
> >  maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/mave
> >  n/plugins/shade/DefaultShader.java
> >  maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/mav
> >  en/plugins/shade/Shader.java
> > 
> > Modified: maven/plugins/trunk/maven-shade-plugin/pom.xml
> > URL:
> > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/pom.
> > xml?rev=1127943&r1=1127942&r2=1127943&view=diff
> > 
> > == --- maven/plugins/trunk/maven-shade-plugin/pom.xml (original)
> > +++ maven/plugins/trunk/maven-shade-plugin/pom.xml Thu May 26 14:30:55
> > 2011 @@ -97,7 +97,7 @@ under the License.
> > 
> >   
> >   
> > asm
> > asm
> > 
> > -3.2
> > +3.3.1
> > 
> >   
> >   
> >   
> > asm
> > 
> > Modified:
> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
> > ugins/shade/DefaultShader.java URL:
> > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/src/
> > main/java/org/apache/maven/plugins/shade/DefaultShader.java?rev=1127943&r
> > 1=1127942&r2=1127943&view=diff
> > 
> > == ---
> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
> > ugins/shade/DefaultShader.java (original) +++
> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
> > ugins/shade/DefaultShader.java Thu May 26 14:30:55 2011 @@ -36,6 +36,7 @@
> > import java.util.regex.Matcher;
> > 
> >   import java.util.regex.Pattern;
> >   import java.util.zip.ZipException;
> > 
> > +import org.apache.maven.plugin.MojoExecutionException;
> > 
> >   import org.apache.maven.plugins.shade.relocation.Relocator;
> >   import
> >   org.apache.maven.plugins.shade.resource.ManifestResourceTransformer;
> >   import org.apache.maven.plugins.shade.resource.ResourceTransformer;
> > 
> > @@ -57,7 +58,7 @@ public class DefaultShader
> > 
> >   {
> >   
> >   public void shade( Set jars, File uberJar, List filters, List
> >   relocators, List resourceTransformers )
> > 
> > -throws IOException
> > +throws IOException, MojoExecutionException
> > 
> >   {
> >   
> >   Set resources = new HashSet();
> > 
> > @@ -241,7 +242,7 @@ public class DefaultShader
> > 
> >   private void addRemappedClass( RelocatorRemapper remapper,
> >   JarOutputStream jos, File jar, String name,
> >   
> >  InputStream is )
> > 
> > -throws IOException
> > +throws IOException, MojoExecutionException
> > 
> >   {
> >   
> >   if ( !remapper.hasRelocators() )
> >   {
> > 
> > @@ -264,7 +265,12 @@ public class DefaultShader
> > 
> >   ClassVisitor cv = new TempRemappingClassAdapter( cw, remapper
> >   );
> > 
> > -cr.accept( cv, ClassReader.EXPAND_FRAMES );
> > +try {
> > +   cr.accept( cv, ClassReader.EXPAND_FRAMES );
> > +} catch ( Throwable ise ) {
> > +   throw new MojoExecutionException ("Error in ASM processing
> > class " +   + name, ise );
> > +}
> > 
> >   byte[] renamedClass = cw.toByteArray();
> > 
> > Modified:
> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
> > ugins/shade/Shader.java URL:
> > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/src/
> > main/java/org/apache/maven/plugins/shade/Shader.java?rev=1127943&r1=11279
> > 42&r2=1127943&view=diff
> > 
> > == ---
> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
> > ugins/shade/Shader.java (original) +++
> > maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/pl
> > ugins/shade/Shader.java Thu May 26 14:30:55 2011 @@ -24,11 +24,26 @@
> > import java.io.IOException;
> > 
> >   import java.util.List;
> >   import java.util.Set;
> > 
> > -/** @author Jason van Zyl */
> > +import org.apache.maven.plugin.MojoExecutionException;
> > +
> > +/**
>

Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java

2011-05-27 Thread Lukas Theussl



Daniel,

This commit breaks jenkins:

https://builds.apache.org//view/M-R/view/Maven/job/maven-plugins-ITs-2.x/

and I also see it locally, can you review?

Thanks,
-Lukas


dk...@apache.org wrote:

Author: dkulp
Date: Thu May 26 14:30:55 2011
New Revision: 1127943

URL: http://svn.apache.org/viewvc?rev=1127943&view=rev
Log:
[MSHADE-99] Update to latest ASM to fix error message
Add javadoc
Patch from Benson Margulies applied


Modified:
 maven/plugins/trunk/maven-shade-plugin/pom.xml
 
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java
 
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/Shader.java

Modified: maven/plugins/trunk/maven-shade-plugin/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/pom.xml?rev=1127943&r1=1127942&r2=1127943&view=diff
==
--- maven/plugins/trunk/maven-shade-plugin/pom.xml (original)
+++ maven/plugins/trunk/maven-shade-plugin/pom.xml Thu May 26 14:30:55 2011
@@ -97,7 +97,7 @@ under the License.
  
asm
asm
-3.2
+3.3.1
  
  
asm

Modified: 
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java
URL: 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java?rev=1127943&r1=1127942&r2=1127943&view=diff
==
--- 
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java
 (original)
+++ 
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java
 Thu May 26 14:30:55 2011
@@ -36,6 +36,7 @@ import java.util.regex.Matcher;
  import java.util.regex.Pattern;
  import java.util.zip.ZipException;

+import org.apache.maven.plugin.MojoExecutionException;
  import org.apache.maven.plugins.shade.relocation.Relocator;
  import org.apache.maven.plugins.shade.resource.ManifestResourceTransformer;
  import org.apache.maven.plugins.shade.resource.ResourceTransformer;
@@ -57,7 +58,7 @@ public class DefaultShader
  {

  public void shade( Set jars, File uberJar, List filters, List relocators, 
List resourceTransformers )
-throws IOException
+throws IOException, MojoExecutionException
  {
  Set resources = new HashSet();

@@ -241,7 +242,7 @@ public class DefaultShader

  private void addRemappedClass( RelocatorRemapper remapper, 
JarOutputStream jos, File jar, String name,
 InputStream is )
-throws IOException
+throws IOException, MojoExecutionException
  {
  if ( !remapper.hasRelocators() )
  {
@@ -264,7 +265,12 @@ public class DefaultShader

  ClassVisitor cv = new TempRemappingClassAdapter( cw, remapper );

-cr.accept( cv, ClassReader.EXPAND_FRAMES );
+try {
+   cr.accept( cv, ClassReader.EXPAND_FRAMES );
+} catch ( Throwable ise ) {
+   throw new MojoExecutionException ("Error in ASM processing class 
"
+   + name, ise );
+}

  byte[] renamedClass = cw.toByteArray();


Modified: 
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/Shader.java
URL: 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/Shader.java?rev=1127943&r1=1127942&r2=1127943&view=diff
==
--- 
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/Shader.java
 (original)
+++ 
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/Shader.java
 Thu May 26 14:30:55 2011
@@ -24,11 +24,26 @@ import java.io.IOException;
  import java.util.List;
  import java.util.Set;

-/** @author Jason van Zyl */
+import org.apache.maven.plugin.MojoExecutionException;
+
+/**
+ * Interface that defines the process of shading.
+ *
+ */
  public interface Shader
  {
  String ROLE = Shader.class.getName();

+/**
+ * Perform a shading operation.
+ * @param jars which jars
+ * @param uberJar output jar
+ * @param filters the filters
+ * @param relocators the relocators
+ * @param resourceTransformers the transformers
+ * @throws IOException for IO errors reading the thing
+ * @throws MojoExecutionException for anything else that goes wrong.
+ */
  void shade( Set jars, File uberJar, List filters, List relocators, List 
resourceTransformers )
-throws IOException;
+throws IOException, MojoExecutionException;
  }




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additi

Re: svn commit: r1127446 - in /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org: apache/maven/tck/ReproducesPlexusBug.java codehaus/plexus/util/IOUtilTest.java

Re: svn commit: r1127446 - in /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org: apache/maven/tck/ReproducesPlexusBug.java codehaus/plexus/util/IOUtilTest.java

Re: svn commit: r1127446 - in /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org: apache/maven/tck/ReproducesPlexusBug.java codehaus/plexus/util/IOUtilTest.java

Re: Handling of unrecognised version qualifiers

Re: Handling of unrecognised version qualifiers

Re: Handling of unrecognised version qualifiers

Re: Handling of unrecognised version qualifiers

Re: Handling of unrecognised version qualifiers

Re: Handling of unrecognised version qualifiers

Re: Handling of unrecognised version qualifiers

Interested in helping a research study on Eclipse?

Handling of unrecognised version qualifiers

Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java

Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java

Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java

Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java

Re: svn commit: r1127943 - in /maven/plugins/trunk/maven-shade-plugin: pom.xml src/main/java/org/apache/maven/plugins/shade/DefaultShader.java src/main/java/org/apache/maven/plugins/shade/Shader.java

17 matches

Site Navigation

Mail list logo

Footer information