Re: Two instances of Continuum
We have two instances running, because one needs to build with java 1.4 and the other one with 1.5. (I couldn't convince all the developers that with the 1.5 java version you can specify that it needs to output 1.4 classes, even minor version was supposed to be the same as on the production machine (1.4.2_05), sorry, just a little rant) As long as you change the ports, you can have a lot of continuums running on one machine. Hth, Nick Stolwijk Lee Meador wrote: Can you run two instances of continuum on the same server if you change the two ports? Is there anything special that needs to be configured to make this work? Thanks. -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
Re: Two instances of Continuum
On 4/11/07, Lee Meador [EMAIL PROTECTED] wrote: Can you run two instances of continuum on the same server if you change the two ports? Is there anything special that needs to be configured to make this work? Consider whether you want the two instances to share a local repository. You might want to run them as different users or otherwise separate them. -- Wendy
Provider message: No such provider: 'mks'
Hi all, I am trying to run the continuum with the MKS (http://www.mks.com) scm, We have developed the maven scm-provider for the mks...and put in to .m2 local repository. However building fails with error: Provider message: No such provider: 'mks'. Any clue? Thanks, Nirav -- View this message in context: http://www.nabble.com/Provider-message%3A-No-such-provider%3A-%27mks%27-tf3563600.html#a9953475 Sent from the Continuum - Users mailing list archive at Nabble.com.
Maven users in the industry
Hi, Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? Thanks for your help. Gilles -- View this message in context: http://www.nabble.com/Maven-users-in-the-industry-tf3557876s177.html#a9934912 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and 3rd Party Libraries
Fong Chan wrote: Hello all, I am having some problems with Maven right now. Just to give some background. I currently have installed all of Taverna's (A workflow management system that uses Maven) classes into the Maven repository and I am able to use them no problem. For one of my programs, I would like to use Taverna's class and also another external library called Jakarta POI (able to manipulate Excel from Java). The thing is the POI downloads do not come in a maven format and make it different to install them into the repository easily. So instead, I have imported them as external jars in eclipse. Finding the right groupId and artifactId for your dependencies is a bit hard but for POI take a look at http://repo1.maven.org/maven2/poi/poi/. I used it in a previous project just fine. If the .jar you want to use is not available in any public repo the only option you have is to either import it into your local repo or setup your own repository. -dirk -- A: Maybe because some people are too annoyed by top-posting. Q: Why do I not get an answer to my question(s)? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Exclude some classes when package a jar.
All, I have a jar project. When packaging, I want some specified class excuded from the jar file. How should I do ? Thanks for any suggestions!
Re: incorrect dependencies in assembly
I'm just coming back to look at this. I'm interested to know whether my question did not make sense or whether no-one has the answer. Please help if you can. Regards, Kelvin. On 21/03/07, kelvin goodson [EMAIL PROTECTED] wrote: I have a reactor build pom (correct terminology?) which specifies a test-scope dependency on junit:junit at version 3.8.1 and a provided-scope dependency on asm (see effective-pom.xml attachment produced with mvn help:effective-pom) The assembly descriptor for creating my release (http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/sdo.xml?view=markup)http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/sdo.xml?view=markuphas a moduleSet which is used to collect together the artifacts from the modules along with their dependencies. I can not for the life of me understand why my packaged archive that results from the assembly descriptor includes the junit and asm jars. Any clues on how to track down why this is happening and/or to block the included dependency would be most welcome. -- TIA Kelvin.
apidocs continuum broken links
hi i use maven2 and continuum 1.0.3 when i generate site from continuum it works fine apart from genereting the correct links in my apidocs. i can find my site here: http://192.168.16.246:8080/continuum/servlet/browse?file=14/target/site/project-reports.html javadocs here: http://192.168.16.246:8080/continuum/servlet/browse?file=14/target/site/apidocs/index.html but the frames are broken they point to: http://192.168.16.246:8080/continuum/servlet/file=14/target/site/apidocs/index.html thanks, tibi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven-assembly-plugin] How to exclude transitive dependencies of an included dependency
Hi all,
I use maven-assembly-plugin to assemble my project. My project contains some
modules.
A module myModule contains a dependency with scope=provided
(myDependencyProvided). This module as a
specific packaging (not a jar, war, ...): myPackaging
I will wish to add to my assembly this module with only its dependency
provided (I don't wish to add all
other dependencies and all transitive dependencies).
My assembly descriptor is something like:
moduleSet
includes
includemyModule/include
/includes
binaries
outputDirectory//outputDirectory
unpackfalse/unpack
fileMode755/fileMode
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
dependencySets
dependencySet
scopeprovided/scope
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
includes
includemyDependencyProvided:myPackaging/include
/includes
/dependencySet
/dependencySets
/binaries
/moduleSet
How can I exclude transitive dependencies of an include dependency ? Is it the
right way to build this
assembly type ?
Can you help me, please?
_
Christophe DENEUX / Capgemini Sud / Méditerranée
Technical Leader
Tel: + 33 4 93 95 55 92 / www.capgemini.com
Porte de l'Arénas - Entrée B / 455 Promenade des
Anglais / 06200 Nice
Join the Collaborative Business Experience
_
Please consider the environment and do not print
this email unless absolutely necessary. Capgemini
encourages environmental awareness.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven users in the industry
I know 2 companies in Belgium that use Maven (one of them still Maven 1.x), but I don't know if I can put their names up. But it is used in Belgium :) regards, Wim 2007/4/11, Gilles Scokart [EMAIL PROTECTED]: Hi, Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? Thanks for your help. Gilles -- View this message in context: http://www.nabble.com/Maven-users-in-the-industry-tf3557876s177.html#a9934912 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Vigilog - an open source log file viewer: http://vigilog.sourceforge.net Blog: http://www.jroller.com/page/Fester
Re: Maven users in the industry
On 4/11/07, Gilles Scokart [EMAIL PROTECTED] wrote: Hi, Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? You should ask the BeJUG. I am sure they can give you some numbers. I remember seeing more than 30 persons on a talk on maven cruisecontrol last year. Most if not all of them were already using maven. Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven users in the industry
Or you could quote my customer: A Danish banking IT services central with 160+ smaller banks within the Nordic region. They have been using Maven 1 for several years and recently switched to Maven 2. The applications cover Internet and intranet applications with well over 600 artifacts and 28 custom plugins. The main reasons behind using m1 in the first place was uniform projects, central repository and dependency management. Switching to m2 was done to use a 'supported' tool (that is, stuff happening here), faster build cycle (no scripts!) even more simple dependency management and better reporting facilities. Debugging our custom plugins proved invaluable, and saved quite a lot of time compared to the old jelly scripts of the m1 days. /Niels - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 plugin for Cactus
2007/4/11, Sambit Bharimalla [EMAIL PROTECTED]: Hi, I have developed a J2EE project. I have choosen Maven2 for automation build process. My J2EE project involves some incontainer test cases written in Cactus. I need suggestion if following is possible or not. I want to - i- compile the code ii- test out of container test cases iii- build ear iv- deploy the ear. (I ve separate scripts for deploying the ear) v- run the incontainer test cases. Any pointer how to achieve point # 5. Has cactus provided plugin for Maven2. I searched net a lot. but didnt get any definite answer. -- Thanks Regards Sambit Sambit hi, Me and the rest of the Cactus team are currently involved in moving Cactus in the incubator where we will develop the new maven2 build system and the Cactus-m2-plugin. I will try to answer to your questions below: 1) Yes you can compile your code with maven (see compiler plugin) 2) as well as run all of the out-of-container test cases like JUnit, TestNG, ... (see the corresponding plugin) 3) and eventually build jar/war/ear/(see the corresponding plugin) 4) For deploying the archive you may consider using Cargo ( cargo.codehaus.org) - it is possible to start/stop/deploy artifacts in a large variety of containers. 5) Currently the cactus-m2 plugin is able to cactify your package and merge your webxmls. When the project is moved in the incubator we will consider finishing the plugin. If you are interested in helping, that will be a good thing. Hope that helped! -- Regards, Petar! Karlovo, Bulgaria. Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
Re : Maven users in the industry
Hi, Here at Capgemini France, we are using Maven 2 + Continuum for a while. I don't know exactly the amount of people using it in the group, but I think most of the new J2EE projects use Maven. ++ Julien - Message d'origine De : Gilles Scokart [EMAIL PROTECTED] À : users@maven.apache.org Envoyé le : Mercredi, 11 Avril 2007, 10h00mn 55s Objet : Maven users in the industry Hi, Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? Thanks for your help. Gilles -- View this message in context: http://www.nabble.com/Maven-users-in-the-industry-tf3557876s177.html#a9934912 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven users in the industry
Hi Gilles, without violating my NDA An US-based global player for mobile content delivery frameworks switched from ANT to Maven2/CruiseControl to improve the distributed software development covering development teams located in the USA, Canada and Europe. Cheers, Siegfried Goeschl Gilles Scokart wrote: Hi, Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? Thanks for your help. Gilles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven users in the industry
On Wed, April 11, 2007 10:00 am, Gilles Scokart wrote: Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? It's being used within the Standard Bank group of companies. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exclude some classes when package a jar.
On 4/11/07, JesseLiu [EMAIL PROTECTED] wrote: All, I have a jar project. When packaging, I want some specified class excuded from the jar file. How should I do ? Thanks for any suggestions! not sure if this is possible before the packaging. You can always post-process your jar to remove some classes, but I wonder why you need that What kind of classes do you need to remove ? Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven users in the industry
Accenture uses it for build projects -Original Message- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: April 11, 2007 7:06 AM To: Maven Users List Cc: users@maven.apache.org Subject: Re: Maven users in the industry On Wed, April 11, 2007 10:00 am, Gilles Scokart wrote: Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? It's being used within the Standard Bank group of companies. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Trademark Symbol in Site Documentation
-Original Message- From: Dirk Starke [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 5:11 PM To: users@maven.apache.org Subject: Trademark Symbol in Site Documentation Hello, I would like to have a TM symbol in my maven generated website. Is there any way to get it out of APF? Thank you in advance. Dunno. I'm trying to get a registered trademark symbol in myself. I can get it to view fine locally, but now when I deploy. It looks like the site processor embeds the character directly into the document, rather than using the HTML entity code. That's all well and good, but it also generates a Content-Type with a charset that doesn't contain the special characters it has embedded. If I manage to wrangle this somehow, I'll let you know. If not, I guess I'll just have funny looking question marks on my site. -- Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: incorrect dependencies in assembly
On 4/11/07, kelvin goodson [EMAIL PROTECTED] wrote: I'm just coming back to look at this. I'm interested to know whether my question did not make sense or whether no-one has the answer. Please help if you can. tracking down unwanted dependencies is usualy done using mvn -X. I believe the assembly plugin to display information there. Do you use the latest stable assembly plugin ? J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Site Published Time Stamp
I am curious if anyone knows of a way to include the time in the Last Published: date that is created in the header of a generated site. Thanks, Charles Hodanics NSTD-STJ 443-778-3246
Re: Using maven directly from a java application ?
I did svn co against [2] and ran mvn site, and got the following error... [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven ArtifactId: maven Version: 2.1-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.maven:maven:pom:2.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) On 4/10/07, franz see [EMAIL PROTECTED] wrote: Good day, Try [1]. Also you can check out the the latest maven-embedder ( from [2] ) and take a look at its examples and tests. You may also want to run mvn site against [2] to get the latest version of the guide presented in [1]. Cheers, Franz [1] http://maven.apache.org/guides/mini/guide-embedding-m2.html [2] http://svn.apache.org/repos/asf/maven/components/trunk/maven-embedder Wayne Fay wrote: Not that I am personally aware of. But search this list and the Maven Dev list -- you're bound to find something. Wayne On 4/10/07, Marouane Amraoui [EMAIL PROTECTED] wrote: Thx for reply. There are some documentation about using embeded maven ?? -Message d'origine- De: Wayne Fay [mailto:[EMAIL PROTECTED] Envoyé: mardi 10 avril 2007 15:16 À: Maven Users List Objet: Re: Using maven directly from a java application ? You may want to try to use the Maven Embedder: http://idisk.maven.org/jvanzyl/Public/embedder/ Wayne On 4/9/07, Marouane Amraoui [EMAIL PROTECTED] wrote: Hi, I want to atomize the creation of the structure of my project. So iwant to develop a desktop application in order to give to the end user To fill some parameters like : groupId, artifactId ... My question how can I invoke all command mvn from my application desktop , ie I don't want to use the mvn.bat I want to use java classes of maven directly ?? This is a simple to do or I must navigate on all java classes maven Thx --- Merouane AMRAOUI Consultant Expert Division Développement Email.: [EMAIL PROTECTED] Gsm .: 065 19 60 99 Tél. | Tel.: 022 98 70 70Téléc | Fax: 022 98 70 70 OMNIDATA , 74 Bv AbdelMoumen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Using--maven-directly-from-a-java-application---tf3546918s177.html#a9932032 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven users in the industry
RedHat Inc uses Maven, as the project management framework along with other open source technologies. Hope this helps. Thanks -dsantani
Re: Maven Site Published Time Stamp
On 4/11/07, Hodanics, Charles J. [EMAIL PROTECTED] wrote: I am curious if anyone knows of a way to include the time in the Last Published: date that is created in the header of a generated site. There is an example of changing the position and formatting of the date in the site plugin docs: http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html I haven't checked, but my guess is that it follows the usual SimpleDateFormat rules: http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
javax.* artifacts in private remote repository
Our projects depend on javax.mail:mail:1.3.3:jar and javax.activation:activation:1.0.2:jar. These artifacts are not available from the central repository. Thus I thought I put them into our own repository (not the local one, but our private remote repository). Instead of installing them in the local repository I use deploy:deploy-file to upload them. Maven finds the artifacts on my machine since they reside in my local repository. But one someone else's machine Maven cannot download these artifacts. When I run Maven with excessive tracing I see that it downloads the artifact from out priveate repository but then it tries to download it from the central repository and sttes that there is no jar in the central repository (There is only a pom). I tried deploying the artifacts with a version suffix (e.g. javax.mail:mail:1.3.3-p:jar). This works, but isn't the most elegant way. How can I use the original version and still get Maven to download the jars? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using maven directly from a java application ?
Good day, Try adding [1] to your list of repositories in your settings.xml Cheers, Franz [1] http://people.apache.org/maven-snapshot-repository Thierry Lach-2 wrote: I did svn co against [2] and ran mvn site, and got the following error... [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven ArtifactId: maven Version: 2.1-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.maven:maven:pom:2.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) On 4/10/07, franz see [EMAIL PROTECTED] wrote: Good day, Try [1]. Also you can check out the the latest maven-embedder ( from [2] ) and take a look at its examples and tests. You may also want to run mvn site against [2] to get the latest version of the guide presented in [1]. Cheers, Franz [1] http://maven.apache.org/guides/mini/guide-embedding-m2.html [2] http://svn.apache.org/repos/asf/maven/components/trunk/maven-embedder Wayne Fay wrote: Not that I am personally aware of. But search this list and the Maven Dev list -- you're bound to find something. Wayne On 4/10/07, Marouane Amraoui [EMAIL PROTECTED] wrote: Thx for reply. There are some documentation about using embeded maven ?? -Message d'origine- De: Wayne Fay [mailto:[EMAIL PROTECTED] Envoyé: mardi 10 avril 2007 15:16 À: Maven Users List Objet: Re: Using maven directly from a java application ? You may want to try to use the Maven Embedder: http://idisk.maven.org/jvanzyl/Public/embedder/ Wayne On 4/9/07, Marouane Amraoui [EMAIL PROTECTED] wrote: Hi, I want to atomize the creation of the structure of my project. So iwant to develop a desktop application in order to give to the end user To fill some parameters like : groupId, artifactId ... My question how can I invoke all command mvn from my application desktop , ie I don't want to use the mvn.bat I want to use java classes of maven directly ?? This is a simple to do or I must navigate on all java classes maven Thx --- Merouane AMRAOUI Consultant Expert Division Développement Email.: [EMAIL PROTECTED] Gsm .: 065 19 60 99 Tél. | Tel.: 022 98 70 70Téléc | Fax: 022 98 70 70 OMNIDATA , 74 Bv AbdelMoumen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Using--maven-directly-from-a-java-application---tf3546918s177.html#a9932032 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Using--maven-directly-from-a-java-application---tf3546918s177.html#a9940680 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven users in the industry
I know numerous software companies in Belgium using Maven in fields such as logistics, banking and geospatial). Cheers, Stéphane On 4/11/07, Gilles Scokart [EMAIL PROTECTED] wrote: Hi, Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? Thanks for your help. Gilles -- View this message in context: http://www.nabble.com/Maven-users-in-the-industry-tf3557876s177.html#a9934912 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven users in the industry
You can also look on the Team List page ( http://maven.apache.org/team-list.html) -- it lists the Organization that each of the contributors work for. Patrick On 4/11/07, Stephane Nicoll [EMAIL PROTECTED] wrote: I know numerous software companies in Belgium using Maven in fields such as logistics, banking and geospatial). Cheers, Stéphane On 4/11/07, Gilles Scokart [EMAIL PROTECTED] wrote: Hi, Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? Thanks for your help. Gilles -- View this message in context: http://www.nabble.com/Maven-users-in-the-industry-tf3557876s177.html#a9934912 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven users in the industry
Maven2 is the primary build tool used by my company, and I know it is used for at least one major project in our parent company (we're in the US, they parent company is in Germany). Some older projects are still using Maven1 or Ant. Maven2 (including its plugins and auxiliary software) is not without its flaws. It requires some investment in infrastructure, and configuration of projects can be a pain. It is still somewhat buggy and incomplete in places, but it has progressed nicely and I expect will soon be quite solid. Given my experience with Maven2, I feel it is well worth the effort. Using Maven2 is remarkably easy. It has many powerful features, and can take time consuming (and usually tedious) tasks and make them trivial. I cannot speak for my company as a whole, but I have been quite satisfied. -- Daniel Siegmann FJA-US, Inc. 512 Seventh Ave., New York, NY 10018 (212) 840-2618 ext. 139 -Original Message- From: Wim Deblauwe [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 5:11 AM To: Maven Users List Subject: Re: Maven users in the industry I know 2 companies in Belgium that use Maven (one of them still Maven 1.x), but I don't know if I can put their names up. But it is used in Belgium :) regards, Wim 2007/4/11, Gilles Scokart [EMAIL PROTECTED]: Hi, Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? Thanks for your help. Gilles -- View this message in context: http://www.nabble.com/Maven-users-in-the-industry-tf3557876s177.html#a 9934912 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Vigilog - an open source log file viewer: http://vigilog.sourceforge.net Blog: http://www.jroller.com/page/Fester - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Assembly deployment
I am using mvn assembly:assembly deploy command to upload my distribution to the repository. After that, to deploy it on the target machine, I use a simple Perl script that downloads the assembly using http and then unpacks it. Seems that this is pretty convenient thing, and my distributions are under maven control, with names, versions, etc. I had a discussion with my colleague, and he says that this usage of Maven may be not appropriate, that Maven should be used for libraries and not for executable packages. I would like to hear what maven community thinks about this. Another question: is there a way to download and unpack the assembly using Maven? This would be more organized way for deployment. -- View this message in context: http://www.nabble.com/Assembly-deployment-tf3559994s177.html#a9941672 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly deployment
IMO, what you are doing sounds reasonable. Could you use Ant instead of Perl to deploy on the target machine? If so, you could wrap your Ant script up with the maven-antrun-plugin. You also might look at the Cargo plugin (http://cargo.codehaus.org) if your project is deployed to a container. Patrick On 4/11/07, leonid_ilyevsky [EMAIL PROTECTED] wrote: I am using mvn assembly:assembly deploy command to upload my distribution to the repository. After that, to deploy it on the target machine, I use a simple Perl script that downloads the assembly using http and then unpacks it. Seems that this is pretty convenient thing, and my distributions are under maven control, with names, versions, etc. I had a discussion with my colleague, and he says that this usage of Maven may be not appropriate, that Maven should be used for libraries and not for executable packages. I would like to hear what maven community thinks about this. Another question: is there a way to download and unpack the assembly using Maven? This would be more organized way for deployment. -- View this message in context: http://www.nabble.com/Assembly-deployment-tf3559994s177.html#a9941672 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please help me out
Hi All, I installed Maven and trying to build Eclipse RCP Application. The following error I am getting while trying to perform (1) C:\Documents and Settings\bpra\Desktop\maven-2.0.6\maven-2.0.6mvn install from command line [INFO] Scanning for projects... [INFO] - --- [INFO] Building Maven Default Project [INFO]task-segment: [install] [INFO] - --- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exi st or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Apr 11 21:10:48 IST 2007 [INFO] Final Memory: 1M/4M [INFO] (2) C:\Documents and Settings\bpra\Desktop\maven-2.0.6\maven-2.0.6mvn archetype:cre ate -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=com.mycompany.app -DartifactId=my-app Error: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not exi st or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Apr 11 20:59:21 IST 2007 [INFO] Final Memory: 1M/4M [INFO] Please help me out in running the maven tool to build RCP Application. Thanks Regards Ramesh Babu.P mailto::[EMAIL PROTECTED] DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ---
Re: Please help me out
Run again with -e, that is, mvn -e install. You will get more error information (stack trace etc) that might help diagnose your problem. Also, it sounds like you are probably behind a web proxy. This will need to be configured in settings.xml so Maven can connect to the Internet to download plugins etc as needed. Wayne On 4/11/07, Ramesh Babu Pokala - TLS, Chennai [EMAIL PROTECTED] wrote: Hi All, I installed Maven and trying to build Eclipse RCP Application. The following error I am getting while trying to perform (1) C:\Documents and Settings\bpra\Desktop\maven-2.0.6\maven-2.0.6mvn install from command line [INFO] Scanning for projects... [INFO] - --- [INFO] Building Maven Default Project [INFO]task-segment: [install] [INFO] - --- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exi st or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Apr 11 21:10:48 IST 2007 [INFO] Final Memory: 1M/4M [INFO] (2) C:\Documents and Settings\bpra\Desktop\maven-2.0.6\maven-2.0.6mvn archetype:cre ate -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=com.mycompany.app -DartifactId=my-app Error: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not exi st or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Apr 11 20:59:21 IST 2007 [INFO] Final Memory: 1M/4M [INFO] Please help me out in running the maven tool to build RCP Application. Thanks Regards Ramesh Babu.P mailto::[EMAIL PROTECTED] DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
Hi everyone, I wanted to send out a quick email to let everyone know about some discussion that's been taking place on the developers' list regarding plugin versions. In trying to release the 2.2-beta-1 version of the assembly plugin, it became apparent that this version fixes some bugs in the 2.1version that don't necessarily look like bugs. All discussion about what is or is not a bug aside, the discussion raises an interesting point: if you do not specify a version for the plugins in your POMs, a situation can arise where Maven will seamlessly resolve an incompatible plugin version and try to use it. Here's an example: Say I create a project that uses the assembly plugin, version 2.1. My assembly descriptor takes advantage of a bug in this version where the explicit inclusion of a .tar.gz dependency does not have its own transitive dependencies included, unless they too are explicitly included. This is incorrect, because there is no ArtifactHandler that specifies that the .tar.gz file contains its own dependencies (so, therefore, should not have its transitive dependencies resolved, much less factored into inclusion/exclusion)...also, from a semantics point of view, Maven's other dependency usages indicate that specifying a dependency implies that you're specifying that dependency's transitive dependencies...the whole sub-graph should be handled, in other words. Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). You can say that the next version should make an effort to support users exploiting bugs like this, and you can say that plugins need to deprecate and gradually move away from behavior that has turned out to be bad design, counter-intuitive, etc. To this extent, you could argue that the next release that fixed the bug above should have made an allowance for this scenario. However, consider what happens if the plugin has been released several times...say that the newest version is actually 3.1 now. In this scenario, it's entirely reasonable to think that the developers have provided a long migration period - along with deprecation warnings - that spanned multiple versions, and then finally dropped the support for this broken configuration. However, Maven has no idea of any of this, and the aforementioned setup will break. All of this can be avoided by simply being careful about evaluating, then migrating, to new plugin versions in a very deliberate fashion. If you take a look at the world of systems administration, you see this sort of thing everywhere. People take enough time to pour over release notes and determine whether the new version is likely to wreck the existing setup. The same should go for building a reproducible build infrastructure. I'm going to start a discussion on the developers' for getting rid of the plugin-version auto-resolver in Maven 2.1 immediately, to start pushing the tools down this path. However, it will make everyone's lives easier to start the process now. Please, take a moment and put the plugin versions into your POMs. Thanks, John
[ANN] maven-jython-plugin 0.1
Hi, I'm pleased to announce the first public release of the maven-jython-plugin for the maven 2 project management system. The purpose of this plugin is to make working with Jython source files as natural as working with Java source files in a project. Being an initial release, we're still a ways off from that, but we do have some nifty stuff working. Official announcement: http://dev.servprise.com/weblog/articles/2007/04/11/announcing-the-first -release-of-the-maven-jython-plugin Official project page: http://dev.servprise.com/maven-jython-plugin/ Please note that this is not an official plugin, but rather one developed by a third party. The sources are being made available under the ASLv2, however. Kevin Menard Servprise International, Inc. 800.832.3823 x308 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem when installing Maven 2.0
Dear Madam/Sir, I am trying to install Maven 2.0 using the command mvn install, and I am getting the following messages: [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Apr 11 20:08:00 GST 2007 [INFO] Final Memory: 1M/2M [INFO] When I used -e switch, here are the messages: + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Default LifecycleExecutor.java:1286) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(De faultLifecycleExecutor.java:1522) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPack aging(DefaultLifecycleExecutor.java:1016) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMa ppings(DefaultLifecycleExecutor.java:980) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.version.PluginVersionNotFoundException: The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePlugi nVersion(DefaultPluginVersionManager.java:228) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePlugi nVersion(DefaultPluginVersionManager.java:90) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginM anager.java:166) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Default LifecycleExecutor.java:1257) ... 18 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Apr 11 20:11:06 GST 2007 [INFO] Final Memory: 1M/2M [INFO] Thanks for your help Zoheir
Newbie: running mvn test problem with configuration files and current directory
Hello, I just downloaded maven and played a little bit with it. I have the following problem (maven 2.0.6): project structure . | src | main | | | java | test |java | |src | |resources | |myconfig.xml pom.xml When I run mvn test, everything works fine, sources are compiled, resources are copied into test-classes etc. When tests run, tests assumes that configuration file config.xml in current directory, which is . and resource file went to ./test-classes/config.xml. I don't understand why current directory when running tests is not ./test-classes/. What should I do? How to tell maven which directory is current for runing tests? Or should I use another method to load configuration file? Thank you, Cristian. Here is my pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdro.romanescu.eximius/groupId artifactIdeximius/artifactId packagingjar/packaging version1.0/version nameeximius/name urlhttp://maven.apache.org/url build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin /plugins /build dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.3.1/version scopetest/scope /dependency dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version scoperuntime/scope /dependency dependency groupIddom4j/groupId artifactIddom4j/artifactId version1.6.1/version scoperuntime/scope /dependency dependency groupIdjaxen/groupId artifactIdjaxen/artifactId version1.1/version scoperuntime/scope /dependency /dependencies /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deploying assembly
I am using mvn assembly:assembly deploy command to upload my distribution to the repository. After that, to deploy it on the target machine, I use a simple Perl script that downloads the assembly using http and then unpacks it. Seems that this is pretty convenient thing, and my distributions are under maven control, with names, versions, etc. I had a discussion with my colleague, and he says that this usage of Maven may be not appropriate, that Maven should be used for libraries and not for executable packages. I would like to hear what maven community thinks about this. Another question: is there a way to download and unpack the assembly using Maven? This would be more organized way for deployment. If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Question regarding finalName in maven-assembly-plugin
Hi,
I've noticed that the finalName configuration option for an assembly is
ignored when you install or deploy your project. Is this intended behavior?
I have a project named openjpa-project which contains the a source and
binary assembly which packages various OpenJPA sub-projects. We'd like to
have the resulting zip files named openjpa-${version}-source.zip and
openjpa-${version}-binary.zip, but we're getting openjpa-project-${version}-
source.zip (and the same for -binary) when we deploy or install.
I can provide pom and assembly files if that would help.
Thanks,
--
-Michael Dick
How to create patch jar files?
Hi, I'm looking for suggestions about how to handle the creation of patch jar files. A patch jar file is one that contains only the classes that have changed between two releases. Our production directories typically look like this: application/bin # contains start scripts application/jars# contains jar files application/patch # contains jar files An application's class path consists of all the jar files in the patch directory (if any) and then all the jar files in the jars directory. This way the patched classes take precedence. When a patch is needed the developers create a small jar file that contains just the classes that have changed and stick it into the patch directory. The Ant based build has a target called patch-jar. It creates a jar file using just the classes listed in a text file. This text file is stored in SCM and thus patches can be reproduced. So, my question is: How can I do something similar in Maven? Regards, Christopher Helck ** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the Information) is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates (ICAP) or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. **
Maven 2.0.6 test-jar
Hello All, I just tried to build our apps with maven 2.0.6 and stumbled on a problem described here: http://jira.codehaus.org/browse/MNG-1895 In short: pom2 -depends on- pom1 pom3 -depends on- pom2 pom4 -depends on- pom3 and in test scope -depends on- pom2-test-jar results in pom1 gets stuck in test scope instead of compile scope, app with pom4 won't build anymore. I now fixed this by adding the pom2 dependency in pom4. This issue should be fixed since 2.0.3, is it possible this bug has sneaked back in? Kind Regards, Jan DISCLAIMER http://www.schaubroeck.be/maildisclaimer.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 and Cobertura - 100% coverage???
I reverted back to cobertura-maven-plugin v2.0 to fix the all classes are 100% problem, and it worked fine on individual modules. But the site build fails at the top pom project with http://jira.codehaus.org/browse/MCOBERTURA-38 MCOBERTURA-38 which is fixed in v2.1!!! So I'm a bit stuck between the two bugs. Is there a way to force the 2.0-plugin to use cobertura 1.7? And would that fix it? If the only solution is to use 2.1-SNAPSHOT... then I guess I'll have to try it. David bkbonner wrote: OK, I'll revert back to 2.0, thanks for the tip. dan tran wrote: use version2.0/version latest 2.1 is bad, and it should be taken out of repo1 -D On 2/23/07, Arnaud Bailly [EMAIL PROTECTED] wrote: Hello, You may want to try the following configuration build !-- indique les plugin qui seront utilisés dans le projet lors de la compilation -- plugins !-- clean coverage data before collecting -- plugin artifactIdcobertura-maven-plugin/artifactId groupIdorg.codehaus.mojo/groupId executions execution goals goalclean/goal /goals /execution /executions /plugin /plugins /build reporting plugins !-- test coverage -- plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId /plugin /plugins /reporting HTH -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-2-and-Cobertura---100--coveragetf3280827s177.html#a9943303 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Newbie: running mvn test problem with configuration files and current directory
Hi, You need to use build . testSourceDirectorysrc/test/java/testSourceDirectory testOutputDirectorytarget/test-classes /testOutputDirectory /build Cheers, Sudheendra N Singh -Original Message- From: Cristian D. Romanescu [mailto:[EMAIL PROTECTED] Sent: 11 April 2007 17:25 To: users@maven.apache.org Subject: Newbie: running mvn test problem with configuration files and current directory Hello, I just downloaded maven and played a little bit with it. I have the following problem (maven 2.0.6): project structure . | src | main | | | java | test |java | |src | |resources | |myconfig.xml pom.xml When I run mvn test, everything works fine, sources are compiled, resources are copied into test-classes etc. When tests run, tests assumes that configuration file config.xml in current directory, which is . and resource file went to ./test-classes/config.xml. I don't understand why current directory when running tests is not ./test-classes/. What should I do? How to tell maven which directory is current for runing tests? Or should I use another method to load configuration file? Thank you, Cristian. Here is my pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdro.romanescu.eximius/groupId artifactIdeximius/artifactId packagingjar/packaging version1.0/version nameeximius/name urlhttp://maven.apache.org/url build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin /plugins /build dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.3.1/version scopetest/scope /dependency dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version scoperuntime/scope /dependency dependency groupIddom4j/groupId artifactIddom4j/artifactId version1.6.1/version scoperuntime/scope /dependency dependency groupIdjaxen/groupId artifactIdjaxen/artifactId version1.1/version scoperuntime/scope /dependency /dependencies /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown. This email transmission may contain confidential information. This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. Copyright 2007 CIGNA == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 and Cobertura - 100% coverage???
I reverted back to cobertura-maven-plugin v2.0 to fix the all classes are 100% problem, and it worked fine on individual modules. But the site build fails at the top pom project with http://jira.codehaus.org/browse/MCOBERTURA-38 MCOBERTURA-38 which is fixed in v2.1!!! So I'm a bit stuck between the two bugs. Is there a way to force the 2.0-plugin to use cobertura 1.7? And would that fix it? If the only solution is to use 2.1-SNAPSHOT... then I guess I'll have to try it. David bkbonner wrote: OK, I'll revert back to 2.0, thanks for the tip. dan tran wrote: use version2.0/version latest 2.1 is bad, and it should be taken out of repo1 -D On 2/23/07, Arnaud Bailly [EMAIL PROTECTED] wrote: Hello, You may want to try the following configuration build !-- indique les plugin qui seront utilisés dans le projet lors de la compilation -- plugins !-- clean coverage data before collecting -- plugin artifactIdcobertura-maven-plugin/artifactId groupIdorg.codehaus.mojo/groupId executions execution goals goalclean/goal /goals /execution /executions /plugin /plugins /build reporting plugins !-- test coverage -- plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId /plugin /plugins /reporting HTH -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-2-and-Cobertura---100--coveragetf3280827s177.html#a9943306 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
I agree, automatic resolution of plugin versions is dangerous and you must use versions if you want reproducible builds. it's easy to add them to your parent pom in the pluginManagement section On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I wanted to send out a quick email to let everyone know about some discussion that's been taking place on the developers' list regarding plugin versions. In trying to release the 2.2-beta-1 version of the assembly plugin, it became apparent that this version fixes some bugs in the 2.1version that don't necessarily look like bugs. All discussion about what is or is not a bug aside, the discussion raises an interesting point: if you do not specify a version for the plugins in your POMs, a situation can arise where Maven will seamlessly resolve an incompatible plugin version and try to use it. Here's an example: Say I create a project that uses the assembly plugin, version 2.1. My assembly descriptor takes advantage of a bug in this version where the explicit inclusion of a .tar.gz dependency does not have its own transitive dependencies included, unless they too are explicitly included. This is incorrect, because there is no ArtifactHandler that specifies that the .tar.gz file contains its own dependencies (so, therefore, should not have its transitive dependencies resolved, much less factored into inclusion/exclusion)...also, from a semantics point of view, Maven's other dependency usages indicate that specifying a dependency implies that you're specifying that dependency's transitive dependencies...the whole sub-graph should be handled, in other words. Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). You can say that the next version should make an effort to support users exploiting bugs like this, and you can say that plugins need to deprecate and gradually move away from behavior that has turned out to be bad design, counter-intuitive, etc. To this extent, you could argue that the next release that fixed the bug above should have made an allowance for this scenario. However, consider what happens if the plugin has been released several times...say that the newest version is actually 3.1 now. In this scenario, it's entirely reasonable to think that the developers have provided a long migration period - along with deprecation warnings - that spanned multiple versions, and then finally dropped the support for this broken configuration. However, Maven has no idea of any of this, and the aforementioned setup will break. All of this can be avoided by simply being careful about evaluating, then migrating, to new plugin versions in a very deliberate fashion. If you take a look at the world of systems administration, you see this sort of thing everywhere. People take enough time to pour over release notes and determine whether the new version is likely to wreck the existing setup. The same should go for building a reproducible build infrastructure. I'm going to start a discussion on the developers' for getting rid of the plugin-version auto-resolver in Maven 2.1 immediately, to start pushing the tools down this path. However, it will make everyone's lives easier to start the process now. Please, take a moment and put the plugin versions into your POMs. Thanks, John -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven users in the industry
UBS Investment Bank within Post Trade Services -- Peter Pilgrim UBS Investment Bank, Client Portal Dev LDN, Triton Court, 14 Finsbury Square, London, EC2A 1PD United Kingdom ( +44 (0)207 56 75692 ) :: Java EE Spring 2.0 Hibernate 3.2 Development :: -Original Message- From: Gilles Scokart [mailto:[EMAIL PROTECTED] Sent: 11 April 2007 09:01 To: users@maven.apache.org Subject: Maven users in the industry Hi, Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? Thanks for your help. Gilles -- View this message in context: http://www.nabble.com/Maven-users-in-the-industry-tf3557876s17 7.html#a9934912 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS Limited is a company registered in England Wales under company number 2035362, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS AG (London Branch) is registered as a branch of a foreign company under number BR004507, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. UBS Clearing and Execution Services Limited is a company registered in England Wales under company number 03123037, whose registered office is at 1 Finsbury Avenue, London, EC2M 2PP, United Kingdom. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
Don't forget you use a lot more plugins than you think. Who specifies versions for resources; compiler, surefire, install, deploy, clean, ... ? Maybe we need a plugin that can rewrite your POMs to specify versions for all the plugins that are used ? Tom On 4/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I agree, automatic resolution of plugin versions is dangerous and you must use versions if you want reproducible builds. it's easy to add them to your parent pom in the pluginManagement section On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I wanted to send out a quick email to let everyone know about some discussion that's been taking place on the developers' list regarding plugin versions. In trying to release the 2.2-beta-1 version of the assembly plugin, it became apparent that this version fixes some bugs in the 2.1version that don't necessarily look like bugs. All discussion about what is or is not a bug aside, the discussion raises an interesting point: if you do not specify a version for the plugins in your POMs, a situation can arise where Maven will seamlessly resolve an incompatible plugin version and try to use it. Here's an example: Say I create a project that uses the assembly plugin, version 2.1. My assembly descriptor takes advantage of a bug in this version where the explicit inclusion of a .tar.gz dependency does not have its own transitive dependencies included, unless they too are explicitly included. This is incorrect, because there is no ArtifactHandler that specifies that the .tar.gz file contains its own dependencies (so, therefore, should not have its transitive dependencies resolved, much less factored into inclusion/exclusion)...also, from a semantics point of view, Maven's other dependency usages indicate that specifying a dependency implies that you're specifying that dependency's transitive dependencies...the whole sub-graph should be handled, in other words. Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). You can say that the next version should make an effort to support users exploiting bugs like this, and you can say that plugins need to deprecate and gradually move away from behavior that has turned out to be bad design, counter-intuitive, etc. To this extent, you could argue that the next release that fixed the bug above should have made an allowance for this scenario. However, consider what happens if the plugin has been released several times...say that the newest version is actually 3.1 now. In this scenario, it's entirely reasonable to think that the developers have provided a long migration period - along with deprecation warnings - that spanned multiple versions, and then finally dropped the support for this broken configuration. However, Maven has no idea of any of this, and the aforementioned setup will break. All of this can be avoided by simply being careful about evaluating, then migrating, to new plugin versions in a very deliberate fashion. If you take a look at the world of systems administration, you see this sort of thing everywhere. People take enough time to pour over release notes and determine whether the new version is likely to wreck the existing setup. The same should go for building a reproducible build infrastructure. I'm going to start a discussion on the developers' for getting rid of the plugin-version auto-resolver in Maven 2.1 immediately, to start pushing the tools down this path. However, it will make everyone's lives easier to start the process now. Please, take a moment and put the plugin versions into your POMs. Thanks, John -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem when installing Maven 2.0
try this first: mvn compile -e The issue is that you have NOT created your local repository (*/.m2/repository) On 4/11/07, Zoheir Ezziane [EMAIL PROTECTED] wrote: Dear Madam/Sir, I am trying to install Maven 2.0 using the command mvn install, and I am getting the following messages: [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Apr 11 20:08:00 GST 2007 [INFO] Final Memory: 1M/2M [INFO] When I used -e switch, here are the messages: + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Default LifecycleExecutor.java:1286) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(De faultLifecycleExecutor.java:1522) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPack aging(DefaultLifecycleExecutor.java:1016) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMa ppings(DefaultLifecycleExecutor.java:980) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.version.PluginVersionNotFoundException: The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePlugi nVersion(DefaultPluginVersionManager.java:228) at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePlugi nVersion(DefaultPluginVersionManager.java:90) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginM anager.java:166) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Default LifecycleExecutor.java:1257) ... 18 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Apr 11 20:11:06 GST 2007 [INFO] Final Memory: 1M/2M [INFO]
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
I think that sort of plugin would be a great idea. For the plugins in the standard packaging lifecycles (to which you're referring, I believe), I still think that Maven should force you to supply a version for each one. It might make sense to have a version-set dependency or artifact that you can use to specify them as a group, so you have a sort of standardized toolchain for your build. This is possible via parent POM and pluginManagement today, but it is sort of orthogonal to normal inheritance in some ways, too... -john On 4/11/07, Tom Huybrechts [EMAIL PROTECTED] wrote: Don't forget you use a lot more plugins than you think. Who specifies versions for resources; compiler, surefire, install, deploy, clean, ... ? Maybe we need a plugin that can rewrite your POMs to specify versions for all the plugins that are used ? Tom On 4/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I agree, automatic resolution of plugin versions is dangerous and you must use versions if you want reproducible builds. it's easy to add them to your parent pom in the pluginManagement section On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I wanted to send out a quick email to let everyone know about some discussion that's been taking place on the developers' list regarding plugin versions. In trying to release the 2.2-beta-1 version of the assembly plugin, it became apparent that this version fixes some bugs in the 2.1version that don't necessarily look like bugs. All discussion about what is or is not a bug aside, the discussion raises an interesting point: if you do not specify a version for the plugins in your POMs, a situation can arise where Maven will seamlessly resolve an incompatible plugin version and try to use it. Here's an example: Say I create a project that uses the assembly plugin, version 2.1. My assembly descriptor takes advantage of a bug in this version where the explicit inclusion of a .tar.gz dependency does not have its own transitive dependencies included, unless they too are explicitly included. This is incorrect, because there is no ArtifactHandler that specifies that the .tar.gz file contains its own dependencies (so, therefore, should not have its transitive dependencies resolved, much less factored into inclusion/exclusion)...also, from a semantics point of view, Maven's other dependency usages indicate that specifying a dependency implies that you're specifying that dependency's transitive dependencies...the whole sub-graph should be handled, in other words. Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). You can say that the next version should make an effort to support users exploiting bugs like this, and you can say that plugins need to deprecate and gradually move away from behavior that has turned out to be bad design, counter-intuitive, etc. To this extent, you could argue that the next release that fixed the bug above should have made an allowance for this scenario. However, consider what happens if the plugin has been released several times...say that the newest version is actually 3.1 now. In this scenario, it's entirely reasonable to think that the developers have provided a long migration period - along with deprecation warnings - that spanned multiple versions, and then finally dropped the support for this broken configuration. However, Maven has no idea of any of this, and the aforementioned setup will break. All of this can be avoided by simply being careful about evaluating, then migrating, to new plugin versions in a very deliberate fashion. If you take a look at the world of systems administration, you see this sort of thing everywhere. People take enough time to pour over release notes and determine whether the new version is likely to wreck the existing setup. The same should go for building a reproducible build infrastructure. I'm going to start a discussion on the developers' for getting rid of the plugin-version auto-resolver in Maven 2.1 immediately, to start pushing the tools down this path. However, it will make everyone's lives easier to start the process now. Please, take a moment and put the plugin versions into your POMs. Thanks, John -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Newbie: running mvn test problem with configuration files and current directory
Thanks, found the problem. I was loading the resource via: Thread.currentThread().getClass().getResource( config.xml ); replaced with getClass().getResource( config.xml ); and works fine now! Thank you, Cristian. Singh, Sudheendra GNI CON wrote: Hi, You need to use build . testSourceDirectorysrc/test/java/testSourceDirectory testOutputDirectorytarget/test-classes /testOutputDirectory /build Cheers, Sudheendra N Singh -Original Message- From: Cristian D. Romanescu [mailto:[EMAIL PROTECTED] Sent: 11 April 2007 17:25 To: users@maven.apache.org Subject: Newbie: running mvn test problem with configuration files and current directory Hello, I just downloaded maven and played a little bit with it. I have the following problem (maven 2.0.6): project structure . | src | main | | | java | test |java | |src | |resources | |myconfig.xml pom.xml When I run mvn test, everything works fine, sources are compiled, resources are copied into test-classes etc. When tests run, tests assumes that configuration file config.xml in current directory, which is . and resource file went to ./test-classes/config.xml. I don't understand why current directory when running tests is not ./test-classes/. What should I do? How to tell maven which directory is current for runing tests? Or should I use another method to load configuration file? Thank you, Cristian. Here is my pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdro.romanescu.eximius/groupId artifactIdeximius/artifactId packagingjar/packaging version1.0/version nameeximius/name urlhttp://maven.apache.org/url build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin /plugins /build dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.3.1/version scopetest/scope /dependency dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version scoperuntime/scope /dependency dependency groupIddom4j/groupId artifactIddom4j/artifactId version1.6.1/version scoperuntime/scope /dependency dependency groupIdjaxen/groupId artifactIdjaxen/artifactId version1.1/version scoperuntime/scope /dependency /dependencies /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown. This email transmission may contain confidential information. This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. Copyright 2007 CIGNA == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
Don't forget you use a lot more plugins than you think. Who specifies versions for resources; compiler, surefire, install, deploy, clean, ... ? Maybe we need a plugin that can rewrite your POMs to specify versions for all the plugins that are used ? I agree entirely. While the automatic resolution is dangerous, it is also very useful. Being forced to specify versions for every plugin used would be tedious, error prone, and overall just a huge pain in the ass. Replacing this functionality with a plugin would probably be ideal. It could do an initial resolution for plugins, and thereafter could upgrade the versions as necessary. Perhaps a section could be added to the POM for specifying version compatibility. This could then be used by the plugin to determine if it can automatically upgrade the plugins, and if so to what version. -- Daniel Siegmann FJA-US, Inc. 512 Seventh Ave., New York, NY 10018 (212) 840-2618 ext. 139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
On 4/11/07, Michael Dick [EMAIL PROTECTED] wrote:
Hi,
I've noticed that the finalName configuration option for an assembly is
ignored when you install or deploy your project. Is this intended behavior?
I have a project named openjpa-project which contains the a source and
binary assembly which packages various OpenJPA sub-projects. We'd like to
have the resulting zip files named openjpa-${version}-source.zip and
openjpa-${version}-binary.zip, but we're getting openjpa-project-${version}-
source.zip (and the same for -binary) when we deploy or install.
I can provide pom and assembly files if that would help.
Thanks,
--
-Michael Dick
There is no way for maven to access an artifact in the repository if
it does not follow the standard naming conventions.
Henry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
I would think most corporate users have run into this already.. I know we have :) I've been saying people still need to know and understand which plugins and versions they are using and why, even if Maven makes it nice and automated. Sorry for OT, but since you mentioned - what's going on with the assembly 2.2-beta-1 release? It looks like the release was made (following the dev thread and new snapshot versions), but it's not available on repo1? I'm sure at least :) a million people are waiting for a new assembly release, beta or not. Kalle On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I wanted to send out a quick email to let everyone know about some discussion that's been taking place on the developers' list regarding plugin versions. In trying to release the 2.2-beta-1 version of the assembly plugin, it became apparent that this version fixes some bugs in the 2.1version that don't necessarily look like bugs. All discussion about what is or is not a bug aside, the discussion raises an interesting point: if you do not specify a version for the plugins in your POMs, a situation can arise where Maven will seamlessly resolve an incompatible plugin version and try to use it. Here's an example: Say I create a project that uses the assembly plugin, version 2.1. My assembly descriptor takes advantage of a bug in this version where the explicit inclusion of a .tar.gz dependency does not have its own transitive dependencies included, unless they too are explicitly included. This is incorrect, because there is no ArtifactHandler that specifies that the .tar.gz file contains its own dependencies (so, therefore, should not have its transitive dependencies resolved, much less factored into inclusion/exclusion)...also, from a semantics point of view, Maven's other dependency usages indicate that specifying a dependency implies that you're specifying that dependency's transitive dependencies...the whole sub-graph should be handled, in other words. Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). You can say that the next version should make an effort to support users exploiting bugs like this, and you can say that plugins need to deprecate and gradually move away from behavior that has turned out to be bad design, counter-intuitive, etc. To this extent, you could argue that the next release that fixed the bug above should have made an allowance for this scenario. However, consider what happens if the plugin has been released several times...say that the newest version is actually 3.1 now. In this scenario, it's entirely reasonable to think that the developers have provided a long migration period - along with deprecation warnings - that spanned multiple versions, and then finally dropped the support for this broken configuration. However, Maven has no idea of any of this, and the aforementioned setup will break. All of this can be avoided by simply being careful about evaluating, then migrating, to new plugin versions in a very deliberate fashion. If you take a look at the world of systems administration, you see this sort of thing everywhere. People take enough time to pour over release notes and determine whether the new version is likely to wreck the existing setup. The same should go for building a reproducible build infrastructure. I'm going to start a discussion on the developers' for getting rid of the plugin-version auto-resolver in Maven 2.1 immediately, to start pushing the tools down this path. However, it will make everyone's lives easier to start the process now. Please, take a moment and put the plugin versions into your POMs. Thanks, John
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
The assembly plugin release goes to an rsync-staging repository before it's shunted on to repo1. It usually takes a couple hours to make it all the way out into the open. I'm sure many people have hit this plugin-versioning problem before, and I know that versioning everything is a huge pain in the ass...but, if you think you might have to build something from an old tag someday, the reproducibility is probably worth a little tedium. If you don't think so, then why tag? As a side note, I guess those who are *really* hard-core about reproducibility won't even use repo1 directly, but will opt for an internal proxy repository instead, where they can have better control over what's available. Not that we intend to cull old plugin releases, but if your business depends on it, then it's a real risk to put that control in someone else's hands... -john On 4/11/07, Kalle Korhonen [EMAIL PROTECTED] wrote: I would think most corporate users have run into this already.. I know we have :) I've been saying people still need to know and understand which plugins and versions they are using and why, even if Maven makes it nice and automated. Sorry for OT, but since you mentioned - what's going on with the assembly 2.2-beta-1 release? It looks like the release was made (following the dev thread and new snapshot versions), but it's not available on repo1? I'm sure at least :) a million people are waiting for a new assembly release, beta or not. Kalle On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I wanted to send out a quick email to let everyone know about some discussion that's been taking place on the developers' list regarding plugin versions. In trying to release the 2.2-beta-1 version of the assembly plugin, it became apparent that this version fixes some bugs in the 2.1version that don't necessarily look like bugs. All discussion about what is or is not a bug aside, the discussion raises an interesting point: if you do not specify a version for the plugins in your POMs, a situation can arise where Maven will seamlessly resolve an incompatible plugin version and try to use it. Here's an example: Say I create a project that uses the assembly plugin, version 2.1. My assembly descriptor takes advantage of a bug in this version where the explicit inclusion of a .tar.gz dependency does not have its own transitive dependencies included, unless they too are explicitly included. This is incorrect, because there is no ArtifactHandler that specifies that the .tar.gz file contains its own dependencies (so, therefore, should not have its transitive dependencies resolved, much less factored into inclusion/exclusion)...also, from a semantics point of view, Maven's other dependency usages indicate that specifying a dependency implies that you're specifying that dependency's transitive dependencies...the whole sub-graph should be handled, in other words. Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). You can say that the next version should make an effort to support users exploiting bugs like this, and you can say that plugins need to deprecate and gradually move away from behavior that has turned out to be bad design, counter-intuitive, etc. To this extent, you could argue that the next release that fixed the bug above should have made an allowance for this scenario. However, consider what happens if the plugin has been released several times...say that the newest version is actually 3.1 now. In this scenario, it's entirely reasonable to think that the developers have provided a long migration period - along with deprecation warnings - that spanned multiple versions, and then finally dropped the support for this broken configuration. However, Maven has no idea of any of this, and the aforementioned setup will break. All of this can be avoided by simply being careful about evaluating, then migrating, to new plugin versions in a very deliberate fashion. If you take a look at the world of systems administration, you see this sort of thing everywhere. People take enough time to pour over release notes and determine whether the new version is likely to wreck the existing setup. The same should go for building a reproducible build infrastructure. I'm going to start a discussion on the developers' for getting rid of the plugin-version auto-resolver in Maven 2.1 immediately, to start pushing the tools down this path. However, it
bogus error? [ERROR]? How can i get rid of it?
Hi, I have seen this error in the build log but i think they are bogus since the operation is successful. How can i get rid of them? Thanks. AY [INFO] copy c:\Documents and Settings\Administrator\.m2\com\aaa\bbb.jar C:\install_dir 1 file(s) copied. [ERROR] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
Thank you for the explanation,
Wouldn't it be possible to store the finalName in the
maven-metadata.xmlfile or another xml file in the repository? We
already have a unique path in
the repository ${groupId}/${artifactId}/${version}. I'm not interested in
changing the path, just the name of the final jar / zip / whatever.
It seems that the finalName *could* be added in an xml file in the
repository. Whether it *should* be added is another issue.
FTR I'm just curious whether this is a possibility, or if anyone else thinks
it would be a good idea. I did look through the mailing list archives
unfortunately after I posted the question) and I know this issue has come up
before.
Thanks again,
Michael Dick
On 4/11/07, Heinrich Nirschl [EMAIL PROTECTED] wrote:
On 4/11/07, Michael Dick [EMAIL PROTECTED] wrote:
Hi,
I've noticed that the finalName configuration option for an assembly is
ignored when you install or deploy your project. Is this intended
behavior?
I have a project named openjpa-project which contains the a source and
binary assembly which packages various OpenJPA sub-projects. We'd like
to
have the resulting zip files named openjpa-${version}-source.zip and
openjpa-${version}-binary.zip, but we're getting
openjpa-project-${version}-
source.zip (and the same for -binary) when we deploy or install.
I can provide pom and assembly files if that would help.
Thanks,
--
-Michael Dick
There is no way for maven to access an artifact in the repository if
it does not follow the standard naming conventions.
Henry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Writting mojos in Groovy?
Can anybody point me to a how-to or recipe or good blog entry on creating a mojo in groovy? Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[2.0.6] LinkageError with Maven 2.0.6
Hi In Apache FtpServer we have had two users independently [1}[2] run into a problem where Surefire fails a test due to a class loader issue. I can reproduce the error on my laptop by simple upgrading from 2.0.5 to 2.0.6. On 2.0.5 it works as expected. The version of maven-surefire-plugin used is 2.0 due to another problem reported with 2.3 [3]. Seems like 2.3.1 has not yet been released. Any clue to why this happens? The stack trace is provided below. Thanks! /niklas [1] http://permalink.gmane.org/gmane.comp.jakarta.ftpserver.devel/610 [2] http://permalink.gmane.org/gmane.comp.apache.incubator.general/13868 [3] http://permalink.gmane.org/gmane.comp.jakarta.turbine.maven.user/63181 --- Battery: org.apache.ftpserver.config.XmlConfigurationTest --- Tests run: 9, Failures: 0, Errors: 9, Time elapsed: 0,093 sec testBaseConfigKeys(org.apache.ftpserver.config.XmlConfigurationTest) Time elapsed: 0,032 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.LinkageError: Class org/xml/sax/XMLReader violates loader constraints at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.codehaus.surefire.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:61) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.ftpserver.config.XmlConfigurationHandler.parse(XmlConfigurationHandler.java:73) at org.apache.ftpserver.config.XmlConfigurationTest.createConfiguration(XmlConfigurationTest.java:35) at org.apache.ftpserver.config.ConfigurationTestTemplate.setUp(ConfigurationTestTemplate.java:39) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:246) at org.codehaus.surefire.battery.JUnitBattery.execute(JUnitBattery.java:220) at org.codehaus.surefire.Surefire.executeBattery(Surefire.java:204) at org.codehaus.surefire.Surefire.run(Surefire.java:153) at org.codehaus.surefire.Surefire.run(Surefire.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.surefire.SurefireBooter.run(SurefireBooter.java:104) at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:303) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: Writting mojos in Groovy?
James CE Johnson wrote: Can anybody point me to a how-to or recipe or good blog entry on creating a mojo in groovy? Thanks, James You're in luck! The Groovy Maven Plugin has just been released. Check it out here: http://mojo.codehaus.org/groovy-maven-plugin/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
On Wed, Apr 11, 2007 at 01:27:42PM -0500, Michael Dick spake thus: *snip* It seems that the finalName *could* be added in an xml file in the repository. Whether it *should* be added is another issue. FTR I'm just curious whether this is a possibility, or if anyone else thinks it would be a good idea. I did look through the mailing list archives unfortunately after I posted the question) and I know this issue has come up before. Thanks again, Michael Dick On 4/11/07, Heinrich Nirschl [EMAIL PROTECTED] wrote: On 4/11/07, Michael Dick [EMAIL PROTECTED] wrote: Hi, I've noticed that the finalName configuration option for an assembly is ignored when you install or deploy your project. Is this intended behavior? *snip* -- -Michael Dick There is no way for maven to access an artifact in the repository if it does not follow the standard naming conventions. Henry I have projects that create artifacts with a 'finalName' set, and these artifacts get installed/deployed with the wrong file names (that is, not what I specified in 'finalName'). In all of my cases, these artifacts do not need to be accessible by maven for build purposes, so the fact that the files are installed and deployed with names different from what I specified in 'finalName' is simply an annoyance (because I then have to rename the files on the deployment server by hand). Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 and Cobertura - 100% coverage???
I just had the same problem. I've got my standard reporting suite declared in a parent pom for several projects. The plugin is supposed to check the package type and disable itself for non jar/war projects, but that's broken in 2.0. It's fixed in 2.1, but that's using a broken version of Cobertura 1.8. My solution was to crack open the pom file for plugin version 2.1 and change the versions for cobertura and cobertura-runtime from 1.8-1.7. Works great. It even puts the cobertura.ser file in the right place now. I was banging my head against a wall for a bit when I deployed it to my local repo because running mvn cobertura:cobertura wouldn't find it, but that's just because I hadn't written some other config file. It works when I run the site goal. -Steve David Roussel wrote: I reverted back to cobertura-maven-plugin v2.0 to fix the all classes are 100% problem, and it worked fine on individual modules. But the site build fails at the top pom project with http://jira.codehaus.org/browse/MCOBERTURA-38 MCOBERTURA-38 which is fixed in v2.1!!! So I'm a bit stuck between the two bugs. Is there a way to force the 2.0-plugin to use cobertura 1.7? And would that fix it? If the only solution is to use 2.1-SNAPSHOT... then I guess I'll have to try it. David bkbonner wrote: OK, I'll revert back to 2.0, thanks for the tip. dan tran wrote: use version2.0/version latest 2.1 is bad, and it should be taken out of repo1 -D On 2/23/07, Arnaud Bailly [EMAIL PROTECTED] wrote: Hello, You may want to try the following configuration build !-- indique les plugin qui seront utilisés dans le projet lors de la compilation -- plugins !-- clean coverage data before collecting -- plugin artifactIdcobertura-maven-plugin/artifactId groupIdorg.codehaus.mojo/groupId executions execution goals goalclean/goal /goals /execution /executions /plugin /plugins /build reporting plugins !-- test coverage -- plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId /plugin /plugins /reporting HTH -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
Two more ideas: - Versioned lifecycles. Let a version of a lifecycle map to versions of each of its plugins. Allow users to override these by specifying explicit versions for the plugins. If you don't specify a version for the packaging, you get the old behaviour. - Have the maven-release-plugin add versions for all plugins, so you would at least have reproduciblity for releases. There must be a JIRA for this already, but I couldn't find it. Tom On 4/11/07, John Casey [EMAIL PROTECTED] wrote: I think that sort of plugin would be a great idea. For the plugins in the standard packaging lifecycles (to which you're referring, I believe), I still think that Maven should force you to supply a version for each one. It might make sense to have a version-set dependency or artifact that you can use to specify them as a group, so you have a sort of standardized toolchain for your build. This is possible via parent POM and pluginManagement today, but it is sort of orthogonal to normal inheritance in some ways, too... -john On 4/11/07, Tom Huybrechts [EMAIL PROTECTED] wrote: Don't forget you use a lot more plugins than you think. Who specifies versions for resources; compiler, surefire, install, deploy, clean, ... ? Maybe we need a plugin that can rewrite your POMs to specify versions for all the plugins that are used ? Tom On 4/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I agree, automatic resolution of plugin versions is dangerous and you must use versions if you want reproducible builds. it's easy to add them to your parent pom in the pluginManagement section On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I wanted to send out a quick email to let everyone know about some discussion that's been taking place on the developers' list regarding plugin versions. In trying to release the 2.2-beta-1 version of the assembly plugin, it became apparent that this version fixes some bugs in the 2.1version that don't necessarily look like bugs. All discussion about what is or is not a bug aside, the discussion raises an interesting point: if you do not specify a version for the plugins in your POMs, a situation can arise where Maven will seamlessly resolve an incompatible plugin version and try to use it. Here's an example: Say I create a project that uses the assembly plugin, version 2.1. My assembly descriptor takes advantage of a bug in this version where the explicit inclusion of a .tar.gz dependency does not have its own transitive dependencies included, unless they too are explicitly included. This is incorrect, because there is no ArtifactHandler that specifies that the .tar.gz file contains its own dependencies (so, therefore, should not have its transitive dependencies resolved, much less factored into inclusion/exclusion)...also, from a semantics point of view, Maven's other dependency usages indicate that specifying a dependency implies that you're specifying that dependency's transitive dependencies...the whole sub-graph should be handled, in other words. Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). You can say that the next version should make an effort to support users exploiting bugs like this, and you can say that plugins need to deprecate and gradually move away from behavior that has turned out to be bad design, counter-intuitive, etc. To this extent, you could argue that the next release that fixed the bug above should have made an allowance for this scenario. However, consider what happens if the plugin has been released several times...say that the newest version is actually 3.1 now. In this scenario, it's entirely reasonable to think that the developers have provided a long migration period - along with deprecation warnings - that spanned multiple versions, and then finally dropped the support for this broken configuration. However, Maven has no idea of any of this, and the aforementioned setup will break. All of this can be avoided by simply being careful about evaluating, then migrating, to new plugin versions in a very deliberate fashion. If you take a look at the world of systems administration, you see this sort of thing everywhere. People take enough time to pour over release notes and determine whether the new version is likely to wreck the
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
please move development discussions to maven-dev, there's already a thread about it there. On 4/11/07, Tom Huybrechts [EMAIL PROTECTED] wrote: Two more ideas: - Versioned lifecycles. Let a version of a lifecycle map to versions of each of its plugins. Allow users to override these by specifying explicit versions for the plugins. If you don't specify a version for the packaging, you get the old behaviour. - Have the maven-release-plugin add versions for all plugins, so you would at least have reproduciblity for releases. There must be a JIRA for this already, but I couldn't find it. Tom On 4/11/07, John Casey [EMAIL PROTECTED] wrote: I think that sort of plugin would be a great idea. For the plugins in the standard packaging lifecycles (to which you're referring, I believe), I still think that Maven should force you to supply a version for each one. It might make sense to have a version-set dependency or artifact that you can use to specify them as a group, so you have a sort of standardized toolchain for your build. This is possible via parent POM and pluginManagement today, but it is sort of orthogonal to normal inheritance in some ways, too... -john On 4/11/07, Tom Huybrechts [EMAIL PROTECTED] wrote: Don't forget you use a lot more plugins than you think. Who specifies versions for resources; compiler, surefire, install, deploy, clean, ... ? Maybe we need a plugin that can rewrite your POMs to specify versions for all the plugins that are used ? Tom On 4/11/07, Carlos Sanchez [EMAIL PROTECTED] wrote: I agree, automatic resolution of plugin versions is dangerous and you must use versions if you want reproducible builds. it's easy to add them to your parent pom in the pluginManagement section On 4/11/07, John Casey [EMAIL PROTECTED] wrote: Hi everyone, I wanted to send out a quick email to let everyone know about some discussion that's been taking place on the developers' list regarding plugin versions. In trying to release the 2.2-beta-1 version of the assembly plugin, it became apparent that this version fixes some bugs in the 2.1version that don't necessarily look like bugs. All discussion about what is or is not a bug aside, the discussion raises an interesting point: if you do not specify a version for the plugins in your POMs, a situation can arise where Maven will seamlessly resolve an incompatible plugin version and try to use it. Here's an example: Say I create a project that uses the assembly plugin, version 2.1. My assembly descriptor takes advantage of a bug in this version where the explicit inclusion of a .tar.gz dependency does not have its own transitive dependencies included, unless they too are explicitly included. This is incorrect, because there is no ArtifactHandler that specifies that the .tar.gz file contains its own dependencies (so, therefore, should not have its transitive dependencies resolved, much less factored into inclusion/exclusion)...also, from a semantics point of view, Maven's other dependency usages indicate that specifying a dependency implies that you're specifying that dependency's transitive dependencies...the whole sub-graph should be handled, in other words. Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). You can say that the next version should make an effort to support users exploiting bugs like this, and you can say that plugins need to deprecate and gradually move away from behavior that has turned out to be bad design, counter-intuitive, etc. To this extent, you could argue that the next release that fixed the bug above should have made an allowance for this scenario. However, consider what happens if the plugin has been released several times...say that the newest version is actually 3.1 now. In this scenario, it's entirely reasonable to think that the developers have provided a long migration period - along with deprecation warnings - that spanned multiple versions, and then finally dropped the support for this broken configuration. However, Maven has no idea of any of this, and the aforementioned setup will break. All of this can be avoided by simply being careful about evaluating, then migrating, to new plugin versions in a very
Re: Question regarding finalName in maven-assembly-plugin
On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: On Wed, Apr 11, 2007 at 01:27:42PM -0500, Michael Dick spake thus: *snip* It seems that the finalName *could* be added in an xml file in the repository. Whether it *should* be added is another issue. I did not think too much about that, but I guess that something like this *could* be implemented. There would still be some issues with snapshot deployments. Also, one has to be careful not to slow down the standard case by an extra file access. I have projects that create artifacts with a 'finalName' set, and these artifacts get installed/deployed with the wrong file names (that is, not what I specified in 'finalName'). In all of my cases, these artifacts do not need to be accessible by maven for build purposes, so the fact that the files are installed and deployed with names different from what I specified in 'finalName' is simply an annoyance (because I then have to rename the files on the deployment server by hand). Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. Why insist to put something into a *maven* repository if there is no intention to access it by maven? Wouldn't it be more useful to be able to publish to a different place? I don't know, if there already is a plugin achieving that, but it would not be too hard to build. Henry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
On Wed, Apr 11, 2007 at 09:45:17PM +0200, Heinrich Nirschl spake thus: *snip* On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. Why insist to put something into a *maven* repository if there is no intention to access it by maven? Wouldn't it be more useful to be able to publish to a different place? I don't know, if there already is a plugin achieving that, but it would not be too hard to build. Henry I'm not insisting on it; in fact, I like your idea much better ;-) Our current practice of deploying all of our artifacts to our internal maven repository came about because the infrastructure was already in place and accessible by everyone who needed access to the artifacts. Now that you mention it, though, it would make sense to have an arbitrary deployment plugin. There is precedence for this with other specialized deployment plugins (cargo, tomcat, probably others). -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven users in the industry
We have helped Fortune 2000 companies to adopt Maven, technology companies, financial and educational institutions. On 4/11/07, Gilles Scokart [EMAIL PROTECTED] wrote: Hi, Next week I have to make a presentation to my collegues. I will try to 'sell' maven, and I would like to say something like Look, Maven is now very used in the industry, It's for instance used by Did you know any companies using Maven, more particularily in Belgium and Europe, but worlwide would be ok also? Thanks for your help. Gilles -- View this message in context: http://www.nabble.com/Maven-users-in-the-industry-tf3557876s177.html#a9934912 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MAVEN][2.0.6] Module dependencies using site-deploy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. Hi, Indeed the bug seems to be the same... This also means the site is build using obsolete data from the repository, and not the last building versions... As far as I understand, this only applies to parts of the site (the javadocs) but NOT on everything. It should work fine for the build itself (mvn package). Are you aware of some kind of workaround, except what I'm use to do running Maven twice ? Running maven twice is what I do for CI. Together with -fn -npu BTW: seems that most of the Java world never understood the GNU conventions for commandline options following SUN's mistakes ;). Thanks. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHVwsmPuec2Dcv/8RAhbvAJ9LpbzrARjbAW4K8pMHDw98GjetlQCfbnoU 7FVT9lCSFyl0XkzIYG1szxc= =Muhx -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Two instances of Continuum
Can you run two instances of continuum on the same server if you change the two ports? Is there anything special that needs to be configured to make this work? Thanks. -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
Re: Question regarding finalName in maven-assembly-plugin
I'm not insisting on it either. The artifacts were deployed automatically when we deploy the parent project. As far as I know we don't need them in the repository though. I'll have to take a closer look. Thanks for your help. On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: On Wed, Apr 11, 2007 at 09:45:17PM +0200, Heinrich Nirschl spake thus: *snip* On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. Why insist to put something into a *maven* repository if there is no intention to access it by maven? Wouldn't it be more useful to be able to publish to a different place? I don't know, if there already is a plugin achieving that, but it would not be too hard to build. Henry I'm not insisting on it; in fact, I like your idea much better ;-) Our current practice of deploying all of our artifacts to our internal maven repository came about because the infrastructure was already in place and accessible by everyone who needed access to the artifacts. Now that you mention it, though, it would make sense to have an arbitrary deployment plugin. There is precedence for this with other specialized deployment plugins (cargo, tomcat, probably others). -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Michael Dick
Re: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous
On 4/12/07, John Casey [EMAIL PROTECTED] wrote: Here's an example: [del] Having created this project with its assembly descriptor, but WITHOUT A VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some time later, after the next version of the assembly plugin fixes this bug, a user comes along. He installs Maven, checks out my project, and tries to build. Without a single line of code changing in my project, the build fails, because his Maven instance resolved the plugin to the newer version. I cannot replicate his failed build, because my assembly-plugin version had not been updated (I didn't use -U during the build). This is how I see things: User checks out HEAD, then they are living on the bleeding edge and the project develoeprs should be able to reproduce the user problems since a mvn -U will bring all plugins in line with a new users. User checks out TAG, then the tagged pom.xml should automatically be transformed as part of the release process to lock down and specify everything to make the build reproducible. If you are building this project 20 years from now (and assuming central hasn't been blown away and lost old plugins) then you can rebuild the project as you are using known versions for everything. It does not matter that newer versions of the plugins are available, they are never used. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven Site Published Time Stamp
Yes you can add the HH:mm to the end of the format to get the time the site was generated -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: April 11, 2007 9:39 AM To: Maven Users List Subject: Re: Maven Site Published Time Stamp On 4/11/07, Hodanics, Charles J. [EMAIL PROTECTED] wrote: I am curious if anyone knows of a way to include the time in the Last Published: date that is created in the header of a generated site. There is an example of changing the position and formatting of the date in the site plugin docs: http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html I haven't checked, but my guess is that it follows the usual SimpleDateFormat rules: http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Writting mojos in Groovy?
Thanks Dennis! That's cool and I managed to get hooked up with version 1.0-alpha-2. Is that the latest / correct version? So now I have MyMojo.groovy that is compiling happily. However, the plugin plugin generates plugin.xml. I need to either (a) tell it not to do that so that I can create it by hand or (b) tell it to generate it from MyMojo.groovy. James CE Johnson wrote: Can anybody point me to a how-to or recipe or good blog entry on creating a mojo in groovy? Thanks, James You're in luck! The Groovy Maven Plugin has just been released. Check it out here: http://mojo.codehaus.org/groovy-maven-plugin/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple artifacts
Thanks Franz for your answer - yes, you understood the problem perfectly. I had gone through the debugger and noticed that setArtifacts was getting called after my plug-in was called. I have solved the problem (partially) by adding the Jar file to DependencyArtifacts in MavenProject. This works for compile but doesn't work for Eclipse project generation. How can I solve Eclipse project issue? -Original Message- From: franz see [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 8:07 PM To: [EMAIL PROTECTED] Subject: Re: Multiple artifacts Good day, AFAIU, you have a single maven project that packages several binaries and adds them to the classpaths via a plugin that you've created. But the binary that you add via your plugin gets overriden by the binary added via maven's transitive dependencyDid I get that right? Curious, what made you think that that binary gets overriden? Maybe your classpath issue is a plugin specific problem ( i.e. a plugin only uses the classpath maven made and not yours ). Cheers, Franz Goel, Deepak wrote: I have a project that builds multiple artifacts - a jar, a DLL and others that are shared by the Jar and DLL. For various reasons, we have decided to create a single POM that has plug-ins in right phases to build the DLL. So we decided to package this as a ZIP that gets unzipped at the right time. We also have a plug-in that adds the Jar file as a dependency. The issue is that dependency on Jar file gets overwritten during transitive dependency resolution. Interestingly, the direct dependencies aren't affected. For example, if there's a project C that depends on B. B in turn depends on A. When I compile C, B.jar remains in the classpath but A.jar gets removed. I have verified that the plug-in indeed adds A.jar. I'll appreciate if somebody can help me resolve this issue. Deepak Goel | Small Business Division, Intuit | direct - (650) 944-3287 -- View this message in context: http://www.nabble.com/Multiple-artifacts-tf3550158s177.html#a9932478 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
how can i compile a multiple directories with pom.xml?
All, If I have a directory src and subdirectories a, b and c. Each subdirectories have their own pom.xml files. Output of a depends on b, and b on c. Is it possible to have a pom.xml in src directory and start compilation in directory c, then b then a? Thanks. A. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how can i compile a multiple directories with pom.xml?
Ideally you would just make multiple poms ie: toplevel/pom.xml (modules a, b, c) toplevel/a/pom.xml (no dependencies) toplevel/b/pom.xml (depends on a) toplevel/c/pom.xml (depends on b) Wayne On 4/11/07, Baz [EMAIL PROTECTED] wrote: All, If I have a directory src and subdirectories a, b and c. Each subdirectories have their own pom.xml files. Output of a depends on b, and b on c. Is it possible to have a pom.xml in src directory and start compilation in directory c, then b then a? Thanks. A. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple artifacts
Good day, After a quick browse through the eclipse plugin's code ( see [1] ), I'd suggest you do a getProject().getDependencies().addAll( your dependencies ). It seems to be using getProject().getDependencies() as a basis for the eclipse project generation. I am not sure though the difference between dependencies and dependencyArtifacts ( aside from the former being a ListDependency while the latter a SetArtifact), and how to properly use them :) Cheers, Franz Goel, Deepak wrote: Thanks Franz for your answer - yes, you understood the problem perfectly. I had gone through the debugger and noticed that setArtifacts was getting called after my plug-in was called. I have solved the problem (partially) by adding the Jar file to DependencyArtifacts in MavenProject. This works for compile but doesn't work for Eclipse project generation. How can I solve Eclipse project issue? -Original Message- From: franz see [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 8:07 PM To: [EMAIL PROTECTED] Subject: Re: Multiple artifacts Good day, AFAIU, you have a single maven project that packages several binaries and adds them to the classpaths via a plugin that you've created. But the binary that you add via your plugin gets overriden by the binary added via maven's transitive dependencyDid I get that right? Curious, what made you think that that binary gets overriden? Maybe your classpath issue is a plugin specific problem ( i.e. a plugin only uses the classpath maven made and not yours ). Cheers, Franz Goel, Deepak wrote: I have a project that builds multiple artifacts - a jar, a DLL and others that are shared by the Jar and DLL. For various reasons, we have decided to create a single POM that has plug-ins in right phases to build the DLL. So we decided to package this as a ZIP that gets unzipped at the right time. We also have a plug-in that adds the Jar file as a dependency. The issue is that dependency on Jar file gets overwritten during transitive dependency resolution. Interestingly, the direct dependencies aren't affected. For example, if there's a project C that depends on B. B in turn depends on A. When I compile C, B.jar remains in the classpath but A.jar gets removed. I have verified that the plug-in indeed adds A.jar. I'll appreciate if somebody can help me resolve this issue. Deepak Goel | Small Business Division, Intuit | direct - (650) 944-3287 -- View this message in context: http://www.nabble.com/Multiple-artifacts-tf3550158s177.html#a9932478 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Multiple-artifacts-tf3550158s177.html#a9953319 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple artifacts
Pardon, [1] is http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin :) franz see wrote: Good day, After a quick browse through the eclipse plugin's code ( see [1] ), I'd suggest you do a getProject().getDependencies().addAll( your dependencies ). It seems to be using getProject().getDependencies() as a basis for the eclipse project generation. I am not sure though the difference between dependencies and dependencyArtifacts ( aside from the former being a ListDependency while the latter a SetArtifact), and how to properly use them :) Cheers, Franz Goel, Deepak wrote: Thanks Franz for your answer - yes, you understood the problem perfectly. I had gone through the debugger and noticed that setArtifacts was getting called after my plug-in was called. I have solved the problem (partially) by adding the Jar file to DependencyArtifacts in MavenProject. This works for compile but doesn't work for Eclipse project generation. How can I solve Eclipse project issue? -Original Message- From: franz see [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 8:07 PM To: [EMAIL PROTECTED] Subject: Re: Multiple artifacts Good day, AFAIU, you have a single maven project that packages several binaries and adds them to the classpaths via a plugin that you've created. But the binary that you add via your plugin gets overriden by the binary added via maven's transitive dependencyDid I get that right? Curious, what made you think that that binary gets overriden? Maybe your classpath issue is a plugin specific problem ( i.e. a plugin only uses the classpath maven made and not yours ). Cheers, Franz Goel, Deepak wrote: I have a project that builds multiple artifacts - a jar, a DLL and others that are shared by the Jar and DLL. For various reasons, we have decided to create a single POM that has plug-ins in right phases to build the DLL. So we decided to package this as a ZIP that gets unzipped at the right time. We also have a plug-in that adds the Jar file as a dependency. The issue is that dependency on Jar file gets overwritten during transitive dependency resolution. Interestingly, the direct dependencies aren't affected. For example, if there's a project C that depends on B. B in turn depends on A. When I compile C, B.jar remains in the classpath but A.jar gets removed. I have verified that the plug-in indeed adds A.jar. I'll appreciate if somebody can help me resolve this issue. Deepak Goel | Small Business Division, Intuit | direct - (650) 944-3287 -- View this message in context: http://www.nabble.com/Multiple-artifacts-tf3550158s177.html#a9932478 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Multiple-artifacts-tf3550158s177.html#a9953320 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how can i compile a multiple directories with pom.xml?
Good day, Try [1]. Cheers, Franz [1] http://mojo.codehaus.org/build-helper-maven-plugin/howto.html Wayne Fay wrote: Ideally you would just make multiple poms ie: toplevel/pom.xml (modules a, b, c) toplevel/a/pom.xml (no dependencies) toplevel/b/pom.xml (depends on a) toplevel/c/pom.xml (depends on b) Wayne On 4/11/07, Baz [EMAIL PROTECTED] wrote: All, If I have a directory src and subdirectories a, b and c. Each subdirectories have their own pom.xml files. Output of a depends on b, and b on c. Is it possible to have a pom.xml in src directory and start compilation in directory c, then b then a? Thanks. A. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/how-can-i-compile-a-multiple-directories-with-pom.xml--tf3563309s177.html#a9953345 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
