Re: [M2] Managing Repositories
I think you are trying to control dependencies and not plugins right? So in order to do that, you need two different repositores. One for dependencies and one for plugin. Control access to the dependency one and allow free access to the plugin one. On 9/16/06, Andreas Guther [EMAIL PROTECTED] wrote: Hi, I am struggling with the question on how to maintain a controlled internal repository with Maven 2. We want to have full control over the downloaded dependencies and configured Maven to use as central repository our internal repository server. With this configuration no external repository is used. In my settings.xml file I have configured Ibiblio as external repository server and activate the profile whenever I have to use components with dependencies that are not in our internal repository. The problem I have is that getting the internal/central repository updated with the new dependencies is rather a tedious and time intensive task, especially if for example a maven plug-in is added that comes with lots of transient dependencies. My question is: Ho do other teams deal with that problem? Are there tools that list differences between two different repositories (local and internal)? I used Maven Archiva as proxy repository but that does not give us the control over what gets added to the repository. Thanks in advance for any hint and suggestion. Andreas - 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]
Re: [M2] Managing Repositories
Hi Andreas, Take a look at Proximity: http://proximity.abstracthorizon.org/ Bests, Henrique Andreas Guther wrote: Hi, I am struggling with the question on how to maintain a controlled internal repository with Maven 2. We want to have full control over the downloaded dependencies and configured Maven to use as central repository our internal repository server. With this configuration no external repository is used. In my settings.xml file I have configured Ibiblio as external repository server and activate the profile whenever I have to use components with dependencies that are not in our internal repository. The problem I have is that getting the internal/central repository updated with the new dependencies is rather a tedious and time intensive task, especially if for example a maven plug-in is added that comes with lots of transient dependencies. My question is: Ho do other teams deal with that problem? Are there tools that list differences between two different repositories (local and internal)? I used Maven Archiva as proxy repository but that does not give us the control over what gets added to the repository. Thanks in advance for any hint and suggestion. Andreas - 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]
RE: [M2] Managing Repositories
Hi Andreas, I had the same problem and the way I resolved it is as follows. Firstly I used Proximity as my proxy server to create my internal repository. Then I implemented a web server to read the internal repository. The developers were provided with the web servers http link. The above approach ensured that the developers could not download any files into the internal Repository automatically. If I needed to install a new plugin/dependency I used to use the http link provided by Proximity. This would first put the files into the internal repository before installing it in my local repository. Hope this helps. Thanks Lakshman -Original Message- From: Andreas Guther [mailto:[EMAIL PROTECTED] Sent: Sunday, 17 September 2006 3:59 AM To: Maven Users List Subject: [M2] Managing Repositories Hi, I am struggling with the question on how to maintain a controlled internal repository with Maven 2. We want to have full control over the downloaded dependencies and configured Maven to use as central repository our internal repository server. With this configuration no external repository is used. In my settings.xml file I have configured Ibiblio as external repository server and activate the profile whenever I have to use components with dependencies that are not in our internal repository. The problem I have is that getting the internal/central repository updated with the new dependencies is rather a tedious and time intensive task, especially if for example a maven plug-in is added that comes with lots of transient dependencies. My question is: Ho do other teams deal with that problem? Are there tools that list differences between two different repositories (local and internal)? I used Maven Archiva as proxy repository but that does not give us the control over what gets added to the repository. Thanks in advance for any hint and suggestion. Andreas - 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]
Re: [M2] Managing Repositories
On 9/17/06, Andreas Guther [EMAIL PROTECTED] wrote: Hi, I am struggling with the question on how to maintain a controlled internal repository with Maven 2. We want to have full control over the downloaded dependencies and configured Maven to use as central repository our internal repository server. With this configuration no external repository is used. I will link to my response to a similar query. http://www.nabble.com/forum/ViewPost.jtp?post=6087922framed=y Essentially I question the need for a locked down repository. About the only time I can see a need for this is because of security restrictions on network connections (i.e. defence with a secure and insecure network, as the secure network can not connect to ibiblio). Any other reason is just making busy work and adds no value. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2] Managing Repositories
Hi Laksham, I am currently using Maven Archiva which provides a Proxy repository and is probably similar to Proximity. I will definitely have a look at Proximity. Thanks for your reply. Andreas -Original Message- From: Lakshman Srilakshmanan [mailto:[EMAIL PROTECTED] Sent: Sunday, September 17, 2006 5:25 PM To: Maven Users List Subject: RE: [M2] Managing Repositories Hi Andreas, I had the same problem and the way I resolved it is as follows. Firstly I used Proximity as my proxy server to create my internal repository. Then I implemented a web server to read the internal repository. The developers were provided with the web servers http link. The above approach ensured that the developers could not download any files into the internal Repository automatically. If I needed to install a new plugin/dependency I used to use the http link provided by Proximity. This would first put the files into the internal repository before installing it in my local repository. Hope this helps. Thanks Lakshman -Original Message- From: Andreas Guther [mailto:[EMAIL PROTECTED] Sent: Sunday, 17 September 2006 3:59 AM To: Maven Users List Subject: [M2] Managing Repositories Hi, I am struggling with the question on how to maintain a controlled internal repository with Maven 2. We want to have full control over the downloaded dependencies and configured Maven to use as central repository our internal repository server. With this configuration no external repository is used. In my settings.xml file I have configured Ibiblio as external repository server and activate the profile whenever I have to use components with dependencies that are not in our internal repository. The problem I have is that getting the internal/central repository updated with the new dependencies is rather a tedious and time intensive task, especially if for example a maven plug-in is added that comes with lots of transient dependencies. My question is: Ho do other teams deal with that problem? Are there tools that list differences between two different repositories (local and internal)? I used Maven Archiva as proxy repository but that does not give us the control over what gets added to the repository. Thanks in advance for any hint and suggestion. Andreas - 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]
RE: [M2] Managing Repositories
Hi Barrie, Thank you for the interesting link. I am also not very convinced if a locked repository is really necessary and then if it is really the solution for our problem. One problem is that Maven seems to pull in more files than sometimes expected or really necessary. Maven analyzes all transient dependencies and adds all defined dependencies to path or lib folder for example of a war file. This sometimes creates unexpected conflicts, especially with XML parsers. And then that we sometimes end up with two versions of the same dependency. Application A needs components C1 and C2. C1 defines dependency on D version 1.1 and C2 defines dependency on D version 1.0. What I see is that we find both in our war lib folder. Right now I am not sure how to deal with those problems. The idea of locking the repository obviously does not really solve the problem. The convenience of Maven to resolve and download all transient dependencies seems to be paid with sudden conflicts that were not apparent in the first place without Maven. Andreas -Original Message- From: Barrie Treloar [mailto:[EMAIL PROTECTED] Sent: Sunday, September 17, 2006 6:02 PM To: Maven Users List Subject: Re: [M2] Managing Repositories On 9/17/06, Andreas Guther [EMAIL PROTECTED] wrote: Hi, I am struggling with the question on how to maintain a controlled internal repository with Maven 2. We want to have full control over the downloaded dependencies and configured Maven to use as central repository our internal repository server. With this configuration no external repository is used. I will link to my response to a similar query. http://www.nabble.com/forum/ViewPost.jtp?post=6087922framed=y Essentially I question the need for a locked down repository. About the only time I can see a need for this is because of security restrictions on network connections (i.e. defence with a secure and insecure network, as the secure network can not connect to ibiblio). Any other reason is just making busy work and adds no value. - 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]
RE: [M2] Managing Repositories
Hi barrie, After reading your post, I beg to differ on the need to lock down the repository. Locking down your repository has nothing to do with _not_ trusting your developers. The reason you lock down your repository is to avoid any unintentional library conflicts that may arise when you have multiple projects using the same repository. A single developer will not be preview to all the dependency matrix (especially the new graduates) and avoids any accidental library conflicts that may arise due to a new core library being installed. Thanks Lakshman -Original Message- From: Barrie Treloar [mailto:[EMAIL PROTECTED] Sent: Monday, 18 September 2006 11:02 AM To: Maven Users List Subject: Re: [M2] Managing Repositories On 9/17/06, Andreas Guther [EMAIL PROTECTED] wrote: Hi, I am struggling with the question on how to maintain a controlled internal repository with Maven 2. We want to have full control over the downloaded dependencies and configured Maven to use as central repository our internal repository server. With this configuration no external repository is used. I will link to my response to a similar query. http://www.nabble.com/forum/ViewPost.jtp?post=6087922framed=y Essentially I question the need for a locked down repository. About the only time I can see a need for this is because of security restrictions on network connections (i.e. defence with a secure and insecure network, as the secure network can not connect to ibiblio). Any other reason is just making busy work and adds no value. - 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]
Re: [M2] Managing Repositories
On 9/18/06, Andreas Guther [EMAIL PROTECTED] wrote: And then that we sometimes end up with two versions of the same dependency. Application A needs components C1 and C2. C1 defines dependency on D version 1.1 and C2 defines dependency on D version 1.0. What I see is that we find both in our war lib folder. Right now I am not sure how to deal with those problems. The idea of locking the repository obviously does not really solve the problem. The convenience of Maven to resolve and download all transient dependencies seems to be paid with sudden conflicts that were not apparent in the first place without Maven. This will also answer Lakshman Srilakshmanan's reply too. You had to deal with these version conflicts before, but you had to do so manually. At least I did when using Ant. With Maven the dependencies are explicitly managed by the pom so it takes the guesswork out of what is really needed. Admittedly there are some projects out there that need cleaning up and marking some of their dependencies optional so that you don't get the kitchen sink as well. However the two ways I resolve these problems are 1) your parent pom defines all version information and your modules do not. 2) override the dependency values (if your are depending upon something other than a module) and exclude things. The root cause of your problem is that Components C1 and C2 need to ensure that they are using the same versions, which is the job of your Configurations Controller to check and enforce. By locking the repository down you just add a layer of administration that slows things down when the component really does need a different version. If the versions are incompatible then that means you need to communicate more to ensure people are using sanctioned versions and one component needs to be modified (either upgraded or downgraded in library versions). I find that you can get away with not explicitly sanctioning versions for quite a lot of projects. For the small number of cases where version conflicts arise then listing the sanctioned versions on your internal wiki is quicker, cheaper and more accessible than locking the repository. If all this fails, then sit down with the projects and communicate how dependencies work, which is still much cheaper than trying to lock down the repository. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
