Sean, last time I checked, Maven does not handle concurrent Maven processes using the same local repository--the kind that the Maven client sets up.
What does work that I know of is using a company-wide repo like Nexus or Artifactory. IME, issues with maven-metadata.xml, etc. do not come up in this configuration--I don't ever think about it myself. Each client will still have its own local repository, but will go to Nexus or Artifactory for their artifacts. Optionally, you can let Nexus or Artifactory fetch (once) all the third-party artifacts you need from Maven Central. With your CI server and all devs using the organization's central artifact repo, everyone is using the same artifacts as each other all the time. More specifically, `group:project:1.2.3` is conventionally just one artifact, not possibly a couple of different artifacts, as enforced by artifact repos like Nexus, Artifactory, and Maven Central. Once someone uploads a non-SNAPSHOT artifact to your company's artifact repository, it never changes (assuming you configure the repository according to convention). Certain things you can add on to the version like `-SNAPSHOT` indicate mutability. Someone please correct any misconceptions / outdated info on my part. On Mon, Nov 11, 2019 at 2:59 PM Sean Horan <combus...@gmail.com> wrote: > 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 > > > -- Jason Young Systems Engineer | TEVERA [image: Phone] 715 245 8000 x7609 [image: Mobile] 715 781 0845 [image: Web] tevera.com Confidentiality Notice: This message is intended for the sole use of the individual and entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure or distribution of this email message, including any attachment, is prohibited. If you are not the intended recipient, please advise the sender by reply email and destroy all copies of the original message.
