Re: Tracking down a

[Anders Hammar]

And by "that id" I mean 'com.springsource.repository.bundles.release'

/Anders (mobile)
On Dec 11, 2015 15:45, "Anders Hammar"  wrote:

> Most likely it is in one of the spring poms. Can't you search for that id
> in all poms in your local Maven repo?
>
> /Anders (mobile)
> On Dec 11, 2015 15:38, "Benson Margulies"  wrote:
>
>> I can't build Apache CXF when my normal Nexus mirror is in place; it
>> fails to find:
>>
>> org.springframework:org.springframework.context:2.5.6.SEC01
>>
>> I can if I turn off my mirrors. So, I'm trying to determine what repo
>> I need to add to my Nexus or exclude from my mirrors.
>>
>> Mirrorless, I see
>>
>> ➜ 2.5.6.SEC01 cat _remote.repositories
>> #NOTE: This is an Aether internal implementation file, its format can
>> be changed without prior notice.
>> #Fri Dec 11 08:13:18 EST 2015
>>
>> org.springframework.context-2.5.6.SEC01.jar>com.springsource.repository.bundles.release=
>>
>> org.springframework.context-2.5.6.SEC01.pom>com.springsource.repository.bundles.release=
>>
>> How do I get from here to a URL /  declaration?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Tracking down a

[Benson Margulies]

I can't build Apache CXF when my normal Nexus mirror is in place; it
fails to find:

org.springframework:org.springframework.context:2.5.6.SEC01

I can if I turn off my mirrors. So, I'm trying to determine what repo
I need to add to my Nexus or exclude from my mirrors.

Mirrorless, I see

➜ 2.5.6.SEC01 cat _remote.repositories
#NOTE: This is an Aether internal implementation file, its format can
be changed without prior notice.
#Fri Dec 11 08:13:18 EST 2015
org.springframework.context-2.5.6.SEC01.jar>com.springsource.repository.bundles.release=
org.springframework.context-2.5.6.SEC01.pom>com.springsource.repository.bundles.release=

How do I get from here to a URL /  declaration?

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

Re: Tracking down a

[Anders Hammar]

Most likely it is in one of the spring poms. Can't you search for that id
in all poms in your local Maven repo?

/Anders (mobile)
On Dec 11, 2015 15:38, "Benson Margulies"  wrote:

> I can't build Apache CXF when my normal Nexus mirror is in place; it
> fails to find:
>
> org.springframework:org.springframework.context:2.5.6.SEC01
>
> I can if I turn off my mirrors. So, I'm trying to determine what repo
> I need to add to my Nexus or exclude from my mirrors.
>
> Mirrorless, I see
>
> ➜ 2.5.6.SEC01 cat _remote.repositories
> #NOTE: This is an Aether internal implementation file, its format can
> be changed without prior notice.
> #Fri Dec 11 08:13:18 EST 2015
>
> org.springframework.context-2.5.6.SEC01.jar>com.springsource.repository.bundles.release=
>
> org.springframework.context-2.5.6.SEC01.pom>com.springsource.repository.bundles.release=
>
> How do I get from here to a URL /  declaration?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Tracking down a

[Benson Margulies]

And indeed that's the ID to add to the mirror ! list!

On Fri, Dec 11, 2015 at 9:47 AM, Anders Hammar  wrote:
> And by "that id" I mean 'com.springsource.repository.bundles.release'
>
> /Anders (mobile)
> On Dec 11, 2015 15:45, "Anders Hammar"  wrote:
>
>> Most likely it is in one of the spring poms. Can't you search for that id
>> in all poms in your local Maven repo?
>>
>> /Anders (mobile)
>> On Dec 11, 2015 15:38, "Benson Margulies"  wrote:
>>
>>> I can't build Apache CXF when my normal Nexus mirror is in place; it
>>> fails to find:
>>>
>>> org.springframework:org.springframework.context:2.5.6.SEC01
>>>
>>> I can if I turn off my mirrors. So, I'm trying to determine what repo
>>> I need to add to my Nexus or exclude from my mirrors.
>>>
>>> Mirrorless, I see
>>>
>>> ➜ 2.5.6.SEC01 cat _remote.repositories
>>> #NOTE: This is an Aether internal implementation file, its format can
>>> be changed without prior notice.
>>> #Fri Dec 11 08:13:18 EST 2015
>>>
>>> org.springframework.context-2.5.6.SEC01.jar>com.springsource.repository.bundles.release=
>>>
>>> org.springframework.context-2.5.6.SEC01.pom>com.springsource.repository.bundles.release=
>>>
>>> How do I get from here to a URL /  declaration?
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>

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

Re: Tracking down a

[ecki]

It should work with the dependency plugin:

https://maven.apache.org/plugins/maven-dependency-plugin/list-repositories-mojo.html

Not exactly scientific, but the fastest method I use is to delete the file and 
run the mvn command again, it will log the download URL. 

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Benson Margulies <bimargul...@gmail.com>
To: Maven Users List <users@maven.apache.org>
Sent: Fr., 11 Dez. 2015 15:38
Subject: Tracking down a 

I can't build Apache CXF when my normal Nexus mirror is in place; it
fails to find:

org.springframework:org.springframework.context:2.5.6.SEC01

I can if I turn off my mirrors. So, I'm trying to determine what repo
I need to add to my Nexus or exclude from my mirrors.

Mirrorless, I see

➜ 2.5.6.SEC01 cat _remote.repositories
#NOTE: This is an Aether internal implementation file, its format can
be changed without prior notice.
#Fri Dec 11 08:13:18 EST 2015
org.springframework.context-2.5.6.SEC01.jar>com.springsource.repository.bundles.release=
org.springframework.context-2.5.6.SEC01.pom>com.springsource.repository.bundles.release=

How do I get from here to a URL /  declaration?

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


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

Tracking down a dependency mystery

[Benson Margulies]

I just created a project with an interesting dependency situation: my
existing code uses jetty 7, while hector from cassandra-land uses
jetty 6.

This should be fine; the group IDs are different.

However, my build fails as follows below. The actual cassandra-all pom
in my local repo, on the other hand, says:

dependency
  groupIdorg.mortbay.jetty/groupId
  artifactIdjetty/artifactId
  version6.1.21/version
/dependency


I expected to find a property reference in here and that the problem
was that two poms were accidently sharing something like
${jetty.version}. But, no. Cassandra's dep is as above, so I cannot
explain how I get the error below.

This is with 2.2.0. Anybody got a clue?

1) org.mortbay.jetty:jetty:jar:7.2.0.v20101020

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.mortbay.jetty
-DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there:
  mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
-DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
1) com.basistech.jug:dcs-cassandra-store:jar:4-SNAPSHOT
2) org.apache.cassandra:cassandra-all:jar:0.7.2
3) org.mortbay.jetty:jetty:jar:7.2.0.v20101020

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

Re: Tracking down a dependency mystery

[Benson Margulies]

Running with m3, it still fails, and I see

[DEBUG]   org.mortbay.jetty:jetty:jar:7.2.0.v20101020:compile
(version managed from 6.1.21)

in the log. So I need to figure out where this 'management' is coming from.

On Fri, Feb 18, 2011 at 10:25 AM, Benson Margulies
bimargul...@gmail.com wrote:
 I just created a project with an interesting dependency situation: my
 existing code uses jetty 7, while hector from cassandra-land uses
 jetty 6.

 This should be fine; the group IDs are different.

 However, my build fails as follows below. The actual cassandra-all pom
 in my local repo, on the other hand, says:

    dependency
      groupIdorg.mortbay.jetty/groupId
      artifactIdjetty/artifactId
      version6.1.21/version
    /dependency


 I expected to find a property reference in here and that the problem
 was that two poms were accidently sharing something like
 ${jetty.version}. But, no. Cassandra's dep is as above, so I cannot
 explain how I get the error below.

 This is with 2.2.0. Anybody got a clue?

 1) org.mortbay.jetty:jetty:jar:7.2.0.v20101020

  Try downloading the file manually from the project website.

  Then, install it using the command:
      mvn install:install-file -DgroupId=org.mortbay.jetty
 -DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
 -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there:
      mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
 -DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
        1) com.basistech.jug:dcs-cassandra-store:jar:4-SNAPSHOT
        2) org.apache.cassandra:cassandra-all:jar:0.7.2
        3) org.mortbay.jetty:jetty:jar:7.2.0.v20101020


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

Re: Tracking down a dependency mystery

[Benson Margulies]

OK, mystery solved. I found the relevant dependencyManagement
statement in a distant parent, leftover from long ago.

On Fri, Feb 18, 2011 at 10:27 AM, Benson Margulies
bimargul...@gmail.com wrote:
 Running with m3, it still fails, and I see

 [DEBUG]       org.mortbay.jetty:jetty:jar:7.2.0.v20101020:compile
 (version managed from 6.1.21)

 in the log. So I need to figure out where this 'management' is coming from.

 On Fri, Feb 18, 2011 at 10:25 AM, Benson Margulies
 bimargul...@gmail.com wrote:
 I just created a project with an interesting dependency situation: my
 existing code uses jetty 7, while hector from cassandra-land uses
 jetty 6.

 This should be fine; the group IDs are different.

 However, my build fails as follows below. The actual cassandra-all pom
 in my local repo, on the other hand, says:

    dependency
      groupIdorg.mortbay.jetty/groupId
      artifactIdjetty/artifactId
      version6.1.21/version
    /dependency


 I expected to find a property reference in here and that the problem
 was that two poms were accidently sharing something like
 ${jetty.version}. But, no. Cassandra's dep is as above, so I cannot
 explain how I get the error below.

 This is with 2.2.0. Anybody got a clue?

 1) org.mortbay.jetty:jetty:jar:7.2.0.v20101020

  Try downloading the file manually from the project website.

  Then, install it using the command:
      mvn install:install-file -DgroupId=org.mortbay.jetty
 -DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
 -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file 
 there:
      mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
 -DartifactId=jetty -Dversion=7.2.0.v20101020 -Dpackaging=jar
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency:
        1) com.basistech.jug:dcs-cassandra-store:jar:4-SNAPSHOT
        2) org.apache.cassandra:cassandra-all:jar:0.7.2
        3) org.mortbay.jetty:jetty:jar:7.2.0.v20101020



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

Re: Tracking down a dependency mystery

[Barrie Treloar]

On Sat, Feb 19, 2011 at 2:01 AM, Benson Margulies bimargul...@gmail.comwrote:

 OK, mystery solved. I found the relevant dependencyManagement
 statement in a distant parent, leftover from long ago.


Can you see if there is already a bug filed that says we should do more to
help the user track these down?
If not, can you raise it.

Re: Tracking down a stray dependency on a plugin?

[Jörg Schaible]

Benson Margulies wrote:

 mvn -X shows me a dependency on a plugin that I can't explain. This is
 a plugin which, on its, has very few dependencies, and depends on
 explicit dependency declarations. -X is showing me something that
 should not be in there. dependency:tree doesn't look at plugins. Is
 there something else which will give me a clue?

Use mvn dependency:tree -f pom-of-plugin.xml

- Jörg


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

Re: Tracking down a stray dependency on a plugin?

[Benson Margulies]

Thanks.

The case at hand is the -X message for:

[DEBUG] Adding managed dependencies for com.basistech:maven-rex2009task-plugin
[DEBUG]   com.basistech:common:jar:4
[DEBUG]   com.basistech:ap-segmentation-features:jar:9-SNAPSHOT
[DEBUG]   com.basistech.rse:rlp-breaks:jar:1.4.99.5-SNAPSHOT

One of these is not visible in the plugin's dependency:tree. In fact,
if I delete the mysterious item from the local repo, and run
--offline, I get no error message. I don't know if it's a logging bug
or what.



On Sat, May 22, 2010 at 6:57 AM, Jörg Schaible joerg.schai...@gmx.de wrote:
 Benson Margulies wrote:

 mvn -X shows me a dependency on a plugin that I can't explain. This is
 a plugin which, on its, has very few dependencies, and depends on
 explicit dependency declarations. -X is showing me something that
 should not be in there. dependency:tree doesn't look at plugins. Is
 there something else which will give me a clue?

 Use mvn dependency:tree -f pom-of-plugin.xml

 - Jörg


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



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

Tracking down a stray dependency on a plugin?

[Benson Margulies]

mvn -X shows me a dependency on a plugin that I can't explain. This is
a plugin which, on its, has very few dependencies, and depends on
explicit dependency declarations. -X is showing me something that
should not be in there. dependency:tree doesn't look at plugins. Is
there something else which will give me a clue?

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

Re: tracking down jetty/tomcat dependencies

[Benson Margulies]

I'm still wishing that someone could help me figure out just what is on the
classpath inside of tomcat:run.

To a first approximation, jetty:run and tomcat:run had the same problem.
However, I was a able to cure it in jetty and not in tomcat. It LOOKS as if
tomcat is depending on an old version of Xalan.


On Fri, Oct 30, 2009 at 5:16 AM, Benson Margulies bimargul...@gmail.comwrote:

 I wrote it up on the mojo user list once I got a clearer picture, but here
 goes again.

 The code calls DocumentBuilderFactory and SchemaFactory to parse an XML
 file to DOM with schema validation. Run in the plugins, it fails with an
 impossible validation error (a claim that a valid attribute is invalid). The
 backtrace shows a combination of xerces and JDK classes. I have xerces in
 the webapp's class path.

 The same code works fine, with or without xerces, run as a pojo or a junit
 test.

 If I try to use 100% Xerces by referring to their implementation classes
 (DocumentBuilderImpl and XMLSchemaFactory) it still fails in the plugins.

 The problem goes away if I use the new JAXP 1.4 APIs to force the use of
 Xerces.

 I reason as follows: in a live copy of tomcat or jetty, the 'system'
 classpath is whatever jars are sitting in the containers system library
 directory. When these plugins deploy a webapp, they don't have a system
 library directory. They instead have whatever classpath maven invokes them
 with, based on their declared dependencies and the transitive closure that
 reaches into plexus and such. There could easily be some ancient xml-apis
 jar in there, or some other source of interference, which I am not
 preempting in my webapp.

 If dependency:tree worked for a plugin classpath, then I might be able to
 figure out the real source of the problem and fix it by tinkering with
 dependencies on the plugin. But I can't figure out how to get a full tree
 for maven-tomcat-plugin (e.g.).


 On Thu, Oct 29, 2009 at 10:32 PM, Brett Randall javabr...@gmail.comwrote:

 On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies bimargul...@gmail.com
 wrote:

  I've got code that works fine when run as a pojo and fails when run in a
  webapp, either via tomcat:run or jetty:run. I suspect, because I can't
  think
  of anything else, that there is detritus in the 'system' classpaths of
  these
  containers. However, mvn dependency:tree does not tell me much about the
  maven-jetty-plugin. Neither does dependency:resolve-plugins.
 
  Is there some way to get a clearer view of this question?
 

 What is the mode of failure?

 Brett

Re: tracking down jetty/tomcat dependencies

[Sony Antony]

( IIRC xalan is used for xslt transformation. xerces is teh parser )

I think the war file is supposed to be self sufficient - meaning it should
contain all teh jar files/libraries application needs.
This is is what maven's war packaging does - it puts all the dependency
artifacts inside WEB-INF/lib directory of the war file.
( make sure none of the dependencies are given scopeprovidedscope at teh
war's pom.xml. Did you check this ?

most of the app servers I know load the library from WEB-INF/lib first and
falls back on teh app server's classpath only if the class is not found
there.


ideally I would not want any of the classpath components inherited by teh
running container ( jetty/tomcat )
But I dont think there is a way to turn off this inheritance

--sony




On Tue, Nov 3, 2009 at 5:53 AM, Benson Margulies bimargul...@gmail.comwrote:

 I'm still wishing that someone could help me figure out just what is on the
 classpath inside of tomcat:run.

 To a first approximation, jetty:run and tomcat:run had the same problem.
 However, I was a able to cure it in jetty and not in tomcat. It LOOKS as if
 tomcat is depending on an old version of Xalan.


 On Fri, Oct 30, 2009 at 5:16 AM, Benson Margulies bimargul...@gmail.com
 wrote:

  I wrote it up on the mojo user list once I got a clearer picture, but
 here
  goes again.
 
  The code calls DocumentBuilderFactory and SchemaFactory to parse an XML
  file to DOM with schema validation. Run in the plugins, it fails with an
  impossible validation error (a claim that a valid attribute is invalid).
 The
  backtrace shows a combination of xerces and JDK classes. I have xerces in
  the webapp's class path.
 
  The same code works fine, with or without xerces, run as a pojo or a
 junit
  test.
 
  If I try to use 100% Xerces by referring to their implementation classes
  (DocumentBuilderImpl and XMLSchemaFactory) it still fails in the plugins.
 
  The problem goes away if I use the new JAXP 1.4 APIs to force the use of
  Xerces.
 
  I reason as follows: in a live copy of tomcat or jetty, the 'system'
  classpath is whatever jars are sitting in the containers system library
  directory. When these plugins deploy a webapp, they don't have a system
  library directory. They instead have whatever classpath maven invokes
 them
  with, based on their declared dependencies and the transitive closure
 that
  reaches into plexus and such. There could easily be some ancient xml-apis
  jar in there, or some other source of interference, which I am not
  preempting in my webapp.
 
  If dependency:tree worked for a plugin classpath, then I might be able to
  figure out the real source of the problem and fix it by tinkering with
  dependencies on the plugin. But I can't figure out how to get a full tree
  for maven-tomcat-plugin (e.g.).
 
 
  On Thu, Oct 29, 2009 at 10:32 PM, Brett Randall javabr...@gmail.com
 wrote:
 
  On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies 
 bimargul...@gmail.com
  wrote:
 
   I've got code that works fine when run as a pojo and fails when run in
 a
   webapp, either via tomcat:run or jetty:run. I suspect, because I can't
   think
   of anything else, that there is detritus in the 'system' classpaths of
   these
   containers. However, mvn dependency:tree does not tell me much about
 the
   maven-jetty-plugin. Neither does dependency:resolve-plugins.
  
   Is there some way to get a clearer view of this question?
  
 
  What is the mode of failure?
 
  Brett
 
 
 

Re: tracking down jetty/tomcat dependencies

[Benson Margulies]

I wrote it up on the mojo user list once I got a clearer picture, but here
goes again.

The code calls DocumentBuilderFactory and SchemaFactory to parse an XML file
to DOM with schema validation. Run in the plugins, it fails with an
impossible validation error (a claim that a valid attribute is invalid). The
backtrace shows a combination of xerces and JDK classes. I have xerces in
the webapp's class path.

The same code works fine, with or without xerces, run as a pojo or a junit
test.

If I try to use 100% Xerces by referring to their implementation classes
(DocumentBuilderImpl and XMLSchemaFactory) it still fails in the plugins.

The problem goes away if I use the new JAXP 1.4 APIs to force the use of
Xerces.

I reason as follows: in a live copy of tomcat or jetty, the 'system'
classpath is whatever jars are sitting in the containers system library
directory. When these plugins deploy a webapp, they don't have a system
library directory. They instead have whatever classpath maven invokes them
with, based on their declared dependencies and the transitive closure that
reaches into plexus and such. There could easily be some ancient xml-apis
jar in there, or some other source of interference, which I am not
preempting in my webapp.

If dependency:tree worked for a plugin classpath, then I might be able to
figure out the real source of the problem and fix it by tinkering with
dependencies on the plugin. But I can't figure out how to get a full tree
for maven-tomcat-plugin (e.g.).

On Thu, Oct 29, 2009 at 10:32 PM, Brett Randall javabr...@gmail.com wrote:

 On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies bimargul...@gmail.com
 wrote:

  I've got code that works fine when run as a pojo and fails when run in a
  webapp, either via tomcat:run or jetty:run. I suspect, because I can't
  think
  of anything else, that there is detritus in the 'system' classpaths of
  these
  containers. However, mvn dependency:tree does not tell me much about the
  maven-jetty-plugin. Neither does dependency:resolve-plugins.
 
  Is there some way to get a clearer view of this question?
 

 What is the mode of failure?

 Brett

tracking down jetty/tomcat dependencies

[Benson Margulies]

I've got code that works fine when run as a pojo and fails when run in a
webapp, either via tomcat:run or jetty:run. I suspect, because I can't think
of anything else, that there is detritus in the 'system' classpaths of these
containers. However, mvn dependency:tree does not tell me much about the
maven-jetty-plugin. Neither does dependency:resolve-plugins.

Is there some way to get a clearer view of this question?

Re: tracking down jetty/tomcat dependencies

[Brett Randall]

On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies bimargul...@gmail.comwrote:

 I've got code that works fine when run as a pojo and fails when run in a
 webapp, either via tomcat:run or jetty:run. I suspect, because I can't
 think
 of anything else, that there is detritus in the 'system' classpaths of
 these
 containers. However, mvn dependency:tree does not tell me much about the
 maven-jetty-plugin. Neither does dependency:resolve-plugins.

 Is there some way to get a clearer view of this question?


What is the mode of failure?

Brett