[jira] Commented: (WAGON-314) Permament move (error 301) not handled properly by Lightweight HTTP Wagon

[Wonne Keysers (JIRA)]

[ 
http://jira.codehaus.org/browse/WAGON-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259753#action_259753
 ] 

Wonne Keysers commented on WAGON-314:
-

I can confirm that only version 2.2.0 handles permanent redirects properly.
I would realy recommend including a fix in Maven 3 !

> Permament move (error 301) not handled properly by Lightweight HTTP Wagon
> -
>
> Key: WAGON-314
> URL: http://jira.codehaus.org/browse/WAGON-314
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http-lightweight
>Affects Versions: 1.0-beta-6
>Reporter: Grzegorz Slowikowski
>Priority: Minor
> Fix For: 1.0-beta-8
>
> Attachments: mng-4428.patch
>
>
> Artifact cannot be downloaded by http-lightweight-wagon used (as default) in 
> all Maven versions except 2.2.0, which uses http-wagon by default.
> Instead of pom and jar files html files appear in the local repo with content 
> like:
> 
> 
> 301 Moved Permanently
> 
> Moved Permanently
> The document has moved  href="http://download.java.net/maven/2/org/codehaus/castor/castor-xml-schema/1.2/castor-xml-schema-1.2.pom";>here.
> 
> Apache Server at maven2-repository.dev.java.net Port 443
> 
> Only Maven 2.2.0 handles 301 properly.
> By the way, I haven't expected such Apache configuration (permament move) in 
> central Maven repo.
> As you can see this is not handled properly by almost all versions of Maven.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR

[Wonne Keysers (JIRA)]

[ http://jira.codehaus.org/browse/MWAR-9?page=comments#action_72277 ] 

Wonne Keysers commented on MWAR-9:
--

Compile time dependencies can be excluded from the WEB-INF/lib by using the 
true flag.  However, this currently does not work 
recursively.

For example: if the war has a dependency on A.jar, but A.jar itself s dependant 
from B.jar, putting the A-dependency optional excludes it from the war (yet it 
includes it in the manifest), but B.jar is still included in the WEB-INF/lib.

If the optional flag would be working recursively, I think the solution would 
be complete?

> WAR plugin should support minimal WARs for inclusion within an EAR
> --
>
> Key: MWAR-9
> URL: http://jira.codehaus.org/browse/MWAR-9
> Project: Maven 2.x War Plugin
>  Issue Type: Improvement
>Reporter: Mike Perham
>
> I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my 
> deps.  This is fine for a default but maven should also support "skeleton" 
> WARs which will be packaged within an EAR.  We have EARs which package 3-4 
> WARs each and to have the deps duplicated within each WAR means we cannot 
> have shared data (since the classes are loaded within each WAR's classloader, 
> rather than by the parent EAR's classloader).  It also means 80MB EARs!  :-)
> It seems like two things need to happen:
> 1) Add a "skeleton" flag which prevents copying any dependencies to 
> WEB-INF/lib.
> 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which 
> lists the relative locations of the dependencies within the parent EAR.
> Fabrice has basically the same idea written down here.  Starting with "- for 
> a War..." : 
> http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira