Hi Alexander,
> The non-maven-jar plugin was new to me, but unfortunately it also does
> not do what I want because it expects the JAR to already exist in a
> certain place and even have a custom Maven module for it.
Why not scratch your itch: fork the non-maven-jar-maven-plugin, add support
for remote JAR locations, and submit a PR?
-Curtis
On Thu, Nov 7, 2013 at 4:13 PM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:
> Sorry, my finger slipped, sent too early...
>
>
> > Am 07.11.2013 um 23:02 schrieb Alexander Kriegisch
> <alexan...@kriegisch.name>:
> >
> > 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
>
> The non-maven-jar plugin was new to me, but unfortunately it also does not
> do what I want because it expects the JAR to already exist in a certain
> place and even have a custom Maven module for it. Maybe I can somehow
> combine it with the download plugin, but it seems awkward.
>
> Basically my solution with binding download and dynamic artifact
> installation to a local repo to the validate phase works nicely as long as
> I call the mvn validate separately for the very first time. Afterwards it
> is absolutely transparent because the artifacts are first class maven
> citizens after installation. The little bit of comfort missing is just a
> trick to delay artifact resolution until after dynamic installation, for
> which I hoped to get a magic Maven option or switch as a hint here on the
> user group. Thanks for bearing with me, even thanks for lecturing me about
> Maven basics I already knew by heart. I share your opinion that people not
> maintaining their artifacts on Central & Co. are indeed "bad", but hey, it
> is a real life situation I want to deal with and handle as gracefully as
> possible with as few dirty tricks as possible.
>
> I might look into creating a custom lifecycle with an additional
> pre-validate phase, if at all possible. I just fear that that hypothetic
> lifecycle will also check dependencies before starting the hypothetic
> pre-validate phase...
>
>
> >
> >
> >> Am 07.11.2013 um 22:43 schrieb Curtis Rueden <ctrue...@wisc.edu>:
> >>
> >> 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
> >>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
