Still - I have:
<repositories>
<repository>
<id>central</id>
<name>local-repository</name>
<layout>default</layout>
<url>http://build.corp.upromise.com/mavenrepository</url>
</repository>
<repository>
<id>lty-local</id>
<name>local-repository</name>
<url>file:thirdparty/repository</url>
</repository>
</repositories>
(I tried the reversing the order to no avail)
And I see -
E:\work\foxboro\model>mvn process-resources -P foxboro,model-base
[INFO] Scanning for projects...
[INFO]
----------------------------------------------------------------------------
[INFO] Building LtyModel
[INFO] task-segment: [process-resources]
[INFO]
----------------------------------------------------------------------------
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin-parent/2.0/maven-plugin-parent-2.0.pom
But I can see this:
http://build.corp.upromise.com/mavenrepository/org/apache/maven/plugins/maven-plugin-parent/2.0/maven-plugin-parent-2.0.pom
What am I doing wrong?
-----Original Message-----
From: Gunther Popp [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 08, 2006 7:29 AM
To: Maven Users List
Subject: Re: Internal (intranet) repositories
I´m by far any expert in the Maven source code, but as far as I
understand the implementation the repos
defined in your pom will be checked first. If your pom contains no repo
with the id "central", the default repos
defined in the "Super-POM" pom-4.0.0.xml will be searched next. Then all
repos defined in parent-poms
are considered.
Additionally, the repos are searched in the order you define them in
your pom.xml.
This should be true for resolving dependencies. I´m not sure, if
parent-poms and poms in general are resolved
the same way. So maybe this explains the problems described in the other
mails.
Gunther
> I think there's a basic misunderstanding here... As far as I know it,
> Maven *always* checks Central first. Even if you define another repo
> somewhere else.
>
> One way people prevent this is by setting up Maven proxy and then
> setting that proxy as a mirror of Central in their settings.xml file.
> Then instead of Central, it checks your proxy for the files, and if
> your proxy doesn't have it, it goes out to Central on its own and
> retrieves them, and then provides them to your Maven process.
>
> Wayne
>
> On 4/7/06, EJ Ciramella <[EMAIL PROTECTED]> wrote:
>
>> Yeah, something else is wrong then, I have apache running on another
>> machine and I have this:
>>
>> <repositories>
>> <repository>
>> <id>lty-local</id>
>> <name>local-repository</name>
>>
>> <url>http://build.corp.upromise.com/mavenrepository/</url>
>> </repository>
>> </repositories>
>>
>> And I STILL see it pulling from:
>>
>> Downloading:
>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-javadoc-plu
>> gin/2.0-beta-3/maven-javadoc-plugin-2.0-beta-3.pom
>> 1K downloaded
>>
>> I'm able to view this directory from firefox on a different machine (and
>> I tried with out that trailing / and no luck).
>>
>> How does this work folks? Nothing seems to work like the documentation
>> says it does (sorry, but this is getting really frustrating).
>>
>>
>> -----Original Message-----
>> From: dan tran [mailto:[EMAIL PROTECTED]
>> Sent: Friday, April 07, 2006 1:55 PM
>> To: Maven Users List
>> Subject: Re: Internal (intranet) repositories
>>
>> sounds like a bug to me, since I also try to reproduce it and mvn -X
>> does
>> not give any
>> indication that it references the configured repo before falling back to
>> to
>> the default ones
>>
>> Perhaps, you can create a small test case and submit a jira.
>>
>> -Dan
>>
>>
>>
>> On 4/7/06, EJ Ciramella <[EMAIL PROTECTED]> wrote:
>>
>>> Yup - and I like the idea, but haven't gotten that far yet.
>>>
>>> I'm still disappointed that the file:/// syntax doesn't work.
>>>
>>> I _just_ finished installing apache 2 and will try with http:// syntax
>>> now.
>>>
>>> When I'm satisfied with these developments, I'll move on to trying out
>>> the proxy part of this.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Rollo, Dan [mailto:[EMAIL PROTECTED]
>>> Sent: Friday, April 07, 2006 1:29 PM
>>> To: EJ Ciramella; Maven Users List
>>> Subject: RE: Internal (intranet) repositories
>>>
>>> Sorry if this have already been suggested and rejected, but: Have you
>>> considered using the maven-proxy to cache the ibiblio repo stuff on an
>>> internal machine?
>>>
>>> Dan
>>>
>>> -----Original Message-----
>>> From: EJ Ciramella [mailto:[EMAIL PROTECTED]
>>> Sent: Friday, April 07, 2006 10:32 AM
>>> To: Maven Users List
>>> Subject: RE: Internal (intranet) repositories
>>>
>>> Bummer about the potential for a bug. I know that the group working
>>>
>> on
>>
>>> maven 2 things have submitted a "repository" directory in the perforce
>>> project (kinda exactly the opposite to what this feature in maven is
>>> supposed to provide).
>>>
>>> But theirs works, but it seems to have to be a local copy.
>>>
>>> I'll try to bring up apache on that machine and see what happens. I
>>> kind of don't want to do this to an already complicated build
>>> environment though.
>>>
>>> -----Original Message-----
>>> From: Wayne Fay [mailto:[EMAIL PROTECTED]
>>> Sent: Friday, April 07, 2006 12:33 AM
>>> To: Maven Users List
>>> Subject: Re: Internal (intranet) repositories
>>>
>>> Can you perhaps load that repository on a local Apache server and
>>>
>> modify
>>
>>> the <repository> to reflect the HTTP repo, and see if it still fails
>>>
>> to
>>
>>> attempt to access the local repo?
>>>
>>> Might be a bug in how Maven deals with file:/// repos. I know most of
>>>
>> us
>>
>>> on the list are using simple HTTP repos, so you might have just
>>>
>> stumbled
>>
>>> into a new bug.
>>>
>>> Wayne
>>>
>>>
>>> On 4/6/06, EJ Ciramella <[EMAIL PROTECTED]> wrote:
>>>
>>>> Here is my pom file. The directory in the url below is a shared
>>>>
>>> folder
>>>
>>>> on a different machine.
>>>>
>>>> <project xmlns="http://maven.apache.org/POM/4.0.0";
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>> http://maven.apache.org/maven-v4_0_0.xsd";>
>>>> <modelVersion>4.0.0</modelVersion>
>>>> <groupId>com.ejstools.tool1</groupId>
>>>> <artifactId>tool1</artifactId>
>>>> <packaging>jar</packaging>
>>>> <version>1.0-SNAPSHOT</version>
>>>> <name>EJs Tools</name>
>>>> <url>http://build2.corp.upromise.com:8080</url>
>>>> <description>This project is simply here to lean about maven and
>>>> eventually will be used to build EJs Java tools.</description>
>>>> <repositories>
>>>> <repository>
>>>> <id>local</id>
>>>> <name>Upromise Maven Repository</name>
>>>> <url>file:///<servernamehere>/mavenrepository</url>
>>>> </repository>
>>>> </repositories>
>>>> <dependencies>
>>>> <dependency>
>>>> <groupId>junit</groupId>
>>>> <artifactId>junit</artifactId>
>>>> <version>3.8.1</version>
>>>> <scope>test</scope>
>>>> </dependency>
>>>> </dependencies>
>>>> <build>
>>>> <resources>
>>>> <resource>
>>>> <directory>src/main/resources</directory>
>>>> <filtering>true</filtering>
>>>> </resource>
>>>> </resources>
>>>> </build>
>>>> </project>
>>>>
>>>> -----Original Message-----
>>>> From: Wayne Fay [mailto:[EMAIL PROTECTED]
>>>> Sent: Thursday, April 06, 2006 6:12 PM
>>>> To: Maven Users List
>>>> Subject: Re: Internal (intranet) repositories
>>>>
>>>> Where exactly were you putting that repository section? In your
>>>> pom.xml? Or in another configuration file?
>>>>
>>>> Wayne
>>>>
>>>>
>>>> On 4/6/06, EJ Ciramella <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> None of this explains why it didn't use my repo and simply ignored
>>>>>
>>> it
>>>
>>>> completely.
>>>>
>>>>> This is the more important part of the puzzle.
>>>>>
>>>>>
>>>>
>> ---------------------------------------------------------------------
>>
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>> --------------------------------------------------
>>> This e-mail and any files transmitted with it may contain privileged
>>>
>> or
>>
>>> confidential information.
>>> It is solely for use by the individual for whom it is intended, even
>>>
>> if
>>
>>> addressed incorrectly.
>>> If you received this e-mail in error, please notify the sender; do not
>>> disclose, copy, distribute,
>>> or take any action in reliance on the contents of this information;
>>>
>> and
>>
>>> delete it from
>>> your system. Any other use of this e-mail is prohibited.
>>>
>>> Thank you for your compliance.
>>> --------------------------------------------------
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
