maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Date Fri, 08 Nov 2013 00:13:57 GMT
On Thursday, 7 November 2013, Curtis Rueden wrote:

> 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.


There are plugins that will download files for you, and a maven rule is one
artifact per module

>
> 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 <
> Alexander@kriegisch.name> wrote:
>
> > Sorry, my finger slipped, sent too early...
> >
> >
> > > Am 07.11.2013 um 23:02 schrieb Alexander Kriegisch
> > <Alexander@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 <ctrueden@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
> >



-- 
Sent from my phone

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