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 < > [email protected]> wrote: > > > Sorry, my finger slipped, sent too early... > > > > > > > Am 07.11.2013 um 23:02 schrieb Alexander Kriegisch > > <[email protected]>: > > > > > > 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 <[email protected]>: > > >> > > >> 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
