maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Douglass <douglass.d...@gmail.com>
Subject Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Date Thu, 07 Nov 2013 21:43:52 GMT
On Thu, Nov 7, 2013 at 2:29 PM, Alexander Kriegisch <
Alexander@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.
>
>
I don't mean to sound rude, but all these excuses have been heard here
before and Steven's blog post is a direct and detailed response that
provides many solutions to your problem. Maven has a robust dependency
resolution and download mechanism, if you choose not to use it, you will be
continually fighting an uphill battle that will (already has) lead to
frustration.

That said, my pragmatic advice to your situation is Steven's solution #4.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message