Thanks for all your answers, I know you want to help me, but you don't. I know what Maven was designed to do, and I can set up an internal repo or nexus for myself. But imagine a situation in which all I want to have as a precondition for building a tiny little OSS tool with external (non-Maven dependencies) is a working Maven installation and one command: mvn install. I do not want to put the burden on my users to create their own Nexus or manually download dependencies and install them to the local repo. I do not want to execute ugly Ant tasks and not use system dependencies with fixed paths. I have tried all this and got every variant working without much fuss, but somehow all of this feels so unclean. I would much prefer to get it working in a declarative Maven style. The non-maven
> Am 07.11.2013 um 22:43 schrieb Curtis Rueden <[email protected]>: > > Hi Alexander, > >> do you have any suggestion how to solve this problem in a clean, >> canonical Maven way, given a single condition: no private Nexus or >> external Maven repo is available and I want one-stop shopping and >> clean bootstrapping right from Maven. > > The blog post linked earlier answers exactly this question. > > The solutions it outlines to this problem are, in order of "best for the > Maven community to worst for the Maven community": > > 1.Get thee to Central > 2. Get the external jars into a public Maven repository > 3. Get the external jars into the internal Maven repository > 4. Use the reactor (and Stephen's non-maven-jar plugin) > 5. Use an ANT task > [Everything after this point is "Donny Don't".] > 6. The file:///${basedir} repository hack > 7. The system scope hack > > Options 1 & 2 require communication with the third party library > developers, which presumably is untenable for you. You have also rejected > #3 ("I kinda dislike manually uploading external JARs there"), which leaves > #4 as your next-best option. > > Regards, > Curtis > > P.S. I am intrigued by your current solution, since it doesn't even appear > on Stephen's list, but I am guessing it would fall under the "Donny Don't" > section. The non-maven-jar plugin is a more integrated way of doing what > you are trying to do. > > > On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch < > [email protected]> wrote: > >> I have never used Ant, so I do nkt have the urge to script my build. I >> have also read the blog post you mentioned. The JARs I was trying to >> dynamically download from. "non-Maven" URL are, as I said >> >> - not available on Central (I suggested it to the author, but he refused >> and keeps committing all dependencies to his SCM) >> >> - not available on any other public Maven repo >> >> - not even built with Maven. >> >> Our company even has an internal Nexus, but >> >> - I kinda dislike manually uploading external JARs there >> >> - I was in a situation where I did not have access to that Nexus instance >> and wondered if it was not somehow possible to bootstrap external >> JARs directly with Maven. Thus, I ended up using the combination of >> download-maven-plugin and maven-install-plugin, both tied to the first >> phase available, named validate. This works nicely if I call validate >> separately, but I wanted to do it Maven style in one call. I think it >> is a >> design flaw in Maven that it behaves differently for validate >> depending on >> which phase has been called. I think the principle of least surprise >> makes >> users expect a different (consistent) behaviour. I do not see any >> problems >> In an approach which executes validate before checking the downloads >> needed for compile. >> >> Having said that and further explained my situation, do you have any >> suggestion how to solve this problem in a clean, canonical Maven way, given >> a single condition: no private Nexus or external Maven repo is available >> and I want one-stop shopping and clean bootstrapping right from Maven. I >> think this is a simple enough and understandable requirement. It is >> actually what I have started using Maven for. >> >> >>> Am 07.11.2013 um 21:23 schrieb Doug Douglass <[email protected]>: >>> >>> On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch < >>> [email protected]> wrote: >>> >>>> Only "mvn compile" yields the exact same result as "mvn validate >> compile", >>>> I just did it like this explicitly to make a point and show clearly what >>>> hapens. So again: Why, pray tell, does my two-phase build work if first >> I >>>> only do "mvn validate" and then "mvn compile", but not with only "mvn >>>> compile"? The question is still unanswered. Two people told me I made a >>>> mistake but did not explain which one and where the different behaviour >>>> comes from. >>> You're right, I didn't answer your original question. The different is >>> because "mvn validate compile" and/or "mvn compile" is a single >> invocation >>> of maven and dependencies are resolved once (by default, w/o any other >>> plugins/configuration). "mvn validate; mvn compile" are 2 separate >>> invocations of maven; the first one does your "download external, >>> non-mavenised" business, which makes those dependencies available for the >>> second. >>> >>> I still suggest you read Steven's post as you're question/problem >> indicates >>> you're heading down the not-uncommon path of trying to script your build >>> (like we all did in the Ant days) vs. giving into The Maven Way. There's >>> lots of similar conversations in the list archives, the blog post is the >>> result of many such "debates". I'll apologize in advance if this is not >>> your case. >>> >>> Cheers, >>> Doug >> >> --------------------------------------------------------------------- >> 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]
