Greg, Thank you for your reply. It is unfortunate that it had to come to this to get an explanation. Why wasn't an explanation like this offered from the beginning? I'm not saying I agree or even like the explanation, but it is an explanation.
I have done some homework on Maven. I would never attempt to use the product without doing so. But if I may speak freely, this product appears to require a certain amount of "esoteric" knowledge. All I want to do is support the task I've been given. Of course I want to know how to use the tool. In fact when I wasn't finding the information I needed to do that, I turned to the Maven User Mailing List. How much knowledge must one have before they do this? Now let’s look at this particular situation, because I think it just might be unique (but I could be wrong). In this particular case I inherited a POM file that was developed by people no longer responsible for its upkeep. Those people were assisted by a software vendor that essentially no longer exists, so their employees that helped our people responsible for this are also no longer available either. We have all been in this situation before. Now the most important thing about this POM is that it is not even building software. You (and a few other people) mention that does not matter. I have a great difference of opinion here. Maven is ostensibly a build tool. Look at its terminology(e.g. as pertains to lifecycle stages). But I think the problem that exists is that in making the product flexible in how it implements its features it has opened the door to be used for more than just building software. I think that is the case here. The original creators of the POM in question used Maven to simply copy some files from one location probably simply because they could. Now I don't know if that was a good or bad idea, all I know is that I have to support it, it broke on my watch and I have to fix it. When I could not figure out how to do that I turned to the Maven community for help, and this is the result of that. So when you explain to me about dependencies, I understand them in the context of building software, because that's how Maven is supposed to be used. It appears to me that the people that originally developed this POM did not appreciate this when they used it almost as a script to copy files. Now I don't know if that is their fault or Mavens fault, but the simple fact of the matter is that I have to support it. And I would expect more than the struggle I've received during this experience. I know my attitude has not be the best, but that is what frustration leads to. And certainly the attitude of some of the people you say were trying to "help" should also be addressed here as well. Sincerely, Mike Michael Tarullo Contractor (Engility Corp) Enterprise Architect NSRR System Administrator FAA WJH Technical Center (609)485-5294 -----Original Message----- From: Greg Trasuk [mailto:tras...@stratuscom.com] Sent: Tuesday, October 06, 2015 12:39 PM To: Maven Users List Subject: Re: Copy-dependencies goal error 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
