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
