Re: Unpacking jars into target/classes

Thank you very much, the effort is truly appreciated. I didn't consider system scope. Not sure whether that was because I heard advice against using it or whether I simply overlooked it unter the wealth of approaches to try. We have finally decided to try Gradle despite the amount of work inv

Oops

That shouldn't have gone to the list. Apologies. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

Hi Brian, Let me express a big Thank You; this was a much-needed breath of fresh air, and I 100% agree with every single sentence in your posting. This isn't going to change much about the technical issues, but you did a whole lot to restore my respect for the community that's building and m

Re: Unpacking jars into target/classes

Am 19.03.2013 23:40, schrieb Stephen Connolly: I don't know what kind of message you got, because it seems that you are intent on mis-interpreting everything I write... I wonder what you will jump on in this reply! On nothing at all. No reasons to. -

Re: Unpacking jars into target/classes

Am 19.03.2013 22:20, schrieb Stephen Connolly: On Tuesday, 19 March 2013, Joachim Durchholz wrote: Am 19.03.2013 12:13, schrieb Stephen Connolly: Jo, Just for you, I have taken the 30 minutes out of my life and written a Maven Plugin that will solve your issues with those pesky non-maven

Re: Unpacking jars into target/classes

Am 19.03.2013 14:02, schrieb Stephen Connolly: Wayne, Please open an issue ( https://github.com/stephenc/non-maven-jar-maven-plugin/issues). Pull requests welcome Just for the record: This confirms that you did that in full consent with both the community and your true inner beliefs. I had

Re: Unpacking jars into target/classes

Am 19.03.2013 12:13, schrieb Stephen Connolly: Jo, Just for you, I have taken the 30 minutes out of my life and written a Maven Plugin that will solve your issues with those pesky non-maven dependencies. https://github.com/stephenc/non-maven-jar-maven-plugin Sorry, but that bold text is a pie

Re: Unpacking jars into target/classes

Am 18.03.2013 12:45, schrieb Stephen Connolly: I would not base your opinion on this one thread. Joachim got off on the wrong foot by mistaking us trying to guide him towards a path (where he won't fight maven all the way) for us being evangelical and spouting religious dogma... Just for the r

Re: Unpacking jars into target/classes

Am 18.03.2013 07:43, schrieb Anders Hammar: Joachim, you're way out of line here! Please do a background check on my contribution to this project before you insult me! Anders, your contributions to Maven were never part of this discussion. Except if you base your demands on how your contributi

Re: Unpacking jars into target/classes

Am 17.03.2013 18:22, schrieb Jeff MAURY: Impress to see that you're claiming you personal priorities prevent you to open a ticket on JIRA but allow you to write a mail including external links The same question could go to Anders...

Re: Unpacking jars into target/classes

Am 16.03.2013 11:54, schrieb Anders Hammar: Jira would be an option, but unfortunately, my time is limited and I'll leave that to people who are already registered and know how to split up a report into meaningful, addressable chunks and file them under the right section. I'm sorry Joachim, but

Re: Unpacking jars into target/classes

Am 15.03.2013 02:16, schrieb Barrie Treloar: On 7 March 2013 23:24, Joachim Durchholz wrote: It's never a bad idea to improve the docs, but the real problem is the plugin docs. Many options are "documented" along the lines of "frob: frobs the build", which isn&#

Re: Unpacking jars into target/classes

Am 08.03.2013 14:05, schrieb Baptiste MATHUS: If there's no way to get it to work (and that's the answer I got from Baptiste), then it's not me who's doing it wrong. Where did I write "there's no way to get it to work"? Sorry for the misrepresentation - it was the conclusion I arrived at aft

Re: Unpacking jars into target/classes

Thanks, somehow I overlooked the truezip plugin. It should do the trick. Regards, Jo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

Am 08.03.2013 04:48, schrieb Ron Wheeler: I am not sure what you expect us to say. Simply stick with the question at hand and don't waste everybody's time with evangelizing and philosophy. By your own experience, your approach doesn't work; you won't try to do it the right way; If there's

Re: Unpacking jars into target/classes

Am 07.03.2013 22:41, schrieb Stephen Connolly: Crazy and stupid are not insults in this context... So if I call Ron a clown, and when he's considering that an insult, I explain to him that that's a very respectable thing to be? I think you are taking this thread far too personally On the

Re: Unpacking jars into target/classes

So no apology and you feel entirely justified. With the argument that you're not talking to me but to posteriority. Now it seems that your perceptions of future readers are more important than anything I have to say; I'll keep that in mind. -

Re: Unpacking jars into target/classes

Am 07.03.2013 19:53, schrieb Ron Wheeler: The trick is not to stop reading it but to stop doing it. Nope. The trick is to ignore abuse. You are getting advice from one of principle architects and authors of Maven. No advice, just evangelizing and allegations that I'm an idiot. What would

Re: Unpacking jars into target/classes

Am 07.03.2013 13:55, schrieb Stephen Connolly: BUT if you are doing something that is crazy and stupid Yeah okay, I stopped reading at that allegation. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additiona

Re: Unpacking jars into target/classes

Just some feedback... Am 07.03.2013 13:22, schrieb Stephen Connolly: Maven wants the java source code in ${basedir}/src/main/java... you want it somewhere else... you know what, Maven is OK with that I'm actually okay with that source structure, though I don't like the split between .../java/

Re: Unpacking jars into target/classes

Am 07.03.2013 13:05, schrieb Andreas Gudian: That's not really what I want. I want a declarative specification so the tool can decide what build steps to run. I want full scripting only for the individual build steps. This probably means an obligation to specify the declarative metadata so the to

Re: Unpacking jars into target/classes

(Sorry, more philosphy ahead, just trying to explain my situation to Adrien) Am 07.03.2013 12:16, schrieb Adrien Rivard: I claim that Maven's stance of essentially requiring a repository manager needlessly complicates the build infrastructure. It may complicate the build infrastrucure but it s

Re: Unpacking jars into target/classes

Am 07.03.2013 12:53, schrieb Anders Hammar: You forgot: - You need a repo manager :-) Sorry, couldn't stop myself, Yeah, talk about waste of time :-( - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional

Re: Unpacking jars into target/classes

Warning: Just philosophy here. I AM trying to restrict myself to things I haven't said before. Some amount of repetition is inevitable, and this kind of discussion is nearing the point of diminishing returns, so I'm trying to cut down on this kind of discussion. Am 07.03.2013 10:57, schrieb B

Re: Unpacking jars into target/classes

Am 07.03.2013 12:07, schrieb Jörg Schaible: Personally, I'll simply stop to look at your questions, because you waste my time and IMHO you waste yours, too. I couldn't agree more to the waste-of-time observation. Though in our case, I guess it's been your answer with its lengthy philosophical

Re: Unpacking jars into target/classes

Am 07.03.2013 10:00, schrieb Jörg Schaible: Hi, Joachim Durchholz wrote: Am 07.03.2013 05:51, schrieb Matthew Adams: Quick jist: 1. Use maven-install-plugin's install-file<http://maven.apache.org/plugins/maven-install- plugin/install-file-mojo.html>goal to make maven artifacts

Re: Unpacking jars into target/classes

Am 07.03.2013 05:51, schrieb Matthew Adams: Quick jist: 1. Use maven-install-plugin's install-filegoal to make maven artifacts out of the jars you intend to unpack, and do it in any phase prior to process-classes (or do

Unpacking jars into target/classes

Hi all, I have two jars from an external source and need to merge their contents into the target/classes tree until the process-classes phase. I'm not sure what plugin(s) can be used to achieve this effect. Directory structure: - external (directory tree that holds the externally-provided file

Re: Antwort: Re: Maven Shade Plugin

Am 01.03.2013 14:59, schrieb Stephen Connolly: On 1 March 2013 12:08, Joachim Durchholz wrote: Am 01.03.2013 07:17, schrieb Tim Kettler: That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. I knew. I just didn'

Re: Antwort: Re: Maven Shade Plugin

Am 01.03.2013 07:17, schrieb Tim Kettler: That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. I knew. I just didn't want to contradict Stephen right away. Plus, classifiers are usually assumed to identify auxiliary artifacts for a

Re: Antwort: Re: Maven Shade Plugin

Am 28.02.2013 16:24, schrieb Jan Engler: At first: in fact this is only one artifact. The full jar contains all classes of the dependecies, the api a reduced set (using filtern in the shade plugin). Is there a (conceivable) Maven build that uses api.jar as a dependency? Then it must be the main

Re: Maven Shade Plugin

Am 28.02.2013 14:50, schrieb Jan Engler: As you might have seen, I want to have 4 artifacts: api.jar, api-sources.jar, full.jar, full-sources.jar. Which of these are supposed to be used as dependencies in other projects? Each project can supply exactly 1 artifact for dependent Maven builds. Ot

Re: [ANN] Maven – the simplest possible introduction?

Am 24.02.2013 12:39, schrieb Thomas Sundberg: Hi! I just wrote a blog on getting started with Maven It might help someone to get a small example up and running. http://thomassundberg.wordpress.com/2013/02/24/maven-the-simplest-possible-introduction/ You may want to mark the JUnit dependency as

Re: Deploying non-unique SNAPSHOTs

Am 23.02.2013 21:21, schrieb Baptiste MATHUS: Hi Joachim, Could you please tell us the URL of the page(s) you read where you think this information would have been valuable? We can improve it. http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#updateReleaseInfo -

Re: Deploying non-unique SNAPSHOTs

Am 23.02.2013 17:44, schrieb Lewis John Mcgibbney: I'm on 3.x unfortunately. @Joachim Can you please elaborate a bit on artifactory please? I have no access to the Artifactory installation right now and for the upcoming week. IIRC it's an option on the repository. I modified only those reposi

Re: Deploying non-unique SNAPSHOTs

Am 23.02.2013 08:55, schrieb Stephen Connolly: Maven 3.x removed the ability to deploy non-unique snapshots. This should be documented in the plugin's docs. I wasted half an afternoon trying to get this to work, and that was just for me. There's an option on the repository in Artifactory tha

Easy MRM installation? Hah!

Just to give the feedback: I've been told that installing a repository and an MRM is a breeze, takes a one-minute-install, etc. etc. I should have read the implied fine print: This will work only for a strictly local install, and even then, there are snags. 1) When sitting behind a firewall i

Re: MRM inside Eclipse

Am 07.02.2013 21:43, schrieb Curtis Rueden: Just in case you didn't see it already, the following page of the M2E documentation explains (rather obtusely) in detail about how to configure M2E's "lifecycle mappings" to work with various Maven plugins: http://wiki.eclipse.org/M2E_plugin_execu

Re: Jar file not in maven

Am 07.02.2013 15:53, schrieb Ron Wheeler: On 07/02/2013 4:50 AM, Joachim Durchholz wrote: Am 07.02.2013 00:00, schrieb Barrie Treloar: You could always pony up some of your own money for a server or try finding a free hosting service and install the MRM there. You could even leave your home

Re: MRM inside Eclipse

Am 07.02.2013 11:32, schrieb Adrien Rivard: but by default they are going there. And you don't need to run an "install", just refresh/build the project with eclipse. Hm... testing with a parent project... ... nope. Running a Maven launch with a "package" goal doesn't add any file to disk as

Re: MRM inside Eclipse

Am 06.02.2013 22:51, schrieb Ron Wheeler: To mention it about the fifth time: The m2e repo is NOT the local cache repo. The m2e repo lives in in an Eclipse-managed directory (in .metadata/plugins IIRC). The local (cache) repo lives in ~/.m2. These two repos are shown in the Maven Repositories ta

Re: Jar file not in maven

Am 07.02.2013 00:00, schrieb Barrie Treloar: You could always pony up some of your own money for a server or try finding a free hosting service and install the MRM there. You could even leave your home computer on all the time and let your other resources connect to the MRM you install there. M

Re: MRM inside Eclipse

Am 06.02.2013 23:43, schrieb Adrien Rivard: On Wed, Feb 6, 2013 at 9:55 PM, Joachim Durchholz wrote: Now I'm wondering where m2e is putting things if I run a Maven launch with an "install" target. It's definitely not going to ~/.m2/repository. It may depends on your

Re: MRM inside Eclipse

Am 07.02.2013 08:27, schrieb Baptiste MATHUS: Try running help:effective-settings from eclipse and read the value of localRepository tag. Nothing unexpected here it seems (this was with a freshly emptied .m2, not sure whether that changes anything): http://maven.apache.org/POM/4.0.0"; xmlns:x

Re: MRM inside Eclipse

Am 06.02.2013 21:40, schrieb Stephen Connolly: That's the lucene index of the maven repository. No content, just an index Ah okay, thanks. As I wrote elsewhere, I'm not wondering where the installs go if I run an Eclipse launch. I don't think they go to ~/.m2/repository, but where else could

Re: MRM inside Eclipse

Am 06.02.2013 21:29, schrieb Baptiste MATHUS: 2013/2/6 Joachim Durchholz Am 06.02.2013 20:33, schrieb Curtis Rueden: Hi Joachim, m2e installs its own repository inside .metadata. My Eclipse workspace has no such thing: $ ls .metadata/ .bak_0.log .bak_3.log .bak_6.log .bak_9

Re: MRM inside Eclipse

Am 06.02.2013 20:38, schrieb Stephen Connolly: On Wednesday, 6 February 2013, Joachim Durchholz wrote: Am 06.02.2013 19:57, schrieb Stephen Connolly: See in-line On Wednesday, 6 February 2013, Joachim Durchholz wrote: Am 06.02.2013 17:47, schrieb Manfred Moser: I dont think there is

Re: MRM inside Eclipse

Am 06.02.2013 20:33, schrieb Curtis Rueden: Hi Joachim, m2e installs its own repository inside .metadata. My Eclipse workspace has no such thing: $ ls .metadata/ .bak_0.log .bak_3.log .bak_6.log .bak_9.log .mylyn/ .bak_1.log .bak_4.log .bak_7.log .lock.plugins/ .bak_2.l

Re: MRM inside Eclipse

Am 06.02.2013 19:57, schrieb Stephen Connolly: See in-line On Wednesday, 6 February 2013, Joachim Durchholz wrote: Am 06.02.2013 17:47, schrieb Manfred Moser: I dont think there is a real MRM type of functionality in M2e ... kind of doesnt make sense to me either. A MRM is a server software

Re: MRM inside Eclipse

Am 06.02.2013 19:03, schrieb Baptiste Mathus: Le 6 févr. 2013 18:22, "Joachim Durchholz" a écrit : m2e installs its own repository inside .metadata. The issue I'm having is that I can't manage that repository. Unless, of course, I install a local Nexus and point it to that

Re: MRM inside Eclipse

Am 06.02.2013 19:03, schrieb Baptiste MATHUS: Le 6 févr. 2013 18:26, "Joachim Durchholz" a écrit : I have two issues here: 1) The m2e repo is soaking up disk space (which isn't a real issue except it's slowing down backups) 2) The m2e repo is defining coordinates that

Re: Jar file not in maven

Am 06.02.2013 16:31, schrieb Wayne Fay: Most of us on this list are simply too pragmatic to take that position against using Ant in your Maven build. Ant is treated as pretty much a first-class citizen in Maven -- you can even write Maven plugins in Ant. I find this a bit strange. Maven is inte

Re: MRM inside Eclipse

Am 06.02.2013 15:46, schrieb Ron Wheeler: The Nexus MRM has a web browser interface that we use to manage MRM activities. Other than searching the MRM for new libraries to get their GAV info, there is really not a lot of interaction between developers and the MRM since Maven will get what is ther

Re: MRM inside Eclipse

Am 06.02.2013 17:47, schrieb Manfred Moser: I dont think there is a real MRM type of functionality in M2e ... kind of doesnt make sense to me either. A MRM is a server software while M2e is a development environment. m2e installs its own repository inside .metadata. The issue I'm having is that

Re: Jar file not in maven

Am 30.01.2013 18:14, schrieb Curtis Rueden: If you do not have a server you control, or you think running an MRM is too complex, or some other issue, there is install:install-file. Now, I absolutely appreciate the concern that it sucks to force all your developers to do that on every new local ma

Re: MRM inside Eclipse

Am 04.02.2013 22:13, schrieb Ron Wheeler: I found STS in the marketplace, and it lists all the plugins that it comes with, so I installed Spring IDE Maven support. Unfortunately, I'm not seeing any additional Maven-related facilities. Is it in some other plugin? (I want to avoid installing plugin

MRM inside Eclipse

Am 30.01.2013 23:16, schrieb Ron Wheeler: On 30/01/2013 4:54 PM, Joachim Durchholz wrote: I'd really love to have an MRM for the repo that m2e runs inside the Eclipse workspace. That would be useful; Eclipse's "Maven Repositories" view is extremely limited (essentially it

Re: Jar file not in maven

Am 30.01.2013 10:44, schrieb Stephen Connolly: First off, I am assuming (always a danger of making an ass of you and me) that we have a multi-module project. No multi-module project here, just dependencies (and a parent pom to capture configuration analogies). I would create a pom.xml for t

Re: Jar file not in maven

Am 30.01.2013 23:39, schrieb Stephen Connolly: There are two ways to look at this: 1. Maven is what it is, how do I achieve my end goal as close as is practicable to the maven best practices 2. Maven sucks, and here is how it should do things differently. We appreciate both types of viewpoint,

Re: Jar file not in maven

Am 30.01.2013 16:14, schrieb Ron Wheeler: You are arguing with the guys who wrote Maven and are responsible for maintaining it. Should I stand in awe from that? I doubt it. I have seen many holes punched into authority figures. In one instance, I was the one who did the punching. Besides, I h

Re: Jar file not in maven

Am 30.01.2013 21:45, schrieb Lyons, Roy: Actually... if I may. I might be able to end this a little easier by providing some information which I think has been left out of the conversation so far. Thanks, that's very much appreciated. Nexus now comes with a functionality of metadata. You c

Re: Jar file not in maven

Am 30.01.2013 10:20, schrieb Stephen Connolly: Now that's just crazy, who would roll back an SVN repo and overwrite a revision past? I'd download from http://repo/tags/1.3.2. And if that's borked, the maintainer will provide http://repo/tags/1.3.3 and I'll update the pom to download from there.

Re: Jar file not in maven

Am 30.01.2013 09:13, schrieb Anders Hammar: Joachim, a possible solution would be to front the external non-Maven repo with a repo manager transforming it into a true Maven repo. Sounds complicated. I.e. not doable unless you know all aspects that need to be considered, hence probably far out

Re: Jar file not in maven

In that case, you will simply have to tell them where to get the files and tell them that they have to be uploaded into their Maven repo with the same GAV that you used in your POM. No one would have trouble with these instructions. Uh... there are a lot of people who're comfortable with an IDE

Re: Jar file not in maven

Am 30.01.2013 00:22, schrieb Stephen Connolly: On 29 January 2013 22:22, Joachim Durchholz wrote: Am 29.01.2013 21:09, schrieb Stephen Connolly: On Tuesday, 29 January 2013, Joachim Durchholz wrote: Am 29.01.2013 19:42, schrieb Anders Hammar: The right/correct solution here is to

Re: Jar file not in maven

Am 29.01.2013 22:06, schrieb Ron Wheeler: On 29/01/2013 2:47 PM, Joachim Durchholz wrote: Am 29.01.2013 19:42, schrieb Anders Hammar: The right/correct solution here is to setup an internal Maven repository where you deploy those jars to. I still feel very uneasy about that, and I think I

Re: Jar file not in maven

Am 29.01.2013 21:09, schrieb Stephen Connolly: On Tuesday, 29 January 2013, Joachim Durchholz wrote: Am 29.01.2013 19:42, schrieb Anders Hammar: The right/correct solution here is to setup an internal Maven repository where you deploy those jars to. I still feel very uneasy about that

Re: Jar file not in maven

Am 29.01.2013 19:42, schrieb Anders Hammar: The right/correct solution here is to setup an internal Maven repository where you deploy those jars to. I still feel very uneasy about that, and I think I can pinpoint the reason a bit better now: One of the promises of Maven is that you can descr

Re: What's better, properties or configuration

Am 26.01.2013 16:45, schrieb Doug Douglass: @Anders, on the contrary, pom properties work quite well. I concur. I've used both approaches, and both did exactly what they were supposed to (verified by checking Maven output at "debug" verbosity). @Jo, one consideration I think you missed is w

What's better, properties or configuration

E.g. 1.7 1.7 vs. org.apache.maven.plugins maven-compiler-plugin 3.0 1.7 1.7 I can see several points that might factor into a decision, but I'm not sure which of them are relevant in prac

Re: Best way to retrieve multiple subsets from SVN?

Am 24.01.2013 21:23, schrieb Stephen Connolly: If you are either replacing the (empty) jar with your "real" jar in the package phase of your 13 projects without source, Ah, good to know. I had intended to put that into an earlier phase, but of course the compiler will recreate the jar. Thank

Re: Best way to retrieve multiple subsets from SVN?

Am 24.01.2013 19:53, schrieb Ron Wheeler: Seems a pity not to just set it up right at the start and then your life with maven would be harmonious. What I suggested is a way to use maven in a way that everyone here could help you and your builds would be very simple. Sorry, I must have been miss

Re: Best way to retrieve multiple subsets from SVN?

Am 24.01.2013 18:53, schrieb Ron Wheeler: On 24/01/2013 11:54 AM, Joachim Durchholz wrote: Am 24.01.2013 15:00, schrieb Ron Wheeler: On 24/01/2013 3:34 AM, Joachim Durchholz wrote: Am 24.01.2013 05:39, schrieb Ron Wheeler: You manually put the jars in your Maven repo through its manual

Re: Best way to retrieve multiple subsets from SVN?

Am 24.01.2013 15:00, schrieb Ron Wheeler: On 24/01/2013 3:34 AM, Joachim Durchholz wrote: Am 24.01.2013 05:39, schrieb Ron Wheeler: You manually put the jars in your Maven repo through its manual upload procedure with some version number (nice if it relates to the version that the authors gave

Re: Best way to retrieve multiple subsets from SVN?

Am 24.01.2013 16:35, schrieb Stephen Connolly: What you want to do is create a series of shim projects for each of these "external" libs, If you mean a just-pass-it-through-unchanged-already project with "shim project", then yes that's what I want to do. > and then just have your CI server r

Re: Best way to retrieve multiple subsets from SVN?

Am 24.01.2013 05:39, schrieb Ron Wheeler: You manually put the jars in your Maven repo through its manual upload procedure with some version number (nice if it relates to the version that the authors gave them) and reference them as dependencies. That's 13 jars to be built from their sources, a

Re: Best way to retrieve multiple subsets from SVN?

Am 23.01.2013 13:44, schrieb Manfred Nilsson: Hi I am going on a hunch here what your are trying to do, in my opinion this is poorly supported by maven currently (I however guess you could use the maven-release-plugin and create a tag Creating an SVN tag? No, that's not the point at all. I don

Best way to retrieve multiple subsets from SVN?

Hi all, I have a bunch of projects that need to extract files from an SVN repository as part of their build process. I need to make sure that all of them use the same SVN revision. It's initially determined as "whatever the current HEAD is", but since HEAD might change anytime, I need a way to

Re: Multi-Module: How to download other project's as dependency's without build it locally

Am 18.01.2013 14:35, schrieb Andrew Todd: I'm not entirely sure, but I think that you might be looking for the "copy" goal in the Maven dependency plugin. https://maven.apache.org/plugins/maven-dependency-plugin/ I'm feeling uneasy about this one. Having to disable the true purpose of the plug

Re: Packaging up pre-existing jar and source jar

Am 18.01.2013 11:07, schrieb Stephen Connolly: My point is, you think adding a MRM is adding a point of failure... actually it's taking away about 3-4 points of failure, so NET GAIN in reliability. Well, right now, everything is bootstrapping nicely from a Bitbucket repository. I'm using Mave

Re: Packaging up pre-existing jar and source jar

Am 17.01.2013 23:17, schrieb Stephen Connolly: First, when you are playing with install:install-file you will find that you regularly need to blow away your local cache (which is the real name of the "local repository")... Turned out I'm not really installing to .m2/repository, but to something

Re: Packaging up pre-existing jar and source jar

You two are really priceless. I have heard the message, I have requested concrete reasoning, yet all I get is a pat on the shoulder and a commandment to shut up and believe already. Four mails, and not a SINGLE concrete explanation what could (or will) go wrong. You decry that people are creat

Re: Packaging up pre-existing jar and source jar

Am 17.01.2013 10:08, schrieb Jörg Schaible: Ah, I had seen that but thought it was inapplicable because I want to deploy just to the local repo. But I guess I can tell it to deploy to ${settings.localRepository}, right? What Anders tells you in a lot of word is: Your last sentence does not make

Re: Packaging up pre-existing jar and source jar

Am 17.01.2013 08:10, schrieb Anders Hammar: You need to read up on Maven terminology. "deploy" means deploying/copying to a remote repo (outside your machine). What you seem to be aiming at is "install" as installing/copying to your local repo on your machine. Been there, done that. Can't say t

Re: Packaging up pre-existing jar and source jar

Am 16.01.2013 13:08, schrieb Francesco Mari: Take a look at the deploy-file mojo [0]. There is a brief explanation of it in the "Usage" page of the deploy plugin [1]. [0] http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html [1] http://maven.apache.org/plugins/maven-deploy-pl

Re: Packaging up pre-existing jar and source jar

Am 16.01.2013 22:26, schrieb Ron Wheeler: If you want them both in one artifact: Use a "pom" packaging type with the dependencies lib.jar and lib-sources.jar. Use the Assembly plugin to make a jar with both jars inside. Hmm... does that mean that a Maven project can install at most a single j

Packaging up pre-existing jar and source jar

Hi all, sorry if this is a FAQ but I didn't find instructions on maven.org for this. I'm provided with a lib.jar and lib-sources.jar. How do I make Maven generate an artifact from these, without recompiling the sources? (lib-sources.jar needs to be available for debugging when importing the ar