Hi Michael: Aside - Are you at the FAA tech center in Atlantic City? I taught a course there four days after 9/11. Very nice people there, although the mood wasn’t great at the time, obviously. I particularly enjoyed seeing what I thought was a museum of ancient computers in the cafeteria (core memory and all)- until they explained they were samples of the then-deployed ATC hardware!
Anyhow, I understand your frustration - Maven can have a somewhat steep learning curve. It seems to me that the answers you’ve gotten so far are correct, but perhaps they seem unhelpful because you don’t already have enough knowledge of the product. Unfortunately, with open source, you, the user, need to meet the user list half-way, and get some background knowledge so you can ask the right questions and use the answers effectively. There’s a classic treatise by Eric Raymond on asking questions (http://catb.org/~esr/faqs/smart-questions.html) that you might want to read, although you might not like the content. In fairness, there’s also a newer guide to answering questions out there (https://skippy.net/how-to-answer-questions) that we ought to read every now and then. In short, you might not like the choice of open source, but I’m guessing your employer already made that choice, and they had good reasons, so… let’s work together! Let’s start with… > It is simply copying ZIP/MD5/SHA1 files from a Nexus repository to a local > workstation. You’re mistaken. Maven is not copying files, it is copying dependencies or artifacts. Sorry if this seems like “maven-speak” to you, but you are going to continue to be frustrated until you try to get a clear mental model of what Maven is doing. Let me try to help… Maven is specifically geared to avoid worrying about where files are on disk. It does this so that (believe it or not) life is easier for developers, since you don’t need to manually manage a library of files that your software might depend on. So, when you say that you have a POM that “copies files from your nexus repository to a local file system”, that’s not exactly correct, that’s only what it looks like from the outside. In reality, what Maven is doing is attempting to track down all the artifacts that will be needed to fulfull the dependencies that are called out in your POM. Normally, Maven uses all these artifacts as the compile-time class path for compiling other source code to create new artifacts, but in your case, your POM file calls out a build plugin that simply copies all those artifacts to a folder on the local file system. The idea of an “artifact” is key to understanding Maven. An artifact is typically a jar, war, or ear file that we use, either as a dependency for another artifact, or to install in a server environment. In order to get us away from depending on the file system, an artifact in Maven is identified by its “Maven Coordinates” or “GAV Coordinates”, which are the group id, artifact id, and version of the artifact. The artifact (every artifact!) is described using a POM file. “POM” is unfortunately a bit of a misnomer - it originally means “Project Object Model”, but should really be something like “Artifact Descriptor”, as it’s really associated with the artifact, not a project. Think of the POM as metadata that describes the artifact. The general idea is that given an artifact’s GAV coordinates, Maven can go off to a repository like Maven Central or your local Nexus repository and retrieve (a) the artifact and (b) the artifact’s metadata, or POM file. One mistake people make is thinking that the POM file tells Maven what to do. That isn’t correct - the POM file defines what an artifact _is_, and then Maven figures out how to build it, given the packaging type and the set of dependencies that are called out in the POM file. It’s also possible for a POM file to define metadata only, without an actual artifact being specified (otherwise known as a POM artifact, since it calls out ‘pom’ packaging). In this case, we still have GAV coordinates, but they’re more of a metadata identifier. The POM you posted defines a POM artifact with the GAV coordinates “com.iona.fuse:all-products-1.0.0.0-fuse”, and calls out a number of dependencies on activemq, camel, and cxf artifacts. Generally, “figuring out how to build it” requires Maven to track down and include transitive dependencies. So if I call out Spring Framework version 3.1, maybe it requires Apache commons collections version 2.2. Maven knows that my artifact won’t work without Spring’s dependencies, so it looks up the metadata (POM file) for Spring 3.1, and adds its dependencies (i.e. transient dependencies) to the list of dependencies for my artifact. Maven looks up the dependencies by going out to its repository (i.e. Maven Central or your local Nexus) and asking for the POM files for each of the dependencies. It adds in the transitive dependencies, and then looks up the metadata for those dependencies, and so on, and so on. This is what people mean by “resolving dependencies”. In your case, your POM file is a little funny - rather than defining an artifact to build, it really exists only to define a set of dependencies and then call out the build plugin called "maven-dependency-plugin”, which is configured to copy the dependencies to the local file system. Here’s your key point - Maven resolves the dependencies even if your particular plugin configuration is not going to use them - the core maven package doesn’t care about the plugin configuration; it just does its thing, which is resolve dependencies. So even though your plugin configuration specifies “<excludeTransitive>true</excludeTransitive>”, Maven still goes to your Nexus repo and tries to track down those transitive dependencies. Your error message, [ERROR] Failed to execute goal on project all-products: Could not resolve dependencies for project com.iona.fuse:all-products:pom:1.0.0.0-fuse: Failed to collect dependencies at org.apache.camel:apache-camel:zip:src:2.15.1.redhat-620133 -> org.apache.camel:camel-cmis:jar:2.15.1.redhat-620133 -> org.apache.chemistry.opencmis:chemistry-opencmis-client-impl:jar:0.8.0 -> org.apache.chemistry.opencmis:chemistry-opencmis-commons-impl:jar:0.8.0 -> com.sun.xml.ws:jaxws-rt:jar:2.1.7 -> com.sun.xml.stream.buffer:streambuffer:jar:0.9 -> org.jvnet.staxex:stax-ex:jar:RELEASE: Failed to read artifact descriptor for org.jvnet.staxex:stax-ex:jar:RELEASE: Failed to resolve version for org.jvnet.staxex:stax-ex:jar:RELEASE: Could not find metadata org.jvnet.staxex:stax-ex/maven-metadata.xml in local (C:\Users\Michael CTR Tarullo.FAA\.m2\super-pom-test-repository-62) means that when Maven tried to resolve the dependencies for "org.apache.camel:apache-camel:zip:src:2.15.1”, the metadata for that artifact (which is in your repository) included a dependency on "org.jvnet.staxex:stax-ex”, but that artifact is not present in your repository. The short answer is that you need to get "org.jvnet.staxex:stax-ex” into your repository. It appears to be in Maven Central, so I’m guessing that your Nexus is configured not to act as a proxy to Maven Central. So you’ll need to either load it manually (or use “procurement”) or configure your Nexus to proxy Maven Central (unless of course you can’t do that for security or other reasons, which is why you’d go through procurement). Since you don’t actually care about the “stax-ex” dependency, you could theoretically load a “dummy” jar and pom that would satisfy the dependency, but that’s really bad practice - some other build might need the real dependency at a later time, so you’re best to get the right files into your repository. Hope this helps. Also, there’s a webinar I did for my employer that you might enjoy, Maven for Late Adopters (http://www.webagesolutions.com/webinars/registration.html?ApacheMavenLateAdopters). We also offer training and consulting. Cheers, Greg Trasuk > On Oct 5, 2015, at 5:02 PM, <michael.ctr.taru...@faa.gov> > <michael.ctr.taru...@faa.gov> wrote: > > There are no transitive dependencies! > > This is not even building source code!!! > > > Michael Tarullo > Contractor (Engility Corp) > Enterprise Architect > NSRR System Administrator > FAA WJH Technical Center > (609)485-5294 > > > -----Original Message----- > From: Jörg Schaible [mailto:joerg.schai...@gmx.de] > Sent: Monday, October 05, 2015 4:37 PM > To: users@maven.apache.org > Subject: RE: Copy-dependencies goal error > > Hi Michael, > > michael.ctr.taru...@faa.gov wrote: > >> What do you mean by a consistent repository and POM model? >> >> If you mean that the POM must be declaring files to copy that are in >> the repository, that is stating the obvious. >> >> And in this case, the POM is doing exactly that. The files I am >> asking to be copied from the repository are actually in the >> repository. The problem is that I am getting errors for files I did not ask >> to be copied. > > The repository must also contain all POMs for the transitive dependencies ... > otherwise Maven cannot build the project model. Maven core does not know that > you have bound an instance of the assembly plugin, that is not interested in > the transitive dependencies. > >> Did you look at the POM file I attached and compare it to the error >> messages also attached? > > The POMs of the referred artifacts get interesting. > > Chrres, > Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
