Re: Grouping related projects

2004-11-18 Thread Nicolas . CHALUMEAU
Use the multiproject with a directory structure like /root /common-prj1 /common-prj2 ... /common-all common-prj* are maven.multiproject.type=jar common-all is maven.multiproject.type=uberjar and have all the common-prj* in his dependancies On the root dir using

Re: Grouping related projects

2004-11-18 Thread Brett Porter
this is definitely the right approach, but be aware uberjar is a JAR of JARs, not jar of all classes. if you want a JAR of all classes, that's something you will need to aggregate yourself at this point. Cheers, Brett On Thu, 18 Nov 2004 09:50:07 +0100, [EMAIL PROTECTED] [EMAIL PROTECTED]

Re: Property maven.home.local always uses default value?

2004-11-18 Thread Ralf Quebbemann
I have filed a bug and found a workaround for the issue: - Create the file build.properties in ${user.home} and set the property maven.home.local to the desired directory. This should work for now. Keep up the great work Ralf Brett Porter wrote: please file a bug. It seems related to a

Re: Setting properties in maven.xml

2004-11-18 Thread Andrew Watters
Excellent, thanks Dan, that works. Still making the mental step from ant to maven when it comes to writing goals. dan tran wrote: try this, j:set var=maven.tomcat.precompile value=false/ -D On Wed, 17 Nov 2004 10:43:30 +, Andrew Watters [EMAIL PROTECTED] wrote: Is it possible to set

Re: XDoclet in Maven

2004-11-18 Thread Jose Gonzalez Gomez
Eric, Any news regarding this? I have taken a look at the web, but I still cannot find the 1.2.2 version of the plugin. Best regards Jose Eric Pugh wrote: I am in the process of updating the XDoclet repository at http://xdoclet.sf.net/repository. I have everything bug the newest

RE: Grouping related projects

2004-11-18 Thread Steve Molloy
I came across the same problem and ended up writing a custom goal (actually a simple plugin because it's used in more then 1 project) which I run as preGoal to the standard java:jar-resources. It simply unjars the dependencies having the jar.bundle property set to true and then the jar goal

maven cvs commit goal?

2004-11-18 Thread erdem kilic
Hi, I want to cvs commit with maven.. is there a goal for this job? Thank you very much.. Erdem - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Réf. : maven cvs commit goal?

2004-11-18 Thread Nicolas . CHALUMEAU
What you want is the ant:cvs task. Example for checkout in the scm plugin it is done with : ant:cvs command=checkout ${maven.scm.cvs.checkout.flags} quiet=${maven.scm.cvs.quiet} cvsRsh=${maven.scm.cvs.rsh} cvsRoot=${maven.scm.cvs.root} dest=${maven.scm.checkout.dir}

Re: XDoclet in Maven

2004-11-18 Thread Pascal Thivent
Jose, as you can see at http://xdoclet.sourceforge.net/repository/xdoclet/plugins/, the plugin is still not available in xdoclet repository. I guess Eric still has some write access problems. So you can't use for now the plugin:download goal (see a previous mail for the exact command). Anyway,

Problems downloading dependencies in 1.0.1

2004-11-18 Thread Adrian Tarau
Hi, I'm using Maven 1.0 and I want to switch to release 1.0.1 but I have some problems with some dependencies. We have a local repository, mirrored after ibiblio/maven and I get an error when it tries to download some jars added by me in the repository manually. All the jars that came from

RE: XDoclet in Maven

2004-11-18 Thread Ryan Sonnek
you can put a list of remote repositories in the project.properties. then every developer doesn't need to specify this. in my project.properties I always set it to include maven-plugins.sf.net and ibiblio since my project depends on plugins/jars from both of these places. -Original

Re: XDoclet in Maven

2004-11-18 Thread Jose Gonzalez Gomez
Well, you still may have maven.repo.remote defined in your project.properties shared among all your developers (we do so), and as soon as you can specify a plugin as a dependency (maven 1.1?) there will be no problem to keep all the developers' plugins updated. Best regards Jose

RE: Problems downloading dependencies in 1.0.1

2004-11-18 Thread Jean-Marc Lavoie
That looks like my first experience with the properties not being inherited. Check if you have a sub project that rely on the maven.repo.remote property being inherited from the parent project.properties . In wich cases, ibilio repository will be used instead of your repository, jars originnally

RE: Problems downloading dependencies in 1.0.1

2004-11-18 Thread Adrian Tarau
Hi, Yes, it is a multi project and I checked the settings for the repository. The settings are only in the multiproject project.xml(You can see it bellow) and the sub-projects doesn't override this properties. As I told you with Maven 1.0 everything works, but with 1.0.1 is not working.

Re: XDoclet in Maven

2004-11-18 Thread Pascal Thivent
From my point of view, this is a configuration management issue that should be addressed with a SCM tool. On Thu, 18 Nov 2004 17:24:19 +0100, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: Well, you still may have maven.repo.remote defined in your project.properties shared among all your

Re: j2ee sample multiproject problem

2004-11-18 Thread jsona laio
Thanks your help Brett. After switching to maven 1.0.1. The problem can be solved. --- Brett Porter [EMAIL PROTECTED] wrote: I'm not certain if multiproject:artifact existed in Maven 1.0 RC2. You should upgrade to the latest Maven release: releases prior to 1.0 are no longer supported.

RE: XDoclet in Maven

2004-11-18 Thread Eric Pugh
I am working on getting the plugin up on XDoclet's repo (file system permission problems). If you could contribute a patch on the xdoclet-dev list with better documentation, that would be great. Also, what would help is if you can submit some fileupload requests for the various XDoclet jars [1].

RE: Problems downloading dependencies in 1.0.1

2004-11-18 Thread Jean-Marc Lavoie
Property inheritance in 1.0.1 is partly broken, there have been some post on it already and a Jira filed on this issue. The value does not get inherited, so you use ibiblio repository without knowing it, and of course it does not contain your custom jars. On my work projects, we will wait

RE: Problems downloading dependencies in 1.0.1

2004-11-18 Thread Adrian Tarau
Thanks, I thought was something broken in this release. I think I will wait for the next release(version 1.0 works ok). -Original Message- From: Jean-Marc Lavoie [mailto:[EMAIL PROTECTED] Sent: Thursday, November 18, 2004 12:27 PM To: Maven Users List Subject: RE: Problems downloading

Re: Problems with dependencies in WAR file

2004-11-18 Thread Brett Porter
You can find more in the archives, but essentially two dependencies where only the types differ are not recognised as distinct. Fixed in CVS HEAD for 1.1. - Brett On Thu, 18 Nov 2004 10:57:01 -0500, Alex Rodriguez [EMAIL PROTECTED] wrote: Hi, I have a problem with the WAR Plugin. I'm

do something before *.properties files load

2004-11-18 Thread Ben Anderson
Hi, I'd like to set a property based on some other command line property. For instance if: maven -Denv=qa java:compile I'd like this: build.properties --- some.arbitrary.property=qaValue but if maven -Denv=prod java:compile I'd like this: build.properties

Re: do something before *.properties files load

2004-11-18 Thread Brett Porter
1) Can I embed jelly in my build.properties files? The answer to the question you were trying to ask is yes, but to this specific one, no. Jelly is the XML scripting, JEXL is the expression language used in Jelly. You can use an expression in build.properties, but not embed Jelly - just in case

Multiple test types?

2004-11-18 Thread Barry Kaplan
Our project has several different types of tests: unit, functional, performance, etc. Is there any concept of this in maven? We have in the past kept them all in the same directory, and at other times split them each into their own directory. We also prefix the class name with an indicator

RE: Multiple test types?

2004-11-18 Thread Ryan Sonnek
I think it'd be great for maven to have the concept of multiple test directories like: src/test for unit tests src/int-test for integration tests etc but as it stands now, the most straightforward approach (ie: the least hacking required) is to create a seperate sub-project for each group of

Use of ${version_num} in dependency?

2004-11-18 Thread Barry Kaplan
If I did in maven.xml: ant:property file=version-info.properties/ And then in project.xml: dependency groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId version${commons_logging_version}/version /dependency Should this work? The dependency

Re: Use of ${version_num} in dependency?

2004-11-18 Thread Brett Porter
you will need to put it into project.properties for that to work. However, there is a built in mechanism for that: jar overrides. in project.properties: maven.jar.override=on maven.jar.commons-logging=1.0.4 Cheers, Brett On Thu, 18 Nov 2004 18:27:55 -0500, Barry Kaplan [EMAIL PROTECTED] wrote:

Re: Use of ${version_num} in dependency?

2004-11-18 Thread Barry Kaplan
Brett Porter wrote: you will need to put it into project.properties for that to work. Seems that project.properties is not inherited to multiprojects (no?). So this approach will not work for sharing version numbers across all the subprojects. -- barry kaplan [EMAIL PROTECTED]

Re: Use of ${version_num} in dependency?

2004-11-18 Thread Barry Kaplan
Brett Porter wrote: It is inherited wherever project.xml is. I copied the project.properties (container the version numbers) down to the subproject. The ${..} were still not used in downloading the jar. The attempt to download looked something like: Attempting to download commons-logging-.jar.

Re: Use of ${version_num} in dependency?

2004-11-18 Thread Brett Porter
I'd highly recommend using the JAR override mechanism I mentioned as it is properly supported by more plugins. Regards, Brett On Thu, 18 Nov 2004 22:37:57 -0500, Barry Kaplan [EMAIL PROTECTED] wrote: Brett Porter wrote: It is inherited wherever project.xml is. I copied the

Re: Use of ${version_num} in dependency?

2004-11-18 Thread Barry Kaplan
Brett Porter wrote: It is inherited wherever project.xml is. Yes, of course you are correct. What is not inherited is 'project.propeties' :-) Thanks Brett! All works great now. -- barry kaplan [EMAIL PROTECTED] - To unsubscribe,

Re: Use of ${version_num} in dependency?

2004-11-18 Thread Brett Porter
I'm not sure what you mean: project.properties IS inherited as long as project.xml is. What version of Maven are you using? - Brett On Thu, 18 Nov 2004 22:49:20 -0500, Barry Kaplan [EMAIL PROTECTED] wrote: Brett Porter wrote: It is inherited wherever project.xml is. Yes, of course you are

Re: Use of ${version_num} in dependency?

2004-11-18 Thread Barry Kaplan
Brett Porter wrote: I'm not sure what you mean: project.properties IS inherited as long as project.xml is. 'project.propeties' :-) project.properties I had a typo. I just switched to the jar overrides, and its perfect. I'll let the activemq and geronimo guys know. They were using entities for