Re: mvn install on a top level of multimodule project
I've encountered a similar problem when one of the sub-modules is a maven plugin that is used by another sub-module. I discovered this only when I cleaned-up my local repository. Then mvn clean install didn't work. Even mvn clean and mvn validate failed because the plugin was missing. My solution was to split my top-level maven project into two: One for maven plugins, and one for everything else. I don't know if this is something that can be fixed, or whether it's a design consequence. I suppose that the missing maven plugin could participate in any goal, including the clean or validate goals, therefore maven can't proceed with anything if a plugin is missing. Aside from this though, I found that maven 2.0.9 works as advertised in figuring out a correct order to build sub-projects.
Re: Third party jars
Thank you Brian, I am now using Nexus Repository Manager, and it does save me from a lot of hassle. It was easier than I thought. I just resisted at first, because switching from Ant to Maven was more work than I thought it would be, so I didn't want to get deeper into trouble with repository managers. Is there a way to convert a local repository into a remote repository, or should I upload each artifact to Nexus again? (I have a few dozen). For now, I've copied my 3rd party section from my local repository directly to the Nexus 3rd-party repo, and it seems to work. I removed the metadata files, since they are local repo metadata. Of course, I'm now adding new 3rd party jars through Nexus. I've found this related issue, but it doesn't explain the solution: https://issues.sonatype.org/browse/NEXUS-996 -Alex On Sat, Nov 29, 2008 at 8:27 PM, Brian Fox bri...@reply.infinity.nu wrote: You could save youself a lot of hassle with a repo manager. You shouldn't use local repos as remote repos because the metadata is different. Also with unmanaged repos, snapshot accumulation will become a problem. --Brian (mobile)
Re: Are Maven profiles like Ant targets?
This reminds me of this best practice that uses a single maven profile to run an ant task: http://ionixx.wordpress.com/2008/03/10/running-specified-ant-tasks-within-maven2-outside-the-lifecycle/ Basically, you can run an ant target from maven like this: mvn -Pant -Dtarget=my-target. This is better than using ant alone, because it lets maven construct an appropriate classpath which the ant target can use. So, maven tasks were not designed to be like ant targets, but can be used like them, if you're using ant targets as standalone scripts outside of the build lifecycle. -Alex
Re: [Public service announcement] mirrors of Central and considerate repo use
Thanks. This sheds some light to my darkness, and may explain why my home-made maven mirror wasn't working properly. Alex On Sat, Nov 29, 2008 at 4:33 PM, Wendy Smoak [EMAIL PROTECTED] wrote: On Sat, Nov 29, 2008 at 5:16 AM, Alex Athanasopoulos [EMAIL PROTECTED] wrote: One of the most annoying problems I ran into with maven was when I setup a central mirror containing my old local repository, deleted my local repository, and then tried to rebuild it by doing a build. A local repo can't be used as a remote repo... while the directory structure looks the same, the metadata files are different. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Third party jars
Why not put the jars in a repository? A repository is perfect for containing 3rd party jars, and one of maven's major benefits. Once you do that, you don't need to refer to the jars through a hardcoded path, but simply by a portable artifact identifier. You don't need any special tools or repository managers, but you do need to setup your own remote repository somehow. I simply use mvn install:install-file, and then copy the generated files from my local repository to a remote repository that I have created just for 3rd party libs. I'm fairly new to maven, and this is one of the first things I had to do. The rest is just defining and managing repositories, which can be a discussion of its own. I'm not using any repository managers yet (learning to live with maven is enough work for me right now). My A-B-Cs of repository management have been the following: A) At first I used only my local repository, which I shared with other developers by putting it under version control in svn, just like I had my 3rd party libs before maven. I used mvn -o most of the time, to avoid accessing Maven's central repository. I was a bit annoyed that I had to use -o. I tried to use the offline configuration in settings.xml, but I couldn't get it to work (one of my first frustrations with maven). mvn -o worked reliably, but I had to remember to use it. Whenever I needed a piece of Maven that I didn't have, I used mvn without the -o flag, and once everything worked, I added the new artifacts from my local repository to svn. I did not add my snapshots. B) I then figured out how to avoid the -o flag, by defining a mirror of the central repository in my settings.xml. The mirror was simply an http-accessible location of the single svn-managed repository that I had. Whenever I needed to use a new piece of maven, I commented out the mirror specifiction in my settings.xml, ran mvn so it could get new pieces from repo1.maven.org, and then took the comment out of settings.xml. The rest was as in A. C) I now use two repositories: 1) A repository of non-maven released artifacts. Essentially this contains 3rd party libraries. These are libraries that I've gotten directly from their source, and which I've entered in the repository through install:install-file. I plan to also put my own released artifacts there. 2) A central-mirror repository that has just the things that maven needs (plugins and their dependencies). This is the most difficult repository to manage, and a source of problems, as I find maven's dependencies chaotic and unstable. This is why I've isolated them from my other artifacts. D) I plan to also use a snapshots repository that is automatically updated with my daily build artifacts. In fact, I may simply provide http access to the daily build's local repository. For now, I rebuild all of my artifacts locally. Alex On Fri, Nov 28, 2008 at 10:38 PM, [EMAIL PROTECTED] wrote: Hi, Is there any way to get the maven build process to include a set of jars when compiling/packaging that are not in the repository? I have some vendor jars and I don't fancy packing them all up and placing them into the repository - I just want to point maven at a lib directory? Thanks, john ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Public service announcement] mirrors of Central and considerate repo use
This touches on my pet peeve about maven. I wish that I could download a zip file containing the subset of central containing maven's core plugins and their dependencies. I would then gladly use it as my central mirror and work productively on my projects without having to worry about central. I also wish that Maven did not access a central online repository by default, so I wouldn't have to go through the extra effort of preventing it from doing so. When Maven is installed out of the box, it could be configured to use its own self-contained repository that came with the installation. If I want non-core plugins or other things, then I could tell maven to use an online repository. In other words, I want an integration-tested self-contained maven release. Is that a lot to ask for from a dependency management tool? I don't have that now, so I have to do my own version managemnet of all maven plugins that I use. When I try to use a plugin or a plugin feature that I haven't used before, I have to go through a sometimes painful process of figuring out which is the version of the plugin that works and is consistent with all my existing projects and plugins. I've more than once used a plugin version mentioned in the documentation, only to find out that it's buggy or obsolete and I need to use a newer version (or sometimes even a completely different groupId/artifactId). Can maven, the tool, be separated from central, the grand repository of java libraries? I don't want central. If I want library X for my projects, I can go to library X's website, download X, and add it to my repository. If library X wants to be maven-friendly, it can include a script that lets me add all its jar files to my repository easily, so I don't have to add them one by one manually. Wouldn't this reduce traffic to maven central? But maven doesn't come in a box. Instead, it lets its plugins download whatever dependencies they want from central. It seems that it even gives them the freedom to specify a range of versions, or any random version they find, so that what a build does is unpredictable and dependent on the vagaries of a moving target central repository. It's amazing that it works most of the time, but it fails too often for me. One of the most annoying problems I ran into with maven was when I setup a central mirror containing my old local repository, deleted my local repository, and then tried to rebuild it by doing a build. mvn went on to happily copy things from my central mirror, until it couldn't resolve a dependency. It has something to do with a RELEASE version of a plugin not being found. I have aparently gotten a central artifact at some point in time that has an integration problem with other artifacts and ends up using an artifact version that it doesn't explicitly ask for. I believe it's related to the site plugin, which I have since stopped trying to use. In the end, I went back to copying my central mirror to my local repository (something easily done with svn, which I use as my repository manager). -Alex On Tue, Nov 25, 2008 at 5:27 PM, Brian E. Fox [EMAIL PROTECTED]wrote: The central repo has been undergoing significant load lately, most likely the result of people crawling and attempting to download all 70GB of it. I'd like to point out the availability of additional mirrors that you can use to increase your download performance and reduce the load on central. These mirrors are updated daily right after central pulls in all the new artifacts, so they are as fresh as central. Find the list of mirrors here[1]. Also, for those of you with multiple developers in a single location not using a repo manager, what are you waiting for? There are plenty to choose from and numerous reasons to do so, particularly the ability to isolate yourself from transitive network outages or slowdowns. You can read more about why and the existing repo managers at [2],[3] and a comparison grid here at [4] Also, if you are using a repo manager, make sure to correctly configure it to not make requests to public repositories for your internal artifacts. Otherwise you are making a ton of requests for things that will never be found, increasing the bandwidth usage on your side and ours. Also it gives away potentially sensitive information as someone could scrape the logs and figure out what you're up to internally based on these requests. Nexus lets you configure routing rules so you could exclude com.yourcompany.* from central. Archiva has similar functionality, I'm not sure about Artifactory. Please be a polite repository user. These repos and mirrors are provided free of charge but there is a real cost behind providing this bandwidth. Scraping the entire repository starves other users and increases the cost of providing these repositories to the community. If the mirrors start getting abused then we may find less geographical redundancy as a result. There is never a reason to
