Re: site-plugin and "dot" files
yes, it should work. Maven site has such .htaccess: see http://svn.apache.org/viewvc/maven/site/trunk/src/site/filtered-resources/ It's a filtered resource in this case, I didn't check if it works when the resource is not filtered, but it should be ok. Regards, Hervé Le vendredi 06 août 2010, Carr, Brian M a écrit : > Is it possible to have .htaccess or other "dot" files deployed via the > site-plugin? My structure looks like this: > > project > > |-src > |-\main > |--\site > |--|apt > |---\index.apt > |--|resources > |\htaccess > ||htgroup > > but the target/site fold is missing the resource files after running the > site stage. > > --b > > __ > Brian M. Carr > Identity and Access Management > ITS Applications > University of Texas at Austin > V: 512-232-6419 > F: 512-471-5746 > brianmc...@austin.utexas.edu - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: site-plugin and "dot" files
On Fri, Aug 6, 2010 at 5:52 PM, Carr, Brian M wrote: > Is it possible to have .htaccess or other "dot" files deployed via the > site-plugin? My structure looks like this: > > project > |-src > |-\main > |--\site > |--|apt > |---\index.apt > |--|resources > |\htaccess > ||htgroup > > but the target/site fold is missing the resource files after running the site > stage. What happens if you run "mvn site-deploy" ? You can configure the url to be file:///some/temp/location to check. FWIW, it works fine in src/site/resources elsewhere, like http://svn.apache.org/repos/asf/continuum/site/src/site/resources/ -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: m2eclipse Doxia Editor
The M2Eclipse prior to 0.10.0 has now been decomposed into the core and extras. As of now I don't believe the Doxia Editors are being built and placed in the extras update site. I'll take a look and see if the build is functioning. If it's working it shouldn't be too hard to get it in the standard extras site: http://m2eclipse.sonatype.org/sites/m2e-extras/ One of my best friends lives in Austin so the email caught my eye :-) On Aug 4, 2010, at 4:13 PM, Carr, Brian M wrote: > Is there a separate eclipse update site for the Doxia Editor which used to > ship with m2eclipse? It seems that it's either no longer a part of > m2eclipse, or has moved to some other location. > > --b > __ > Brian M. Carr > Identity and Access Management > ITS Applications > University of Texas at Austin > V: 512-232-6419 > F: 512-471-5746 > brianmc...@austin.utexas.edu > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Re: force maven to redownload/refresh "released" dependencies
On Aug 6, 2010, at 3:53 PM, Haszlakiewicz, Eric wrote: >> -Original Message- >> From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org] >> >> Eric, you're not going to win this one. It's part of the philosophy of >> Maven. It's also good practice. >> >> Give it up. >> >> I'm not going to fight the site generation being split out of Maven. I >> think I understand Jason's point on that, though I disagree. And that's > a >> *much* less nasty violation of Maven's perceived function, if in fact, > it >> is a violation. >> >> What you're wanting is a violation. > > You're missing the point of what I'm asking. I'm not suggesting that > maven make it possible or easy to *create* the violation. I'm > suggesting that it should be able to *detect* the violation. > > I'm baffled as to why the maven community is so against the idea of > having additional (optional) checks to detect problems. > The nut of the problem is that if we had to support every optional behavior for a particular subset of the community the code base would likely be unmaintainable. No one here is going to implement anything toward what you're specifically asking for because Maven was specifically designed not to work for what you want. It probably would not be hard to do what you ask for, but just because something is possible doesn't mean it's a good idea to do it. Generally when people argue along the lines of "well my organization doesn't do that and we can't change" I retort that the community of Maven users is like an organization and it's far more powerful then yours. We don't do that and we're not going to change. So the onus would be on you to take the sources of Maven and alter it for your use and then the cost of maintaining that behavior becomes yours and it's not cheap. It's really not cheap. We can't make everyone happy and that's ok with us, well it's at least ok with me. I guess I can't speak for everyone. There are other build tool options, or you can maintain your own fork of Maven with the behavior your organization desires. Now what you're asking for here sounds particularly disastrous. If across your organization a release does not actually mean a release in the Maven sense you are going to have so many problems with what plugins normally expect and how artifacts may be integrated across different groups. Trust me, you do not want to go hunting around trying to figure out if something actually changed because looking at an artifact that is supposed to be immutable in Maven but isn't just screams out N points of failure. None of the IDE integration would work properly, many of the CI tools also wouldn't work very well. You're just asking for a world of very expensive pain. Every organization can change. You may not be able to change tomorrow but you can change. I've seen it happen at the biggest of the big. My suggestion if you are looking at Maven is to start with a smaller project and use Maven the way it's supposed to be used and evaluate if that's workable for your organization today. I can tell you with absolute certainty that what you're asking for is never going to implemented. But on the dev list we can point you in the right direction if you want to hack something up yourself. > eric > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: Problem with uniqueVersion=false in 3.0 beta1
Because the code to support that was a giant rats nest, and everything was re-written. It's mostly an anti-pattern to use so the developers rewriting that code didn't re-implement it. So far no one has stepped up to provide a patch to put it back in. That's essentially it in a nutshell. On Fri, Aug 6, 2010 at 12:15 PM, Adam Krieg wrote: > We have a local repo manager and it still takes a fixed amount of time per > artifact. It would take a few minutes to totally rebuild a local repo as we > have a fair number (hundreds) of artifacts, and Maven itself requires a bunch > of plugins just to get started. Granted I could just delete my group from > the local repo tree to speed things up, but I don't understand why we need to > do this when the SNAPSHOT notion seemed to work just fine for us. The > SNAPSHOT version was useful and I'm not sure why it was taken out in M3. > > -Original Message- > From: Brian Fox [mailto:bri...@infinity.nu] > Sent: Friday, August 06, 2010 11:42 AM > To: Maven Users List > Subject: Re: Problem with uniqueVersion=false in 3.0 beta1 > > No, but with a repo manager, it's pretty quick to wipe the local and > refetch everything cleanly from the local network. > > On Fri, Aug 6, 2010 at 10:31 AM, Adam Krieg wrote: >> Is the local repository smart enough to clear out the old snapshots? I'm >> worried about tons of irrelevant artifacts. >> >> -Original Message- >> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] >> Sent: Thursday, July 15, 2010 4:00 PM >> To: Maven Users List >> Subject: Re: Problem with uniqueVersion=false in 3.0 beta1 >> >> You recall correctly, uniqueSnapshots will always be true for M3 >> irrespective of what you try to set it to >> >> -Stephen >> >> P.S. I don't understand exactly why... I think it has something to do with >> Repository managers being sufficiently good that they can reclaim the disk >> space for you so the non-unique is no longer required. >> >> On 15 July 2010 20:28, Anders Hammar wrote: >> >>> IIRC Maven 3 only supports unique versioned snapshots (currently). There >>> was >>> some discussion easlier here on the mailing list regarding that. Search >>> some >>> archive for more info. >>> >>> /Anders >>> >>> On Thu, Jul 15, 2010 at 21:24, Adam Krieg >>> wrote: >>> >>> > I'm trying to configure Maven to not create unique snapshots. >>> > >>> > When using the following settings in Maven 2.2.1, this works: >>> > >>> > >>> > false >>> > >>> > >>> > >>> > However when I run with Maven 3.0 beta 1, I get autogenerated numbers >>> > appended, as if uniqueVersion was true. >>> > >>> > >>> > Is anyone else seeing this behavior? >>> > >>> > Disclaimer: http://pragmatrading.com/disclaimer.html >>> > >>> >> >> Disclaimer: http://pragmatrading.com/disclaimer.html >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > Disclaimer: http://pragmatrading.com/disclaimer.html > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: trouble with checkstyle
Hello Dennis Thanks for the link. It does sound like that error. Pretty crippling (imo). I found and installed maven-checkstyle-plugin-2.4.jar and installed it in my artifactory. It took a while to find one with valid META-INF\maven\plugin.xml. Same results. My suspicion is that if I upgraded from maven2.0.9 this problem would disappear but that is not an option at this time. Checkstyle 2.5 does work with my checkstyle.xml when configured within each of my subprojects. So that is what I will be doing for now. Thanks, Gord
Re: force maven to redownload/refresh "released" dependencies
On Aug 6, 2010, at 6:16 PM, Ron Wheeler wrote: > On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote: >>> -Original Message- >>> From: Ron Wheeler [mailto:rwhee...@artifact-software.com] I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? >>> If you can not deploy the release, that will tell you that you are >>> trying to rerelease an artifact. Maybe you'll get lucky and something is different enough in your artifact that the build process fails. >>> Your attempt to deploy will fail. That will tell you right away that >> you >>> are doing the wrong thing. >> No, the deployment of a project that USES a changed artifact will NOT >> fail. > > Yes. > That is why releases can not be replaced. > In your case, you should have deleted the wrong artifacts and loaded them > with new versions. > And informed the victims that they needed to update their dependencies. > > You were completely in control of the versions and names. And, frustrating though it is, that's what I've done when my bad QC has released bad stuff onto Central. You just put out another version and apologize on the web page. There's not a lot else to do, and it's not that bad. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote: -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? If you can not deploy the release, that will tell you that you are trying to rerelease an artifact. Maybe you'll get lucky and something is different enough in your artifact that the build process fails. Your attempt to deploy will fail. That will tell you right away that you are doing the wrong thing. No, the deployment of a project that USES a changed artifact will NOT fail. Yes. That is why releases can not be replaced. In your case, you should have deleted the wrong artifacts and loaded them with new versions. And informed the victims that they needed to update their dependencies. You were completely in control of the versions and names. Ron eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven Tomcat Plugin - Context File
I have the following: /myapp src/main/test/context.xml I have context.xml at that location. However, I still get "Cannot invoke Tomcat manager: FAIL - No context exists for path /myapp" I am not sure why. Thanks. -Original Message- From: Olivier Lamy [mailto:ol...@apache.org] Sent: Friday, August 06, 2010 6:10 PM To: Maven Users List Subject: Re: Maven Tomcat Plugin - Context File Hi, Try src/test/tomcat/context.xml 2010/8/7 Neil Chaudhuri : > I have a configuration file, call it myapp.xml, that would be found in > conf\Catalina\localhost in a conventional deployment to indicate that the > context for my application is to be found at /myapp. I don't want to include > this file in my war. My question is simply where should I put myapp.xml in my > source tree and how I should reference it in the configuration of my plugin. > > Thanks. > > -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy http://www.viadeo.com/fr/profile/olivier.lamy7 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Ron Wheeler [mailto:rwhee...@artifact-software.com] > On 06/08/2010 4:04 PM, Haszlakiewicz, Eric wrote: >> Is it really going to be that much wasted bandwidth to download a few >> checksums? >> >> Can a plugin hook into the existing support for detecting changes in >> snapshots? >You do not have to. >SNAPSHOTS are checked in exactly the way you want releases to be checked >because SNAPSHOTS are supposed to change and by default you get the >latest deployed SNAPSHOT. >To find out if you have the latest SNAPSHOT, Maven will check the >repository and download the new version for you automatically. So you're saying that I should always upload a released package using a SNAPSHOT version? Then it seems like I'm lying about what the package actually is. >That is why we are so comfortable with the current system. >Only the stuff that you indicate is unstable, is checked and the stable >stuff (called Releases) can be used from your local cache without problem. > >The clear distinction between a stable release and a SNAPSHOT is your >team's commitment to each other not to break things after you have said >that they are done. ...snip... I am not arguing against the idea of having snapshots that can be updated, and releases that stay stable. I'm perfectly fine with that being what *should* happen, but I know it's impossible that the correct procedures will be followed at all times. It seems that you're connecting the creation of a release with the process of uploading it to a particular repository. If you're dealing solely with projects that use maven, and perfect people that never fiddle with the repository directly, then you can probably consider those to be equivalent. But not everything is a maven project, and not everyone follows the perfect procedures, and not all disks are perfectly immune from corruption. If there is ever a problem with uploading the artifact to the repository, or with it after it's been uploaded, then I'd want to know that there is something wrong. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Tomcat Plugin - Context File
Hi, Try src/test/tomcat/context.xml 2010/8/7 Neil Chaudhuri : > I have a configuration file, call it myapp.xml, that would be found in > conf\Catalina\localhost in a conventional deployment to indicate that the > context for my application is to be found at /myapp. I don't want to include > this file in my war. My question is simply where should I put myapp.xml in my > source tree and how I should reference it in the configuration of my plugin. > > Thanks. > > -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy http://www.viadeo.com/fr/profile/olivier.lamy7 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Tomcat Plugin - Context File
I have a configuration file, call it myapp.xml, that would be found in conf\Catalina\localhost in a conventional deployment to indicate that the context for my application is to be found at /myapp. I don't want to include this file in my war. My question is simply where should I put myapp.xml in my source tree and how I should reference it in the configuration of my plugin. Thanks.
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Ron Wheeler [mailto:rwhee...@artifact-software.com] >> I'm AGREEING with you that the solution is to wipe out the local >> artifact! But you can only do that once you know there is something >> wrong. How do you detect that the artifact has changed? >If you can not deploy the release, that will tell you that you are >trying to rerelease an artifact. >> Maybe you'll get lucky and something is different enough in your >> artifact that the build process fails. >Your attempt to deploy will fail. That will tell you right away that you >are doing the wrong thing. No, the deployment of a project that USES a changed artifact will NOT fail. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven deploy plugin
> of these deploy fine to Archiva. I have one maven project that is similar > in structure to all the rest that produces a 2M JAR. This project will not > deploy to Archiva. It exits with the following exception: Did you post this on the Archiva list? They may know about a defect either in Maven or Archiva (or their interaction) which is triggering this error. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
site-plugin and "dot" files
Is it possible to have .htaccess or other "dot" files deployed via the site-plugin? My structure looks like this: project |-src |-\main |--\site |--|apt |---\index.apt |--|resources |\htaccess ||htgroup but the target/site fold is missing the resource files after running the site stage. --b __ Brian M. Carr Identity and Access Management ITS Applications University of Texas at Austin V: 512-232-6419 F: 512-471-5746 brianmc...@austin.utexas.edu smime.p7s Description: S/MIME cryptographic signature
Re: force maven to redownload/refresh "released" dependencies
On 06/08/2010 4:04 PM, Haszlakiewicz, Eric wrote: -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric wrote: You're missing the point of what I'm asking. I'm not suggesting that maven make it possible or easy to *create* the violation. I'm suggesting that it should be able to *detect* the violation. I'm baffled as to why the maven community is so against the idea of having additional (optional) checks to detect problems. Eric, The point is releases don't change. To "detect" means wasting bandwidth comparing your supposedly unchanging released local artifacts to supposedly unchanging released remote artifacts. If anything, writing a Maven plug-in for this would be more appropriate, but I don't see your suggestion as part of Maven core. Is it really going to be that much wasted bandwidth to download a few checksums? Can a plugin hook into the existing support for detecting changes in snapshots? You do not have to. SNAPSHOTS are checked in exactly the way you want releases to be checked because SNAPSHOTS are supposed to change and by default you get the latest deployed SNAPSHOT. To find out if you have the latest SNAPSHOT, Maven will check the repository and download the new version for you automatically. That is why we are so comfortable with the current system. Only the stuff that you indicate is unstable, is checked and the stable stuff (called Releases) can be used from your local cache without problem. The clear distinction between a stable release and a SNAPSHOT is your team's commitment to each other not to break things after you have said that they are done. With SNAPSHOTS you can decide to stick with a certain version of a SNAPSHOT or take the latest depending on your informal contract with the developer. If I tell you that today I am deploying a SNAPSHOT that is tested to do this function and that function while I am continuing to work on a third function and fix a deficiency in the first function, at least you know what you have to deal with. Youi can decide that you want to get my fixes as soon as they are deployed or you want to stick with the buggy one since your code deals with the bug and you want to go on testing with a stable version of my SNAPSHOT. But it is your choice and you know what you are getting. If I deploy a Release of my artifact, you are assured that I am promising you a production quality artifact ready to go in the final build. If you, God forbid, find a bug in my release 2.1.4, I must issue a patched version with a new version number 2.1.5 or 2.1.4.1 and let people know that if they want the fixed version, they have to change their dependencies or suffer the bug that you found. I can not lie to you about what you are getting. In a team, this is a big help. Ron eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 06/08/2010 4:01 PM, Haszlakiewicz, Eric wrote: -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric wrote: Please read the rest of the email thread. The short summary is: Yes, I know what *should* happen, but the world isn't perfect and release artifacts DO sometimes change. It is not absurd to be able to detect and recover from that kind of situation. The solution is to wipe out your local artifact. No one should be updating released artifacts. If they do, they abused what a release means -- hence the problem to begin with. The solution given is the only (correct) one in Maven. I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? If you can not deploy the release, that will tell you that you are trying to rerelease an artifact. Maybe you'll get lucky and something is different enough in your artifact that the build process fails. Your attempt to deploy will fail. That will tell you right away that you are doing the wrong thing. Or maybe you have some regression testing that you'll do so you notice the problem. Having maven compare the checksums seems like a much more reliable way to catch these problems. Yes use SNAPSHOTS. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Aug 6, 2010, at 2:58 PM, Paul Benedict wrote: > On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric > wrote: > >> You're missing the point of what I'm asking. I'm not suggesting that >> maven make it possible or easy to *create* the violation. I'm >> suggesting that it should be able to *detect* the violation. >> >> I'm baffled as to why the maven community is so against the idea of >> having additional (optional) checks to detect problems. >> >> > Eric, > > The point is releases don't change. To "detect" means wasting bandwidth > comparing your supposedly unchanging released local artifacts to supposedly > unchanging released remote artifacts. If anything, writing a Maven plug-in > for this would be more appropriate, but I don't see your suggestion as part > of Maven core. And actually, it wouldn't be that hard to write such a plugin. But you have to want it... -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Eduardo M KALINOWSKI [mailto:edua...@kalinowski.com.br] > >On Sex, 06 Ago 2010, "Haszlakiewicz, Eric" wrote: >> I'm AGREEING with you that the solution is to wipe out the local >> artifact! But you can only do that once you know there is something >> wrong. How do you detect that the artifact has changed? > >You don't have to, because released artifacts do not change[0]. > >[0]Unless someone intentionally screws up. And it is no accidental >screw up, I think all artifact managers forbid redeploying a non >snapshot version. So in order to that happen, someone must circunvent >the normal deploying route. If someone really needs to do so, then >that person may simply warn everyone that might be affected. That is >feasible, because such situation should never happen in any of the >public repositories, being limited to the organization repository. It doesn't require much of a screwup to create a changed release artifacts. For example, all it takes is a simple typo when uploading an artifact to your nexus repository. I did exactly this when trying to import a specific release of a package that isn't available on central and isn't built through maven. I ended up with releases in the repository with the wrong jar files attached, and by the time I noticed it was wrong people had already tried to build things using it, and I didn't realize that there was something I needed to warn about. Even if I did warn people, the overhead of everyone needing to read an email, figure out where they ran builds from, figure out what needs to be removed and remove the files from every machine that they might have worked on is huge. i.e. I intended to upload foox-1.2.jar as com.mycompany:foox:1.2 fooy-1.2.jar as com.mycompany:fooy:1.2 but I actually ended up with it switched fooy-1.2.jar as com.mycompany:foox:1.2 foox-1.2.jar as com.mycompany:fooy:1.2 I don't have control over the release cycle of these packages so I couldn't just declare a new release. Even after I fixed our central repository people were having problems building. Eventually we figured out what was going on, but it would have been far easier if maven could have actually told us that there was an inconsistency between the central repo and the .m2 directories. In the real world artifacts DO change. I've seen other people ask about this on the mailing list so I know I'm not the only one that has run into situations like this. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Project without main artifact
On 06/08/2010 2:48 PM, C. Benson Manica wrote: No, it's not a pom, its purpose is to go download other dependencies and repackage them nicely. So it does produce an artifact. What kind of Artifact? What exactly are you trying to do. Give enough detail so that someone can help you. BTW. It still could be a POM. It might use a plug-in to make something but I would just be guessing, wouldn't I. If you want to get help, you actually have to disclose some facts. If it is a secret, you need to hire a consultant and have him sign a non-disclosure after checking his references. not post to a public forum. Ron On Tue, Aug 3, 2010 at 4:49 PM, Anders Hammar wrote: A pom project? /Anders On Tue, Aug 3, 2010 at 16:22, C. Benson Manica wrote: Is it possible to configure a Maven project so that it doesn't build or deploy the main artifact? I have projects that are essentially shells to download and package dependencies, but there are no Java sources to compile or package as a jar (or anything else). Am I condemned to have empty jars deployed along with the artifacts I want, or are there configuration options that can address this? -- C. Benson Manica cbman...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Best way to get topologically sorted classpath?
I need (ultimately) a list of URLs corresponding to elements in a project's classpath, where that classpath has been sorted in dependency order. (I don't actually care if it's sorted "ascending" or "descending".) I need this for a mojo that I'm working on that will be run as part of an ear project's generate-resources phase. (Running mvn dependency:list or mvn dependency:build-classpath on such a project gets all the right jar files in there, but not in dependency order. That is, if the ear project depends on A which depends on B which depends on C, mvn dependency:list will return C before B.) I've noticed that Surefire seems to get this exactly right. If you look at the classpath when you're running a unit test, you'll notice that all dependencies are in that classpath and in proper topological order. But I can't see an easy way to inherit from or use Surefire simply for this purpose, nor, frankly, would I want to. What's the best/sanctioned way to get this information? Thanks, Laird
RE: force maven to redownload/refresh "released" dependencies
On Sex, 06 Ago 2010, "Haszlakiewicz, Eric" wrote: I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? You don't have to, because released artifacts do not change[0]. [0]Unless someone intentionally screws up. And it is no accidental screw up, I think all artifact managers forbid redeploying a non snapshot version. So in order to that happen, someone must circunvent the normal deploying route. If someone really needs to do so, then that person may simply warn everyone that might be affected. That is feasible, because such situation should never happen in any of the public repositories, being limited to the organization repository. -- Be circumspect in your liaisons with women. It is better to be seen at the opera with a man than at mass with a woman. -- De Maintenon Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On >On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric >wrote: > >> You're missing the point of what I'm asking. I'm not suggesting that >> maven make it possible or easy to *create* the violation. I'm >> suggesting that it should be able to *detect* the violation. >> >> I'm baffled as to why the maven community is so against the idea of >> having additional (optional) checks to detect problems. >> >> >Eric, > >The point is releases don't change. To "detect" means wasting bandwidth >comparing your supposedly unchanging released local artifacts to supposedly >unchanging released remote artifacts. If anything, writing a Maven plug-in >for this would be more appropriate, but I don't see your suggestion as part >of Maven core. Is it really going to be that much wasted bandwidth to download a few checksums? Can a plugin hook into the existing support for detecting changes in snapshots? eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
So you just want to verify? $ mvn --help usage: mvn [options] [] [] Options: -am,--also-makeIf project list is specified, also build projects required by the list -amd,--also-make-dependentsIf project list is specified, also build projects that depend on projects on the list -B,--batch-modeRun in non-interactive (batch) mode -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksums Warn if checksums don't match Kalle On Fri, Aug 6, 2010 at 1:01 PM, Haszlakiewicz, Eric wrote: >>-Original Message- >>From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] > On >> >>On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric >>wrote: >> >>> Please read the rest of the email thread. The short summary is: >>> Yes, I know what *should* happen, but the world isn't perfect and >>release >>> artifacts DO sometimes change. It is not absurd to be able to detect > and >>> recover from that kind of situation. >>> >>> >>The solution is to wipe out your local artifact. No one should be > updating >>released artifacts. If they do, they abused what a release means -- > hence >>the problem to begin with. The solution given is the only (correct) one > in >>Maven. > > I'm AGREEING with you that the solution is to wipe out the local > artifact! But you can only do that once you know there is something > wrong. How do you detect that the artifact has changed? > Maybe you'll get lucky and something is different enough in your > artifact that the build process fails. Or maybe you have some > regression testing that you'll do so you notice the problem. Having > maven compare the checksums seems like a much more reliable way to catch > these problems. > > eric > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
> On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric > wrote: > >> You're missing the point of what I'm asking. I'm not suggesting that >> maven make it possible or easy to *create* the violation. I'm >> suggesting that it should be able to *detect* the violation. >> >> I'm baffled as to why the maven community is so against the idea of >> having additional (optional) checks to detect problems. >> >> > Eric, > > The point is releases don't change. To "detect" means wasting bandwidth > comparing your supposedly unchanging released local artifacts to > supposedly > unchanging released remote artifacts. If anything, writing a Maven plug-in > for this would be more appropriate, but I don't see your suggestion as > part > of Maven core. Exactly what I suggested. If you really need this you will have to do it yourself. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On > >On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric >wrote: > >> Please read the rest of the email thread. The short summary is: >> Yes, I know what *should* happen, but the world isn't perfect and >release >> artifacts DO sometimes change. It is not absurd to be able to detect and >> recover from that kind of situation. >> >> >The solution is to wipe out your local artifact. No one should be updating >released artifacts. If they do, they abused what a release means -- hence >the problem to begin with. The solution given is the only (correct) one in >Maven. I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? Maybe you'll get lucky and something is different enough in your artifact that the build process fails. Or maybe you have some regression testing that you'll do so you notice the problem. Having maven compare the checksums seems like a much more reliable way to catch these problems. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric wrote: > You're missing the point of what I'm asking. I'm not suggesting that > maven make it possible or easy to *create* the violation. I'm > suggesting that it should be able to *detect* the violation. > > I'm baffled as to why the maven community is so against the idea of > having additional (optional) checks to detect problems. > > Eric, The point is releases don't change. To "detect" means wasting bandwidth comparing your supposedly unchanging released local artifacts to supposedly unchanging released remote artifacts. If anything, writing a Maven plug-in for this would be more appropriate, but I don't see your suggestion as part of Maven core. Paul
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org] > >Eric, you're not going to win this one. It's part of the philosophy of >Maven. It's also good practice. > >Give it up. > >I'm not going to fight the site generation being split out of Maven. I >think I understand Jason's point on that, though I disagree. And that's a >*much* less nasty violation of Maven's perceived function, if in fact, it >is a violation. > >What you're wanting is a violation. You're missing the point of what I'm asking. I'm not suggesting that maven make it possible or easy to *create* the violation. I'm suggesting that it should be able to *detect* the violation. I'm baffled as to why the maven community is so against the idea of having additional (optional) checks to detect problems. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
I second this! I've used Artifactory and liked it. (I somewhat prefer Nexus, at least the last time I looked at Artifactory.) -K On Aug 6, 2010, at 1:47 PM, Yoav Landman wrote: > You may want to take a look at the CI integration in Artifactory - > http://wiki.jfrog.org/confluence/display/RTF/Build+Integration > You can get a json object with a report of all this information captured at > build time: detailed build environment information, published artifacts and > resolved dependencies of all scopes. > Like many have commented here, re-downloading cached release artifacts if > you run your build from scratch should be done from the caches of your repo > manager. > > Yoav > > On Sat, Jul 31, 2010 at 12:07 AM, Shan Syed wrote: > >> no, this isn't in regard to our own published artifacts >> >> I regret starting this thread, I apologize >> I didn't mean this question to be an affront to maven conventions - I just >> need to figure out a better way to capture a full log >> they even want a log of how the build environment was downloaded and >> installed >> >> >> On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict >> wrote: >> >>> There is a maxim to follow when deploying: "do not redeploy a version >> more >>> than once". Once you deploy version X.Y.Z, it should never be updated, >> and >>> those who download it never need to download it again. So, back to the >>> original problem, are you guys doing that? >>> >>> On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: >>> it only applies to our final release cuts, not our day-to-day just once for this project really; I wanted to insert such this switch >>> (if existed) in our "delivery build" profile we use archiva for everything else, and actually only make use of >> public maven repositories when we up a version of our dependencies, which is >>> rare because of change control it's all weird stuff, I know, but sometimes I just don't question it On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: >>> deleting the m2 works, I was just curious to see if there was a >>> switch > in >>> maven to force all downloads again >> >> This makes absolutely no sense, doesn't change your BOM, and is >> just >> wasteful. Consumes bandwidth unnecessarily from a resource that is being >> used by the whole Maven community. > > I'd think that if you had enough developers doing this on every > machine on a consistent basis (eg every build), it might add up to > enough traffic to get you on a blacklist somewhere... You really need > to install Nexus or another MRM, this is just plain dumb. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > >>> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Project without main artifact
No, it's not a pom, its purpose is to go download other dependencies and repackage them nicely. On Tue, Aug 3, 2010 at 4:49 PM, Anders Hammar wrote: > A pom project? > > /Anders > > On Tue, Aug 3, 2010 at 16:22, C. Benson Manica wrote: > > > Is it possible to configure a Maven project so that it doesn't build or > > deploy the main artifact? I have projects that are essentially shells to > > download and package dependencies, but there are no Java sources to > compile > > or package as a jar (or anything else). Am I condemned to have empty > jars > > deployed along with the artifacts I want, or are there configuration > > options > > that can address this? > > > > -- > > C. Benson Manica > > cbman...@gmail.com > > > -- C. Benson Manica cbman...@gmail.com
Re: force maven to redownload/refresh "released" dependencies
You may want to take a look at the CI integration in Artifactory - http://wiki.jfrog.org/confluence/display/RTF/Build+Integration You can get a json object with a report of all this information captured at build time: detailed build environment information, published artifacts and resolved dependencies of all scopes. Like many have commented here, re-downloading cached release artifacts if you run your build from scratch should be done from the caches of your repo manager. Yoav On Sat, Jul 31, 2010 at 12:07 AM, Shan Syed wrote: > no, this isn't in regard to our own published artifacts > > I regret starting this thread, I apologize > I didn't mean this question to be an affront to maven conventions - I just > need to figure out a better way to capture a full log > they even want a log of how the build environment was downloaded and > installed > > > On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict > wrote: > > > There is a maxim to follow when deploying: "do not redeploy a version > more > > than once". Once you deploy version X.Y.Z, it should never be updated, > and > > those who download it never need to download it again. So, back to the > > original problem, are you guys doing that? > > > > On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: > > > > > it only applies to our final release cuts, not our day-to-day > > > just once for this project really; I wanted to insert such this switch > > (if > > > existed) in our "delivery build" profile > > > we use archiva for everything else, and actually only make use of > public > > > maven repositories when we up a version of our dependencies, which is > > rare > > > because of change control > > > > > > it's all weird stuff, I know, but sometimes I just don't question it > > > > > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: > > > > > > > >> deleting the m2 works, I was just curious to see if there was a > > switch > > > > in > > > > >> maven to force all downloads again > > > > > > > > > > This makes absolutely no sense, doesn't change your BOM, and is > just > > > > > wasteful. Consumes bandwidth unnecessarily from a resource that is > > > being > > > > > used by the whole Maven community. > > > > > > > > I'd think that if you had enough developers doing this on every > > > > machine on a consistent basis (eg every build), it might add up to > > > > enough traffic to get you on a blacklist somewhere... You really need > > > > to install Nexus or another MRM, this is just plain dumb. > > > > > > > > Wayne > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > > >
Re: force maven to redownload/refresh "released" dependencies
On Aug 6, 2010, at 1:00 PM, Haszlakiewicz, Eric wrote: >> -Original Message- >> From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] >> >> On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric >> wrote: -Original Message- >>> I don't (yet) know much about the internals of maven, but is it really >>> that much of an impact on the code? There's already support present for >>> checking for differences in snapshot versions, right? I'm imagining >>> that making it work for release artifacts would be a matter of not >>> distinguishing between release and snapshot artifacts and having the >>> check apply to both. >>> It sounds like you think it'll be harder to do than that; what I am >>> missing? >> >> What you are asking is absurd. That's the exact difference between >> snapshots and releases; snapshots should be updated and releases >> shouldn't. Why would you insist on removing this differentiation? >> Wouldn't it be easier for you to just use snapshots if you need to >> check for updates? > > Please read the rest of the email thread. The short summary is: > Yes, I know what *should* happen, but the world isn't perfect and release > artifacts DO sometimes change. It is not absurd to be able to detect and > recover from that kind of situation. Eric, you're not going to win this one. It's part of the philosophy of Maven. It's also good practice. Give it up. I'm not going to fight the site generation being split out of Maven. I think I understand Jason's point on that, though I disagree. And that's a *much* less nasty violation of Maven's perceived function, if in fact, it is a violation. What you're wanting is a violation. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Aug 6, 2010, at 12:57 PM, Kalle Korhonen wrote: > On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric > wrote: >>> -Original Message- >> I don't (yet) know much about the internals of maven, but is it really >> that much of an impact on the code? There's already support present for >> checking for differences in snapshot versions, right? I'm imagining >> that making it work for release artifacts would be a matter of not >> distinguishing between release and snapshot artifacts and having the >> check apply to both. >> It sounds like you think it'll be harder to do than that; what I am >> missing? > > What you are asking is absurd. That's the exact difference between > snapshots and releases; snapshots should be updated and releases > shouldn't. Why would you insist on removing this differentiation? > Wouldn't it be easier for you to just use snapshots if you need to > check for updates? What Katie (and others) said! I have my differences with the current Maven philosophy, but one thing that has been baked in from the beginning is that artifact coordinates imply a fixed thing. The artifact does not change. That's one of the *points* of Maven. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>>-Original Message- >>From: Manfred Moser [mailto:manf...@mosabuam.com] >> >>It seems like we will not agree here. The changes necessary and the >>additional overhead to make your suggestions work have to much of a >>negative impact imho. I cant see your feature getting implemented by >>anybody. Your only option is to implement it yourself and see how you >>fare. If you do it as a plugin that does the check you want you might > get >>traction with other users. > > I don't (yet) know much about the internals of maven, but is it really > that much of an impact on the code? There's already support present for > checking for differences in snapshot versions, right? I'm imagining > that making it work for release artifacts would be a matter of not > distinguishing between release and snapshot artifacts and having the > check apply to both. > It sounds like you think it'll be harder to do than that; what I am > missing? It might be easy to he do but I have a feeling you will not be liked by the community. By doing this in your own plugin or forked codebase you will by merely running it put a large additional strain and the public and shared infrastructure like maven central and others. You will not get any good will and might end up getting blocked by central. I really suggest you drop this idea and adopt a proper process or move to a different tool. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: parallel execution of (test) modules
It sounds like the maven3 parallel build feature would help you out on this, https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in +Maven+3. There is also the -fae option that could be used to proceed even with failing tests, which also works for serial builds. As for the aggregation I'm not sure, but I'm sure something could parse the report files under target/surefire-reports. Kristian fr., 06.08.2010 kl. 14.23 +0200, skrev torsten.reinh...@gi-de.com: > Hi, > > we have a lot of independent "integration tests", based on testNG - > separated in different modules: > > TS_01_\pom.xml > TS_02_\pom.xml > TS_03_\pom.xml > > > During developing phase, each module is executed by dedicated developers > so each one just focuses on his own module. > During release phase, I want to execute all tests and get an aggregated > test-results view. > > Executing them sequentially, for example in a multi-module build won´t > work, > because the build will break at the moment the first integration-test > module fails. > Further, the execution time of some test modules is about some hours - so > I need to execute them parallel. > > => How can I execute those modules in parallel and get an aggregated view? > > > Thanx, Torsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric wrote: > Please read the rest of the email thread. The short summary is: > Yes, I know what *should* happen, but the world isn't perfect and release > artifacts DO sometimes change. It is not absurd to be able to detect and > recover from that kind of situation. > > The solution is to wipe out your local artifact. No one should be updating released artifacts. If they do, they abused what a release means -- hence the problem to begin with. The solution given is the only (correct) one in Maven. Paul
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] > >On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric > wrote: >>>-Original Message- >> I don't (yet) know much about the internals of maven, but is it really >> that much of an impact on the code? There's already support present for >> checking for differences in snapshot versions, right? I'm imagining >> that making it work for release artifacts would be a matter of not >> distinguishing between release and snapshot artifacts and having the >> check apply to both. >> It sounds like you think it'll be harder to do than that; what I am >> missing? > >What you are asking is absurd. That's the exact difference between >snapshots and releases; snapshots should be updated and releases >shouldn't. Why would you insist on removing this differentiation? >Wouldn't it be easier for you to just use snapshots if you need to >check for updates? Please read the rest of the email thread. The short summary is: Yes, I know what *should* happen, but the world isn't perfect and release artifacts DO sometimes change. It is not absurd to be able to detect and recover from that kind of situation. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric wrote: >>-Original Message- > I don't (yet) know much about the internals of maven, but is it really > that much of an impact on the code? There's already support present for > checking for differences in snapshot versions, right? I'm imagining > that making it work for release artifacts would be a matter of not > distinguishing between release and snapshot artifacts and having the > check apply to both. > It sounds like you think it'll be harder to do than that; what I am > missing? What you are asking is absurd. That's the exact difference between snapshots and releases; snapshots should be updated and releases shouldn't. Why would you insist on removing this differentiation? Wouldn't it be easier for you to just use snapshots if you need to check for updates? Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Manfred Moser [mailto:manf...@mosabuam.com] > >It seems like we will not agree here. The changes necessary and the >additional overhead to make your suggestions work have to much of a >negative impact imho. I cant see your feature getting implemented by >anybody. Your only option is to implement it yourself and see how you >fare. If you do it as a plugin that does the check you want you might get >traction with other users. I don't (yet) know much about the internals of maven, but is it really that much of an impact on the code? There's already support present for checking for differences in snapshot versions, right? I'm imagining that making it work for release artifacts would be a matter of not distinguishing between release and snapshot artifacts and having the check apply to both. It sounds like you think it'll be harder to do than that; what I am missing? eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Problem with uniqueVersion=false in 3.0 beta1
We have a local repo manager and it still takes a fixed amount of time per artifact. It would take a few minutes to totally rebuild a local repo as we have a fair number (hundreds) of artifacts, and Maven itself requires a bunch of plugins just to get started. Granted I could just delete my group from the local repo tree to speed things up, but I don't understand why we need to do this when the SNAPSHOT notion seemed to work just fine for us. The SNAPSHOT version was useful and I'm not sure why it was taken out in M3. -Original Message- From: Brian Fox [mailto:bri...@infinity.nu] Sent: Friday, August 06, 2010 11:42 AM To: Maven Users List Subject: Re: Problem with uniqueVersion=false in 3.0 beta1 No, but with a repo manager, it's pretty quick to wipe the local and refetch everything cleanly from the local network. On Fri, Aug 6, 2010 at 10:31 AM, Adam Krieg wrote: > Is the local repository smart enough to clear out the old snapshots? I'm > worried about tons of irrelevant artifacts. > > -Original Message- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Thursday, July 15, 2010 4:00 PM > To: Maven Users List > Subject: Re: Problem with uniqueVersion=false in 3.0 beta1 > > You recall correctly, uniqueSnapshots will always be true for M3 > irrespective of what you try to set it to > > -Stephen > > P.S. I don't understand exactly why... I think it has something to do with > Repository managers being sufficiently good that they can reclaim the disk > space for you so the non-unique is no longer required. > > On 15 July 2010 20:28, Anders Hammar wrote: > >> IIRC Maven 3 only supports unique versioned snapshots (currently). There >> was >> some discussion easlier here on the mailing list regarding that. Search >> some >> archive for more info. >> >> /Anders >> >> On Thu, Jul 15, 2010 at 21:24, Adam Krieg >> wrote: >> >> > I'm trying to configure Maven to not create unique snapshots. >> > >> > When using the following settings in Maven 2.2.1, this works: >> > >> > >> >false >> > >> > >> > >> > However when I run with Maven 3.0 beta 1, I get autogenerated numbers >> > appended, as if uniqueVersion was true. >> > >> > >> > Is anyone else seeing this behavior? >> > >> > Disclaimer: http://pragmatrading.com/disclaimer.html >> > >> > > Disclaimer: http://pragmatrading.com/disclaimer.html > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Disclaimer: http://pragmatrading.com/disclaimer.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with uniqueVersion=false in 3.0 beta1
No, but with a repo manager, it's pretty quick to wipe the local and refetch everything cleanly from the local network. On Fri, Aug 6, 2010 at 10:31 AM, Adam Krieg wrote: > Is the local repository smart enough to clear out the old snapshots? I'm > worried about tons of irrelevant artifacts. > > -Original Message- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Thursday, July 15, 2010 4:00 PM > To: Maven Users List > Subject: Re: Problem with uniqueVersion=false in 3.0 beta1 > > You recall correctly, uniqueSnapshots will always be true for M3 > irrespective of what you try to set it to > > -Stephen > > P.S. I don't understand exactly why... I think it has something to do with > Repository managers being sufficiently good that they can reclaim the disk > space for you so the non-unique is no longer required. > > On 15 July 2010 20:28, Anders Hammar wrote: > >> IIRC Maven 3 only supports unique versioned snapshots (currently). There >> was >> some discussion easlier here on the mailing list regarding that. Search >> some >> archive for more info. >> >> /Anders >> >> On Thu, Jul 15, 2010 at 21:24, Adam Krieg >> wrote: >> >> > I'm trying to configure Maven to not create unique snapshots. >> > >> > When using the following settings in Maven 2.2.1, this works: >> > >> > >> > false >> > >> > >> > >> > However when I run with Maven 3.0 beta 1, I get autogenerated numbers >> > appended, as if uniqueVersion was true. >> > >> > >> > Is anyone else seeing this behavior? >> > >> > Disclaimer: http://pragmatrading.com/disclaimer.html >> > >> > > Disclaimer: http://pragmatrading.com/disclaimer.html > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: A use case for non-constant artifact ids
Hey Frank, The Maven provided solution for your situation is 'classifiers'. You are building a single artifact for multiple classes of compiler. I know about classifiers and I completely agree that they might have been a better solution to express this. Unfortunately that doesn't change the fact that Scala projects are already built this way (although most are built by sbt and not Maven these days, I think) and potential users would probably expect my library to work like that too. In the language of Maven, "non-constant artifact ids" is an oxy-moron. I agree that using that expression was probably not the smartest thing I did today :) However, it's not really as if the artifact id varies for the same artifact. Once you deployed it, it stays the same of course. It's just that artifacts built from future versions of the same codebase might have a different id than the current ones. But it doesn't matter all that much. Maybe I could just use a classifier and educate my users about this deviation from the Scala/sbt-way. All I'm doing here is presenting an argument for keeping things the way they are, especially since I can't see any harm in it. By the way, I dug up some information on this from the sbt documentation: http://code.google.com/p/simple-build-tool/wiki/CrossBuild It doesn't say anything about classifiers though. Maybe there were good reasons for not using them, maybe not. Regards, Hanno On 08/06/2010 04:09 PM, Gorham-Engard, Frank wrote: Hi Hanno The Maven provided solution for your situation is 'classifiers'. You are building a single artifact for multiple classes of compiler. In the language of Maven, "non-constant artifact ids" is an oxy-moron. The 'Id' part of this field label stands for 'identifier'. An identifier is, by nature, a constant. You don't have a different birthday when you where different shoes. Your birthday is one piece of identifying information about you. The intention in Maven is for the GroupId and ArtifactId to be identifiers. This affects the dependency resolution, storage, acquisition processes that Maven uses. Notice that 'version' and 'classifier' are not labeled 'Ids'. These are where your variations can be registered.
RE: Problem with uniqueVersion=false in 3.0 beta1
Is the local repository smart enough to clear out the old snapshots? I'm worried about tons of irrelevant artifacts. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Thursday, July 15, 2010 4:00 PM To: Maven Users List Subject: Re: Problem with uniqueVersion=false in 3.0 beta1 You recall correctly, uniqueSnapshots will always be true for M3 irrespective of what you try to set it to -Stephen P.S. I don't understand exactly why... I think it has something to do with Repository managers being sufficiently good that they can reclaim the disk space for you so the non-unique is no longer required. On 15 July 2010 20:28, Anders Hammar wrote: > IIRC Maven 3 only supports unique versioned snapshots (currently). There > was > some discussion easlier here on the mailing list regarding that. Search > some > archive for more info. > > /Anders > > On Thu, Jul 15, 2010 at 21:24, Adam Krieg > wrote: > > > I'm trying to configure Maven to not create unique snapshots. > > > > When using the following settings in Maven 2.2.1, this works: > > > > > >false > > > > > > > > However when I run with Maven 3.0 beta 1, I get autogenerated numbers > > appended, as if uniqueVersion was true. > > > > > > Is anyone else seeing this behavior? > > > > Disclaimer: http://pragmatrading.com/disclaimer.html > > > Disclaimer: http://pragmatrading.com/disclaimer.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: A use case for non-constant artifact ids
Hi Hanno The Maven provided solution for your situation is 'classifiers'. You are building a single artifact for multiple classes of compiler. In the language of Maven, "non-constant artifact ids" is an oxy-moron. The 'Id' part of this field label stands for 'identifier'. An identifier is, by nature, a constant. You don't have a different birthday when you where different shoes. Your birthday is one piece of identifying information about you. The intention in Maven is for the GroupId and ArtifactId to be identifiers. This affects the dependency resolution, storage, acquisition processes that Maven uses. Notice that 'version' and 'classifier' are not labeled 'Ids'. These are where your variations can be registered.
A use case for non-constant artifact ids
Hi everyone,
when I build my project, Maven tells me the following:
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for com.hannobraun:scalable-dynamics_2.8.0:jar:0.3-SNAPSHOT
[WARNING] 'artifactId' contains an expression but should be a constant.
@ com.hannobraun:scalable-dynamics_${scala.version}:0.3-SNAPSHOT,
/home/hanno/Projects/ScalableDynamics/pom.xml
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
I think the ability to have an expression in the artifactId is very
useful for Scala projects built with Maven.
Due to binary incompatibility between code that was compiled with
different versions of the Scala compiler, Scala projects have adopted
the convention of adding the Scala version used to the artifact id. See
this for example: http://mvnrepository.com/artifact/org.scala-tools.testing
Due to the ability to use an expression in the artifact id I can do
something like this:
2.8.0
scalable-dynamics_${scala.version}
...
org.scala-lang
scala-library
${scala.version}
org.scala-tools.testing
specs_${scala.version}
1.6.5
test
This approach is pretty much error-proof and low-maintenance. Requiring
a constant artifactId would introduce the possibility of errors every
time I update to another Scala version.
While I understand the notion of wanting to restrict what a user can do
for safety reasons, I think it would be a shame to take power away from
the users. You'll never be able to anticipate what kind of productive
uses people will find for this power.
Regards,
Hanno
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: plugin descriptor missing mojos section
Just for the record, here's the solution if anyone else were to encounter
this:
My mistake was to do with basic annotation syntax:
In the header of my Mojo class, I had:
/**
* This goal will process a ...
*
* @goal metadatagenerator
* @phase compile
* @author Pankaj Tandon
*
*
/
/**
* This class is modified from the Ant Task ...
*
*/
public class MetadataMojo extends AbstractMojo {
...
Instead of
/**
* This goal will process a ...
*
* @goal metadatagenerator
* @phase compile
* @author Pankaj Tandon
*
* This class is modified from the Ant Task ...
*
*/
public class MetadataMojo extends AbstractMojo {
...
The extra block of comments threw my annotations off kilter and I did not
get the plugin descriptor generated correctly.
I introduced this comment before site generation and therefore the wild
goose chase.
Hope this helps somebody :)
Pankaj
--
View this message in context:
http://maven.40175.n5.nabble.com/plugin-descriptor-missing-mojos-section-tp2265972p2266613.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
parallel execution of (test) modules
Hi, we have a lot of independent "integration tests", based on testNG - separated in different modules: TS_01_\pom.xml TS_02_\pom.xml TS_03_\pom.xml During developing phase, each module is executed by dedicated developers so each one just focuses on his own module. During release phase, I want to execute all tests and get an aggregated test-results view. Executing them sequentially, for example in a multi-module build won´t work, because the build will break at the moment the first integration-test module fails. Further, the execution time of some test modules is about some hours - so I need to execute them parallel. => How can I execute those modules in parallel and get an aggregated view? Thanx, Torsten
Re: maven-release-plugin: Accessing version numbers from custom mojos during a run goal
On 06/08/2010, at 9:12 PM, Mark Derricutt wrote:
> Hey all,
>
> I'm wanting to write a mojo to run as part of my release process ( by
> declaring it in the element of the release plugin, but I
> want to know the release version, and the next-release version as used by
> the release plugin.
The release version will be ${project.version} at that point.
>
> Are these values stored in any system parameters at all? It doesn't look
> like they're stored in the release.properties file and even if they were, I
> don't like the idea of just assuming this file will exist.
Not in sys properties, but I would have thought they were in release.properties
(probably several of them, per module). I'm not sure why you wouldn't be
comfortable reading that since it has to be there (it's certainly an
implementation leak, but not one that seems likely to change).
Other than that, I think you'd need to change the release plugin to pass them
to the preparation goals as a system property (though again there's the
difficulty of potentially not being the same for every module).
- Brett
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
maven-release-plugin: Accessing version numbers from custom mojos during a run goal
Hey all, I'm wanting to write a mojo to run as part of my release process ( by declaring it in the element of the release plugin, but I want to know the release version, and the next-release version as used by the release plugin. Are these values stored in any system parameters at all? It doesn't look like they're stored in the release.properties file and even if they were, I don't like the idea of just assuming this file will exist. Any pointers? -- Pull me down under...
Re: Releasing only one (sub)module within an SCM tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/2010 10:53 AM, Olivier Lamy wrote: > Hi, > Do you have a scm element in your module ? I tried it. At the moment I just have an scm element in my parent. > Just to be sure your tree is similar to : > http://github.com/olamy/scm-git-test ? > And you want to release only my-app ? Yes, exactly. That is the scenario. Now I just want to remove the modules section from the parent... > By the way it could be fixed if there was a way to do something like > git clone g...@github.com:olamy/scm-git-test.git/my-app Yes. But that is not possible... (Un)fortunately... Maven is build with Subversion in mind... Therefore the problems. Johannes > > Or doing some hackhish stuff for git in the release plugin. > > Can you load an issue on this ? (IHMO it looks to be reasonnable to > add hack for such case) > > 2010/8/5 Johannes Schneider : > Hi, > > I have such a structure within my Git tree: > > daParent >- moduleA >- moduleB >- ... > > Until today I released all modules together. This worked like a charm. > > Now I want to release the modules independently. But that does not work. > > I have removed the "modules" section from "daParent" and have been able > to release that artifact successfully. > Now I upgraded the parent version within moduleA and moduleB manually. > > But releasing moduleA does *not* work now. > > > release:prepare works as expected, but release:perform checks out the > the tagged version and tries to release "/pom.xml". > Of course this pom is the pom of "daParent"... > > Since I am using Git I can't simply add a corrected scm tag to moduleA > and moduleB... > > > So how could I solve that? I experimented with > -DpomFileName=moduleA/pom.xml but that did not work > Any ideas are welcome... > > > > Thanks, > > Johannes > > >> - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org >> >> - -- Johannes Schneider - blog.cedarsoft.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJMW9wwAAoJEAytD9R7Qv6dhWoH/j+KXnAlzOIwSqAXjQzvIrJn B3VVp61ltm5kBLpl63aP0sIrWMde7QboSfcTjnsl5KA1NXvTm2XaybpNnmyJVXQs YTI1J2h7/BoCIxeSzdN02mB6ptjZIkDwcAgjZkhUNTA41Q+3CoKE2lVwpYcjdTj8 /gc0qj72Tfxw6SgzxVo5uWTxf7TPLxoXshFFAkj8xXtkpYEfUxvu0mlf/VZYVJp4 ZWlBtD6u9kldNgfWtSEp3JJiLEeSi8PW3Ym8vQCVeAh5UAgzqtiTns5NPJEbE4vv Tf46HLx55RY6nNI5XmbDr5xLzGMeIVbV3ehobsz9msZzqatmq9FIiTpFLut13b0= =eAyX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Releasing only one (sub)module within an SCM tree
Hi, Do you have a scm element in your module ? Just to be sure your tree is similar to : http://github.com/olamy/scm-git-test ? And you want to release only my-app ? By the way it could be fixed if there was a way to do something like git clone g...@github.com:olamy/scm-git-test.git/my-app Or doing some hackhish stuff for git in the release plugin. Can you load an issue on this ? (IHMO it looks to be reasonnable to add hack for such case) 2010/8/5 Johannes Schneider : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > I have such a structure within my Git tree: > > daParent > - moduleA > - moduleB > - ... > > Until today I released all modules together. This worked like a charm. > > Now I want to release the modules independently. But that does not work. > > I have removed the "modules" section from "daParent" and have been able > to release that artifact successfully. > Now I upgraded the parent version within moduleA and moduleB manually. > > But releasing moduleA does *not* work now. > > > release:prepare works as expected, but release:perform checks out the > the tagged version and tries to release "/pom.xml". > Of course this pom is the pom of "daParent"... > > Since I am using Git I can't simply add a corrected scm tag to moduleA > and moduleB... > > > So how could I solve that? I experimented with > - -DpomFileName=moduleA/pom.xml but that did not work > Any ideas are welcome... > > > > Thanks, > > Johannes > > > - -- > Johannes Schneider - blog.cedarsoft.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJMWx9FAAoJEAytD9R7Qv6dfCYIAMPeb9WfTX4hntgj6CnNwXUw > 8/CnY2KgSBadoPDGW4zSF+XS2/RyosU9gmmBYyNyqfKm/fMoI/DrXp3KOG4SZ7a7 > owX3QMBRPRPqOGXT8z9kp9rOVYY5HodZXHmbU7GKuMpNFgYz9zIPpscFWS+1ohhT > 2szO2OMPfPsSBgq3Py6rchQXZigMD+dLB2lTrjdZ9jApo1b4ZlrnQDAZEnWCHhki > E5tVBTRyCRMwTEDFdsdr0lX9LLX9gn/8ViOTayS5gnd/PxaftRRfSrmKltPDwygw > GbrmgQGtXi+/OnOX2tRfllYUqsoPrANzMEFvE5mTq44p45Q75bNZ8dtbm3+KgdY= > =/OF4 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy http://www.viadeo.com/fr/profile/olivier.lamy7 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven deploy plugin
All mentioned projects inherit from the same parent-POM. I have several maven project which produce small (50k-300k) JAR files. All of these deploy fine to Archiva. I have one maven project that is similar in structure to all the rest that produces a 2M JAR. This project will not deploy to Archiva. It exits with the following exception: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.4:deploy (default-deploy) on project nielsenUtilities: Error deploying artifact: Transfer error: The server did not respond within the configured timeout. -> [Help 1] I have searched far and wide for a reason/explanation/fix for this error. Has anyone encountered such an issue? I am thinking that it is some kind of timeout on the maven side. Maven does not receive a response within a "reasonable" amount of time, and exits as though it were an error. -- View this message in context: http://maven.40175.n5.nabble.com/maven-deploy-plugin-tp2265826p2265826.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
