maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gunther Popp <Gunther.P...@web.de>
Subject Re: use of proxies
Date Fri, 14 Apr 2006 09:01:54 GMT
Well, Hacks are sometimes the way to go ...  :-) Maybe a future Maven 
version will provide some "official" option to replace the standard repo.

Gunther

dan tran schrieb:
> Just want to confirm, Gunther's setup works.  I force a bad missing artifact
> and maven output shows it only
> search my internal repo
>
>
> On 4/14/06, dan tran <dantran@gmail.com> wrote:
>   
>>  Did i mention it is a hacked solution? :-)
>>
>> BTW, the way m2 shows build output is very confused, when an missing
>> artifact occurs,
>> it shows repo1 got searched first.
>>
>> -D
>>
>>
>> On 4/14/06, Gunther Popp <Gunther.Popp@web.de> wrote:
>>     
>>> Hmm, what´s wrong with my solution? Redefining a repo using the id
>>> "central"? This works fine and is, IMO, a normal usage of the
>>> POM-inheritance of Maven (with pom-4.0.0.xml as implicit parent pom).
>>>
>>> Changing the hosts file would be necessary on every single developer
>>> workstation, so I´m not sure if this is really better.
>>>
>>> Gunther
>>>
>>>
>>> dan tran schrieb:
>>>       
>>>> this is  a hacked solution, fixup your hosts file and route
>>>> repo1.apache.orgto your internal host
>>>>
>>>> -D
>>>>
>>>>
>>>> On 4/14/06, Gunther Popp < Gunther.Popp@web.de> wrote:
>>>>
>>>>         
>>>>> Hmm, I´ve been monitoring this thread (and it´s predecessor) for a
>>>>>           
>>> while
>>>       
>>>>> am still not sure what´s wrong with your setup. From all I´ve read,
>>>>>           
>>> it
>>>       
>>>>> should work. I´m using internal repositories for a while now, without
>>>>>           
>>>>> any problems. Here´s my definition of repositories I´m using in my
>>>>>           
>>> POM:
>>>       
>>>>> <!-- Definition privater Repositories -->
>>>>> <repositories>
>>>>>    <repository>
>>>>>      <id>central</id>
>>>>>      <name>Privates Repository für externe Bibliotheken</name>
>>>>>      <url>http://localhost/mvnrepos/lib </url>
>>>>>      <releases>
>>>>>        <enabled>true</enabled>
>>>>>        <updatePolicy>daily</updatePolicy>
>>>>>      </releases>
>>>>>      <snapshots>
>>>>>        <enabled>false</enabled>
>>>>>      </snapshots>
>>>>>    </repository>
>>>>> </repositories>
>>>>>
>>>>> <pluginRepositories>
>>>>>     <pluginRepository>
>>>>>       <id>central</id>
>>>>>       <name>Privates Repository für Plugins</name>
>>>>>       <url>http://localhost/mvnrepos/plugin </url>
>>>>>       <releases>
>>>>>         <enabled>true</enabled>
>>>>>         <updatePolicy>daily</updatePolicy>
>>>>>       </releases>
>>>>>       <snapshots>
>>>>>         <enabled>false</enabled>
>>>>>       </snapshots>
>>>>>     </pluginRepository>
>>>>>   </pluginRepositories>
>>>>>
>>>>> Maybe you´ll find a difference to your setup. Just a note: A
>>>>>           
>>> potential
>>>       
>>>>> problem arises, if a POM in the repository defines a parent POM _and_
>>>>> redefines the central-repository using http://repo1.maven.org/maven2,
>>>>> too. In this case it is possible that Maven still accesses the
>>>>>           
>>> default
>>>       
>>>>> repository url to download the parent POMs. But AFAIK that´s not true
>>>>> for the POM of the resources-plugin.
>>>>>
>>>>> CU,
>>>>>
>>>>> Gunther
>>>>>
>>>>>
>>>>> EJ Ciramella schrieb:
>>>>>
>>>>>           
>>>>>> Take about 10 steps back and a deep breath - the problem is that
the
>>>>>>
>>>>>>             
>>>>> security forces that be don't like the fact that anything can be
>>>>>           
>>> placed up
>>>       
>>>>> there ( http://repo1.maven.org/maven2) and then pulled down.
>>>>>
>>>>>           
>>>>>> In addition to this, why oh why is maven downloading something
>>>>>>             
>>> remotely
>>>       
>>>>> that exist within our four walls?
>>>>>
>>>>>           
>>>>>> How do I stop this?
>>>>>>
>>>>>> E:\work\foxboro\model>mvn process-resources
>>>>>> [INFO] Scanning for projects...
>>>>>> [INFO]
>>>>>>
>>>>>>             
>>> ----------------------------------------------------------------------------
>>>
>>>       
>>>>>> [INFO] Building LtyModel
>>>>>> [INFO]    task-segment: [process-resources]
>>>>>> [INFO]
>>>>>>
>>>>>>             
>>> ----------------------------------------------------------------------------
>>>
>>>       
>>>>>> [INFO] artifact
>>>>>>             
>>> org.apache.maven.plugins:maven-resources-plugin:checking for updates
>>> from local-central
>>>       
>>>>>> [INFO] artifact
>>>>>>             
>>> org.apache.maven.plugins:maven-resources-plugin:checking for updates
>>> from central
>>>       
>>>>>> Downloading:
>>>>>>
>>>>>>             
>>>>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-resources-plugin/2.1/maven-resources-plugin-2.1.pom
>>>>>           
>>>>>> 888b downloaded
>>>>>> [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin:checking
>>>>>>
>>>>>>             
>>>>> for updates from local-central
>>>>>
>>>>>           
>>>>>> [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin:checking
>>>>>>
>>>>>>             
>>>>> for updates from central
>>>>>
>>>>>           
>>>>>> Downloading:
>>>>>>
>>>>>>             
>>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/2.0.1/maven-compiler-plugin-2.0.1.pom
>>>       
>>>>>> 1K downloaded
>>>>>> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin:checking
>>>>>>
>>>>>>             
>>>>> for updates from local-central
>>>>>
>>>>>           
>>>>>> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin:checking
>>>>>>
>>>>>>             
>>>>> for updates from central
>>>>>
>>>>>           
>>>>>> Downloading:
>>>>>>
>>>>>>             
>>>>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.1.3/maven-surefire-plugin-2.1.3.pom
>>>>>           
>>>>>> 1K downloaded
>>>>>> [INFO] artifact org.apache.maven.plugins:maven-javadoc-plugin:checking
>>>>>>
>>>>>>             
>>>>> for updates from local-central
>>>>>
>>>>>           
>>>>>> [INFO] artifact org.apache.maven.plugins:maven-javadoc-plugin:checking
>>>>>>
>>>>>>             
>>>>> for updates from central
>>>>>
>>>>>           
>>>>>> Downloading:
>>>>>>
>>>>>>             
>>> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-javadoc-plugin/2.0-beta-3/maven-javadoc-plugin-2.0-beta-3.pom
>>>       
>>>>>> -----Original Message-----
>>>>>> From: Gunther Popp [mailto: Gunther.Popp@web.de]
>>>>>> Sent: Thursday, April 13, 2006 1:51 PM
>>>>>> To: Maven Users List
>>>>>> Subject: Re: use of proxies
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> The first question is: why?
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> Sorry, for jumping in here, but a common reason is to guarantee
>>>>>> reproducible builds over a fairly long period of time. For example,
>>>>>>             
>>> the
>>>       
>>>>>> systems I´m engaged with have a typical lifetime of 15-20 years.
>>>>>>             
>>> When
>>>       
>>>>>> the software is considered stable after initial development, a team
>>>>>>             
>>> of
>>>       
>>>>>> maintenance developers will implement enhancements and fix bugs.
>>>>>>             
>>> These
>>>       
>>>>>> guys are typically responsible for several systems and have no time
>>>>>>             
>>> to
>>>       
>>>>>> hassle around with build tools. So the build process simply should
>>>>>>             
>>> work.
>>>       
>>>>>> You cannot guarantee this, if your build relies on any form of
>>>>>>             
>>> external
>>>       
>>>>>> resource that is not under your direct control. Even if I use
>>>>>>             
>>> explicit
>>>       
>>>>>> version numbering for plugins and dependencies, the corresponding
>>>>>> artifacts simply may disappear on iblio in five years from now. Or,
>>>>>> another scenario, maybe the repository layout changes in Maven 3
or
>>>>>>             
>>> 4
>>>       
>>>>>> and "legacy" Maven 2 repositories are only supported until 2010.
At
>>>>>>             
>>> this
>>>       
>>>>>> time it is to expensive and risky to upgrade the build process for
a
>>>>>>             
>>>>>> running mission-critical system to a completely new version of
>>>>>>             
>>> Maven.
>>>       
>>>>>> Nobody will fund this.
>>>>>>
>>>>>> So, the only way to prevent this is to use strictly internal
>>>>>> repositories. This means additional effort, of course, and only pays
>>>>>>             
>>> off
>>>       
>>>>>> if you really have use case for it. But these use cases certainly
>>>>>>             
>>> exist.
>>>       
>>>>>> CU,
>>>>>>
>>>>>> Gunther
>>>>>>
>>>>>> Barrie Treloar schrieb:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> On 4/13/06, EJ Ciramella <ejciramella@upromise.com > wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> All I'm attempting to do is prevent builds from going to
the maven
>>>>>>>>
>>>>>>>>                 
>>>>> repository.  I have set up one machine ( build.corp.upromise.com)
>>>>>           
>>> that has
>>>       
>>>>> everything from my .m2/repository directory (I copied it there).
>>>>>
>>>>>           
>>>>>>> The first question is: why?
>>>>>>>
>>>>>>> Maven manages your build dependencies. Use version numbers in
your
>>>>>>>               
>>> pom
>>>       
>>>>>>> dependencies to lock down what should be used instead of
>>>>>>>               
>>> restricting
>>>       
>>>>>>> access to central.
>>>>>>>
>>>>>>>
>>>>>>>               
>>> ---------------------------------------------------------------------
>>>       
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>> ---------------------------------------------------------------------
>>>       
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>> ---------------------------------------------------------------------
>>>       
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>         
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>       
>
>   


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


Mime
View raw message