AW: [mvn-3] jar files causing problems

2012-07-04 Thread Stadelmann Josef
Wayne

100%-nail-hit! how did you know that 
xalan-2.7.1.jar  xalan-2.7.1.pom
and other stuff . . .
when downloaded as maven-artifact 
from the repository, comes down with 
such a bunch of HTML rubbish in it?

Who deposits xalan-2.7.1.jar é all?

Before I deleted the mirrors in my 
settings.xml, there was local company
repository mirror defined. This mirror
acts as proxy. And it provided me the
same rubbish. So I removed this mirror.

So the rubbish is located somehow central 
and I wonder if I am the only one having 
this types of troubles. 

Below my settings.xml

Josef

?xml version=1.0 encoding=ISO-8859-1?
settings
  localRepository/dka3/stadelma/.m2/repository/localRepository
  proxies
   proxy
   activetrue/active
   protocolhttp/protocol
   hostproxyserver.ch/host
   port8080/port
   usernameC770817/username
   passwordorbxorbx/password
   nonProxyHosts*.wgrintra.net/nonProxyHosts
   iddefault/id
   /proxy
  /proxies
  mirrors
  /mirrors
/settings

I am going to move now, from my local PC m2/repository,
the failing artifacts into the OpenVMS m2/repository. 





-Ursprüngliche Nachricht-
Von: Wayne Fay [mailto:wayne...@gmail.com] 
Gesendet: Dienstag, 3. Juli 2012 18:28
An: Maven Users List
Betreff: Re: [mvn-3] jar files causing problems

 [WARNING] The POM for org.apache.xalan:xalan:jar:2.7.1 is invalid,
 transitive dependencies (if any) will not be available, enable debug logging
 for more details

Cat the jar file or open it in vi etc. I bet you see an HTTP 503 or a
404 or something other HTML in there instead of the proper binary jar
bits.

Most likely you have a problem in your settings.xml. Ideally you
should set up a proper local Maven Repository Manager (Nexus, Archiva,
Artifactory, etc) and leverage it for your jar access.

Wayne

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



AW: [mvn-3] jar files causing problems

2012-07-04 Thread Stadelmann Josef
Ok Wayne
or anybody else

we have a corporate repository acting as a proxy to central !
fine - this safes you a lot bandwidth and us time.

But what shall I do if I get same rubbish from our repository as well as from 
central when I ask for pom / jar? for an artifact?

I just cleared out my m2/repository and have all downloaded for a small axis2 
project from our repository at axa-winterthur.

As xalan jars and pom's and others are in error, just rubbish HTML in it, I 
expected our axa-winterthur repository is bad;
Hence I took out from settings.xml the mirror to our repository. Sso I work 
without any mirror at the moment. 

But bad luck, our repository is really just a mirror of central and contains 
the same rubbish for xalan-2.7.1.pom and jar 

- HTML in a POM and in the jar's 

while my $ mvn install 
takes place I observer the following

[INFO] 
[INFO] Building SpezplaService 1.6.1
[INFO] 
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-deploy-plugin/maven-metadata.xml
Downloaded: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-deploy-plugin/maven-metadata.xml
 (614 B at 2.2 KB/sec)
Downloading: 
http://repo1.maven.org/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom
Downloading: 
http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom
[WARNING] Checksum validation failed, expected !DOCTYPE but is 
2b52583a26dc455eebec16f29ab9480344f2c5a4 for 
http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom
[WARNING] Checksum validation failed, expected !DOCTYPE but is 
2b52583a26dc455eebec16f29ab9480344f2c5a4 for 
http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom


let's take 1 by 1
Downloading: 
http://shibboleth.internet2.edu/downloads/maven2/org/apache/xalan/xalan/2.7.1/xalan-2.7.1.pom

taking this URL into the browser brings you to the shibboleth site and it seems 
that the expected repository has been relocated to somewhere else. I think, 
maven cannot handle this bad redirection but sucks up the HTML rubbish instead 
from this site for the artifacts wanted.

What I do not understand is, why xalan-* and a few other artifacts must come 
down from http://shibboleth.internet2.edu/downloads/maven2/org/apache/

Where can I prevent this? can I? can I black-list proactively the 
mirrorurlhttp://shibboleth.internet2.edu/downloads/maven2 ?

can someone more fluent with that confirm or explain me what happens?

any help welcome

Josef
 


-Ursprüngliche Nachricht-
Von: Wayne Fay [mailto:wayne...@gmail.com] 
Gesendet: Dienstag, 3. Juli 2012 18:28
An: Maven Users List
Betreff: Re: [mvn-3] jar files causing problems

 [WARNING] The POM for org.apache.xalan:xalan:jar:2.7.1 is invalid,
 transitive dependencies (if any) will not be available, enable debug logging
 for more details

Cat the jar file or open it in vi etc. I bet you see an HTTP 503 or a
404 or something other HTML in there instead of the proper binary jar
bits.

Most likely you have a problem in your settings.xml. Ideally you
should set up a proper local Maven Repository Manager (Nexus, Archiva,
Artifactory, etc) and leverage it for your jar access.

Wayne

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



Re: AW: [mvn-3] jar files causing problems

2012-07-04 Thread Jörg Schaible
Hi Josef,

Stadelmann Josef wrote:

 Ok Wayne
 or anybody else

[snip]

 What I do not understand is, why xalan-* and a few other artifacts must
 come down from
 http://shibboleth.internet2.edu/downloads/maven2/org/apache/
 
 Where can I prevent this? can I? can I black-list proactively the
 mirrorurlhttp://shibboleth.internet2.edu/downloads/maven2 ?
 
 can someone more fluent with that confirm or explain me what happens?

M2 has the unfortunate habbit to take repositories into account that are 
somewhere declared in one of the POMs that are part of your build (i.e. also 
those in transitive 3rd party POMs). That's the reason why it is discouraged 
to declare repositories in POMs. Therefore your mirror declaration should 
have a mirrorOf*/mirrorOf entry to mask all those additional injected 
repos. IIRC M3 behaves better, but uses such repos under some circumstances 
also.

Regards,
Jörg


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