The developers can use whatever repos on the Internet they feel is appropriate, but it is up to the team lead to sync that up to the build server which does not have access to the public Internet.
Syncing the local repository that exists now on the build server with Artifactory is where I'm blocked because maven is looking for maven-metadata.xml files that I don't have and I don't understand the difference between maven-metadata.xml, maven-metadata-central.xml, and maven-metadata-mycompanyname.xml that are in the folder. Sean On Sun, Nov 10, 2019 at 11:31 PM Robert Scholte <rfscho...@apache.org> wrote: > If you don't have a repository manager in place to serve your developers > (that is, bound to the internet), then I consider that as a huge risk. > Developers will find other ways to get their libraries, which means you > can't know anymore if they came from a valid and secure location. > A repository manager should be the only place that acts as the single > point of trust. Only this way you can control all incoming (and optionally > outgoing) traffic. > > Robert > On 8-11-2019 00:22:28, Sean Horan <combus...@gmail.com> wrote: > Hi all, > > I am tasked with ensuring that the Maven build process of a large > government/enterprise-class system does not reach out to the Internet. Our > Jenkins server's local maven repository has 10,000 POMs. There are many > individual builds that are specific to our product and what we customize > for government clients. > > I have a lot of devops experience but practically no experience with Maven > and Java beyond struggling to set this up. > > We are using Artifactory and I'm not sure whether a generic or > Maven-specific repository is suitable for this project. > > As I'm trying to understand it, I am using curl in a find/curl loop adapted > from > > https://github.com/jfrog/project-examples/blob/master/bash-example/deploy-folder-by-checksum.sh > > to traverse the ~/.m2/repository on our existing Jenkins server and HTTP > PUT it over to Artifactory. This script would be hardened and sent to > internal customers to sync as part of the development process. > > The problem I am seeing is that the build process is looking for > maven-metadata.xml which does not exist on our server. We do have > -companyname and -central XML files for eg, the maven-source-plugin that > are slightly different. > > I have the sense that my approach to this is off and I'm in over my head so > I could use some help. > > Any pointers in the right direction would be more than welcome. > > We are using Maven 3.3.9 and JDK8 on Centos 7 and cannot upgrade at this > time. > > Sean Horan >
