Re: svn commit: r677112 - /maven/components/branches/maven-2.0.10-RC/pom.xml

[brettporter]

I think 1.0.1 was what would have been used in 2.0.9 (it looks like no  
version was given to me though).

Any idea what is wrong in 1.1+?

- Brett

On 16/07/2008, at 10:02 AM, jdcasey@... wrote:

> Author: jdcasey
> Date: Tue Jul 15 17:02:42 2008
> New Revision: 677112
>
> URL: http://svn.apache.org/viewvc?rev=677112&view=rev
> Log:
> rolling back to 1.0 of the shade plugin to fix the MNG-3503  
> integration test.
>
> Modified:
>    maven/components/branches/maven-2.0.10-RC/pom.xml
>
> Modified: maven/components/branches/maven-2.0.10-RC/pom.xml
> URL: http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.10-RC/pom.xml?rev=677112&r1=677111&r2=677112&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- maven/components/branches/maven-2.0.10-RC/pom.xml (original)
> +++ maven/components/branches/maven-2.0.10-RC/pom.xml Tue Jul 15  
> 17:02:42 2008
> @@ -134,7 +134,7 @@
>         </plugin>
>         <plugin>
>           <artifactId>maven-shade-plugin</artifactId>
> -          <version>1.1</version>
> +          <version>1.0</version>
>         </plugin>
>         <plugin>
>           <artifactId>maven-surefire-plugin</artifactId>
>
>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


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

[Benjamin Bentmann]

Brett Porter wrote:

> Any idea what is wrong in 1.1+?

I did some major changes in the relocator component for MSHADE-28 which according to the plugin's release history is quite the only change that might be related. Maybe I managed to get something wrong in there. Will try to reproduce the issue John mentioned and check how it relates to my change.


Benjamin

[John Casey-5]

For what it's worth, this works fine in 1.2-SNAPSHOT, but I can't
release with that plugin version in there.

Let's try to get that release going...

-john

Benjamin Bentmann wrote:

> Brett Porter wrote:
>
>> Any idea what is wrong in 1.1+?
>
> I did some major changes in the relocator component for MSHADE-28 which
> according to the plugin's release history is quite the only change that
> might be related. Maybe I managed to get something wrong in there. Will try
> to reproduce the issue John mentioned and check how it relates to my change.
>
>
> Benjamin

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

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

[Benjamin Bentmann]

John Casey wrote:

> For what it's worth, this works fine in 1.2-SNAPSHOT

Are you sure? I have identified a regression in 1.1 over 1.0.1 that
really seems to arise from my changes in SimpleRelocator. I.e. I
boostrapped Maven 2.0.x once with Shade 1.0.1 (passed ITs) and once with
1.1 (failed mng3503), decompiled the resulting uber JARs and diffed
them. I got exactly one single line change in DefaultPluginManager where
it reads

   child.getContainerRealm().importFrom("plexus.core",
     "hidden.org.codehaus.plexus.util.xml.pull");

instead of

   child.getContainerRealm().importFrom("plexus.core",
     "org.codehaus.plexus.util.xml.pull");

i.e. a package excluded from relocation was renamed. So far, I managed
to create an unit test and am now in the progress of fixing it.


Benjamin

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

[John Casey-5]

Sounds good. All I can tell you is that I've been doing quite a bit of
testing using 2.0.10-snapshot builds that had 1.2-snapshot configured
for use in the apache-maven project build (the one that assembles the
final distro), and I haven't noticed a problem with it yet.

I'll change my local configuration back to using 1.2-SNAPSHOT and see if
I can tease out a problem.

Benjamin Bentmann wrote:

> John Casey wrote:
>
>> For what it's worth, this works fine in 1.2-SNAPSHOT
>
> Are you sure? I have identified a regression in 1.1 over 1.0.1 that
> really seems to arise from my changes in SimpleRelocator. I.e. I
> boostrapped Maven 2.0.x once with Shade 1.0.1 (passed ITs) and once with
> 1.1 (failed mng3503), decompiled the resulting uber JARs and diffed
> them. I got exactly one single line change in DefaultPluginManager where
> it reads
>
>   child.getContainerRealm().importFrom("plexus.core",
>     "hidden.org.codehaus.plexus.util.xml.pull");
>
> instead of
>
>   child.getContainerRealm().importFrom("plexus.core",
>     "org.codehaus.plexus.util.xml.pull");
>
> i.e. a package excluded from relocation was renamed. So far, I managed
> to create an unit test and am now in the progress of fixing it.
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

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

[Benjamin Bentmann]

Benjamin Bentmann wrote:

> I did some major changes in the relocator component for MSHADE-28 which
> according to the plugin's release history is quite the only change that
> might be related. Maybe I managed to get something wrong in there.

OK, I called that MSHADE-38 and have fixed the relocator to work as in
version 1.0.x.

There is some subtle behavior of the relocator that makes me wonder
whether this is intended. Consider a Shade configuration like this:

   <relocation>
     <pattern>org.util</pattern>
     <excludes>
       <exclude>org.util.noreloc.*</exclude>
     </excludes>
   </relocation>

the notation ".*" at the end of an exclude will also prevent the plugin
from renaming the package name itself, i.e. the string literal
"org.util.noreloc" in bytecode will stay as is instead of becoming
"hidden.org.util.noreloc".

Now imagine rather than using wildcards we would explicitly list up all
the classes to be excluded:

   <relocation>
     <pattern>org.util</pattern>
     <excludes>
       <exclude>org.util.noreloc.A</exclude>
       ... all the other classes from this package ...
       <exclude>org.util.noreloc.Z</exclude>
     </excludes>
   </relocation>

In terms of classes, both configurations describe the same set and
naively one would expect the plugin to behave just as before (at least I
did). However, this time all occurrences of the string
"org.util.noreloc" will be changed to "hidden.org.util.noreloc". This
will, for instance, wreck havoc on the package imports used to link
Classworld's ClassRealms together.

Should we maybe change the relocator to always leave the package names
of excluded classes untouched? Algorithmically, this would mean to have
an implicit exclusion of the form "package" for every exclude
"package.SomeClass" from the plugin configuration.


Benjamin

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