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 <
alexan...@kriegisch.name> 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 <douglass.d...@gmail.com>:
> >
> > On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
> > alexan...@kriegisch.name> 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: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
