Re: maven jelly tag and build.properties properties
On Wed, 2004-01-14 at 17:55, Gilles Dodinet wrote:
> Ebersole, Steven wrote:
>
> > actually, my bad. it does not work. it is maven.build.dest that works, not
> > maven.test.dest
>
>
> heres my understanding of it, i may be wrong - correct me if am :
>
> maven.build.dest should always be available (core behavorial property),
> maven.test.dest is being made available by the test plugin,
> so to look it up we have to use the context of the test plugin..
> however, if specified in build.properties, this late property becomes
> always available. the few tests ive just made tend to confirm it (using
> both ${maven.test.dest} and ${pom.getPluginContext...) and
> value="${pom.getPluginContext('maven-test-plugin').getVariable('maven.test.dest')}"/>
> does work just fine for me, returning the expected result.
There is also the relatively new pluginVar tag to help with this:
>
> -- gd
>
>
> -
> 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: single artifact mantra and ejb projects
Hi, Ryan, I just reviewed your wiki posting pretty extensively and found it to be a great help. However, I've had a problem with the part about running 'maven multiproject:install' in the root project. I get this error: Starting the reactor... BUILD FAILED File.. file:/C:/Documents and Settings/Rob/.maven/plugins/maven-multiproject-plugin-1.1/ Element... maven:reactor Line.. 174 Column 9 IO error scanning directory c:\WUTemp\myproject\root\..\ Total time: 3 seconds Finished at: Wed Jan 14 18:37:35 CST 2004 Have you seen this kind of thing before? Also, I was curious about your statement regarding Eclipse compatibility. Can you offer a bit more on what happens within Eclipse if the more 'traditional' approach is taken? I find the root project difficult to swallow -- but will accept it if I must. :^) Thanks, Rob Sonnek, Ryan wrote: I just finished added an entry to the wiki about how I have structured my EJB project. I would be very interested in hearing some feedback if it is on target with what other developers are doing. http://wiki.codehaus.org/maven/CreatingEjbApplications Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven jelly tag and build.properties properties
Not sure if any of the developers of the idea plugin are around here, but I basically
modified my plugin locally because it was not fully defining the intellij project
files for me correctly. This change was specifically to the v3 resources.
Specifically, it was not:
1) setting up any compiler output path(s) at all;
2) correctly setting up cvs support
My local version defines one new property (maven.idea.output.mode=single/multiple).
Depending on the value set, project.jelly appropriately sets the intellij OUTPUT_MODE
abd DEFAULT_OUTPUT_PATH properties, and possibly the element.
Also made changes to workspace.jelly to get cvs support working after plugin execution.
If you're interested in the source or patch, let me know...
-Original Message-
From: Ebersole, Steven
Sent: Wednesday, January 14, 2004 5:30 PM
To: Maven Users List
Subject: RE: maven jelly tag and build.properties properties
Thanks for the help. What I did was to simply (re?)define it in the specific
plugin.properties file to be its defined default using
maven.test.dest=${maven.build.dir}/test-classes, and everything started working.
Woohoo...
-Original Message-
From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 4:56 PM
To: Maven Users List
Subject: Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
> actually, my bad. it does not work. it is maven.build.dest that works, not
> maven.test.dest
heres my understanding of it, i may be wrong - correct me if am :
maven.build.dest should always be available (core behavorial property),
maven.test.dest is being made available by the test plugin,
so to look it up we have to use the context of the test plugin..
however, if specified in build.properties, this late property becomes
always available. the few tests ive just made tend to confirm it (using
both ${maven.test.dest} and ${pom.getPluginContext...) and
does work just fine for me, returning the expected result.
-- gd
-
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]
RE: maven jelly tag and build.properties properties
Thanks for the help. What I did was to simply (re?)define it in the specific
plugin.properties file to be its defined default using
maven.test.dest=${maven.build.dir}/test-classes, and everything started working.
Woohoo...
-Original Message-
From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 4:56 PM
To: Maven Users List
Subject: Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
> actually, my bad. it does not work. it is maven.build.dest that works, not
> maven.test.dest
heres my understanding of it, i may be wrong - correct me if am :
maven.build.dest should always be available (core behavorial property),
maven.test.dest is being made available by the test plugin,
so to look it up we have to use the context of the test plugin..
however, if specified in build.properties, this late property becomes
always available. the few tests ive just made tend to confirm it (using
both ${maven.test.dest} and ${pom.getPluginContext...) and
does work just fine for me, returning the expected result.
-- gd
-
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 jelly tag and build.properties properties
Ebersole, Steven wrote:
actually, my bad. it does not work. it is maven.build.dest that works, not maven.test.dest
heres my understanding of it, i may be wrong - correct me if am :
maven.build.dest should always be available (core behavorial property),
maven.test.dest is being made available by the test plugin,
so to look it up we have to use the context of the test plugin..
however, if specified in build.properties, this late property becomes
always available. the few tests ive just made tend to confirm it (using
both ${maven.test.dest} and ${pom.getPluginContext...) and
does work just fine for me, returning the expected result.
-- gd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: single artifact mantra and ejb projects
I just finished added an entry to the wiki about how I have structured my EJB project. I would be very interested in hearing some feedback if it is on target with what other developers are doing. http://wiki.codehaus.org/maven/CreatingEjbApplications Ryan -Original Message- From: Sonnek, Ryan [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 2:47 PM To: 'Maven Users List' Subject: RE: single artifact mantra and ejb projects I would be very interested to hear other peoples opinion on this as well. I'm currently working on 4 separate EJB projects and have gone through this same situation. I have heard talk on the mailing list about adding support for an artifact type "ejb-client.jar", but I don't remember who was looking into that. I've used the multiproject setup you've listed above, and with a little hack on the xdoclet plugin, got it up and running without any major problems. I would really like to flesh out some kind of "maven methodology" on this subject as I know it is a big area of question. I might put some time into putting something on the wiki regarding this. Ryan -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 7:25 AM To: Maven Users List Subject: single artifact mantra and ejb projects I have a question about the mantra that a single project should produce a single artifact. I can buy into that in every case I have run across or have thought about, except for projects involving ejb creation. Typically an ejb project will produce both an ejb-jar file as well as a client-jar file. But wouldn't that be two artifacts? I have read a lot of external docs on setting up j2ee projects using maven, most of which suggest a multi project layout. I can totally justify that for say a j2ee project producing an ear made up of sub ejb-jars and wars. But in the case of a stand-alone ejb-jar producing project or an ejb-jar producing subproject of an ear project it seems like overkill to define a subproject for the ejb-jar generation and the client-jar generation, especially when both are ultimately logically tied to the attainment of an ejb goal. Could someone help me out in my understanding here? Thanks, Steve - 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]
[SOLVED]Re: Getting a list of directories in a variable
Silly me, I had the solution just in front of my eyes on a webpage I've
googled an hour ago. I haven't seen it anywhere in the plugins, so here
it goes:
${networkDirs}
Best Regards,
David Garnier
Le mer 14/01/2004 à 23:05, David Garnier a écrit :
> Hello,
>
> I would like to collect a list of directory in a variable, in order to
> feed a foreach loop. I have several datasets, each one composed of 3
> files. Each dataset is in a different directory, and every directory is
> in a directory called network. Today, I just move the right dataset in
> place, build it and move away the result. Example:
>
>
>delim=",">${networkDirs}
>
>
>
>
> Packaging ${network}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> This work quite well but I would like to collect the names of the
> directory automatically. I have hundreds of them...
>
> Best Regards,
--
David Garnier <[EMAIL PROTECTED]>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Getting a list of directories in a variable
Hello,
I would like to collect a list of directory in a variable, in order to
feed a foreach loop. I have several datasets, each one composed of 3
files. Each dataset is in a different directory, and every directory is
in a directory called network. Today, I just move the right dataset in
place, build it and move away the result. Example:
${networkDirs}
Packaging ${network}
This work quite well but I would like to collect the names of the
directory automatically. I have hundreds of them...
Best Regards,
--
David Garnier <[EMAIL PROTECTED]>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running Maven on an Alpha using Compaq Tru64 UNIX V5.1B (Rev. 2650)
I was premature in my report. Maven still doesn't run on Alpha. I've tracked the problem down to the maven-xdoc-plugin-1.4/plugin.jelly when it tries to register a report using the I suspect the problem is something similar to junit class loading issue which necessities the property "maven.junit.fork=yes" If I run the report register goal directly, maven succeeds. The problem occurs when the report registration is called from xdoc:register-reports. I.E. "maven maven-junit-report-plugin:register" succeeds whereas "maven xdoc:register-reports" fails. If there is any experienced java developer who would care to comment with workaround suggestions, I would appreciate that. Erik Husby wrote: Well, it is obviously a bug in the Alpha JVM. The default JVM is the "fast" one which is known to have some problems with native code (ie. the code that access the file system to find jars and other useful things). So by setting MAVEN_OPTS to "-Xmx256mb -classic", I can force the JVM into classic mode which appears to run. Erik Husby wrote: I've installed Maven-1.0-RC1 on my Windows XP system and my Alpha using Compaq Tru64 UNIX V5.1B (Rev. 2650); Using a shared drive, if I build the project on the Windows XP system, it works fine. But if I build, using the same set of files on the Unix box, Maven fails to load the JUnitTask as shown below. --- Unix Maven 107 11:41am [EMAIL PROTECTED] ~/workarea/SquidBuild/sequence/common > maven test:test __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT java:prepare-filesystem: java:compile: [echo] Compiling to /home/radon00/mhusby/workarea/SquidBuild/sequence/common/target/classes BUILD FAILED File.. file:/home/radon00/mhusby/.maven/plugins/maven-test-plugin-1.4/ Element... taskdef Line.. 89 Column 9 taskdef class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask cannot be found Total time: 12 seconds Finished at: Thu Jan 08 11:41:49 EST 2004 7.487u 5.990s 0:14.39 93.6%0+581k 10+30io 0pf+0w 108 11:41am [EMAIL PROTECTED] ~/workarea/SquidBuild/sequence/common > --- Windows XP Maven F:\workarea\SquidBuild\sequence\common>maven test __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT Attempting to download maven-SNAPSHOT.jar. Overriding previous definition of reference to clover.classpath java:prepare-filesystem: java:compile: [echo] Compiling to F:\workarea\SquidBuild\sequence\common/target/classes java:jar-resources: test:prepare-filesystem: test:test-resources: test:compile: test:test: [junit] Running edu.mit.wi.genome.common.dba.AllTests [junit] Tests run: 29, Failures: 0, Errors: 1, Time elapsed: 3.225 sec Its like Maven can't find its jar files. I've verified that $MAVEN_HOME/lib contains the same set of jar files on both systems. Any suggestions on things to look at would be really appreciated. -- Erik Husby Team Lead for Software Quality Automation Genome Center at MIT Rm. 2192 320 Charles St Cambridge, MA 02141-2023 mobile: 781.354.6669 office: 617.258.9227 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven jelly tag and build.properties properties
actually, my bad. it does not work. it is maven.build.dest that works, not
maven.test.dest
so what I have:
does not work because , sets
testDestProp equal to "".
I also tried:
to no avail.
Any thoughts? No idea why maven.build.dest would work, but not maven.test.dest...
-Original Message-
From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 3:11 PM
To: Maven Users List
Subject: Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
>but this works for me even without the namespacing:
>
>m.t.d = ${maven.test.dest}
>
uh ! right.. it works when it is defined in the properties file.. i
forgot your original question.. my bad
-- gd
-
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: Junit report failure
I'm stupid. I set maven.test.skip=true
junitreport blew up because there were no test report files
- Original Message -
From: "Cary Coulter" <[EMAIL PROTECTED]>
To: "Maven Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 14, 2004 9:47 AM
Subject: Junit report failure
> my junit tests always fail with the following exception. In searching, I
> have found several proect pages on the net with the same error " formatting: 'NaN' with '0.00%'>" in the "Success Rate" column at teh top
of
> the junit-report.html page
>
> There is a test to be run.
>
> Thanks in advance,
> Cary
>
>
> ==
> test:test:
>
> [junitreport] [DEBUG] fileset: Setup scanner in dir
> /home/cacc/workspace/COM/enterprise/target/test-reports with patternSet{
> includes: [TEST-*.xml] exclud
> es: [] }
>
> java.lang.NumberFormatException: NaN
> at
> java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1171)
> at java.lang.Double.valueOf(Double.java:163)
> at
> org.apache.maven.util.DVSLFormatter.formatNumber(DVSLFormatter.java:113)
> at java.lang.reflect.Method.invoke(Native Method)
> at
>
org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invok
> e(UberspectImpl.java:304)
> at
> org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:56)
> at
> org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:106)
> at
> org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:88)
> at
> org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:123)
> at
>
org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExpress
> ion.java:115)
> at
>
org.apache.commons.jelly.expression.jexl.JexlExpressionFactory$ExpressionSup
> portLocal.evaluate(JexlExpressionFactory.java:168)
> at
>
org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(Expres
> sionSupport.java:106)
> at
>
org.apache.commons.jelly.expression.ExpressionSupport.evaluateAsString(Expre
> ssionSupport.java:91)
> at
>
org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java:112
> )
> at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
> at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
> at
> org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
> at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
> at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
> at
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:111)
> at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:318)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
> at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
> at
> org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
> at
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:111)
> at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:318)
> at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
> at
> org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
> [snip]
>
> -
> 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 jelly tag and build.properties properties
Ebersole, Steven wrote:
but this works for me even without the namespacing:
m.t.d = ${maven.test.dest}
uh ! right.. it works when it is defined in the properties file.. i
forgot your original question.. my bad
-- gd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Child project using parent sources
Sure can, thx for that one :)
But since maven builds most of its properties on {basedir}, i guess then
that the clean way to change maven.build.dir would be to override in the
same manner this property in the build.properties of that "sub-project"?
Eric.
Sonnek, Ryan wrote:
Couldn't you just change the child's to point to the
parent?
${basedir}/../src/java
-Original Message-
From: Eric Giguere [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 2:58 PM
To: Maven Users List
Subject: Child project using parent sources
Hi all
Is there a property somewhere in the projet that can be set to tell a
sub project to use the parents directories? I'm trying to build multiple
jars using multiple maven projects but each uses its own sources and
targets. The class files are in the parent's target.
thx for any advice
Eric.
-
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]
RE: maven jelly tag and build.properties properties
but this works for me even without the namespacing:
m.t.d = ${maven.test.dest}
-Original Message-
From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 2:51 PM
To: Maven Users List
Subject: Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
>Same error message. Tried using a bunch of different plugin contexts (test, java,
>idea)...
>
do you "import" the test context by declaring the 'test' namespace ?
this works for me :
m.t.d =
${pom.getPluginContext('maven-test-plugin').getVariable('maven.test.dest')}
-- gd
-
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 running Maven on an Alpha using Compaq Tru64 UNIX V5.1B (Rev. 2650)
Well, it is obviously a bug in the Alpha JVM. The default JVM is the "fast" one which is known to have some problems with native code (ie. the code that access the file system to find jars and other useful things). So by setting MAVEN_OPTS to "-Xmx256mb -classic", I can force the JVM into classic mode which appears to run. Erik Husby wrote: I've installed Maven-1.0-RC1 on my Windows XP system and my Alpha using Compaq Tru64 UNIX V5.1B (Rev. 2650); Using a shared drive, if I build the project on the Windows XP system, it works fine. But if I build, using the same set of files on the Unix box, Maven fails to load the JUnitTask as shown below. --- Unix Maven 107 11:41am [EMAIL PROTECTED] ~/workarea/SquidBuild/sequence/common > maven test:test __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT java:prepare-filesystem: java:compile: [echo] Compiling to /home/radon00/mhusby/workarea/SquidBuild/sequence/common/target/classes BUILD FAILED File.. file:/home/radon00/mhusby/.maven/plugins/maven-test-plugin-1.4/ Element... taskdef Line.. 89 Column 9 taskdef class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask cannot be found Total time: 12 seconds Finished at: Thu Jan 08 11:41:49 EST 2004 7.487u 5.990s 0:14.39 93.6%0+581k 10+30io 0pf+0w 108 11:41am [EMAIL PROTECTED] ~/workarea/SquidBuild/sequence/common > --- Windows XP Maven F:\workarea\SquidBuild\sequence\common>maven test __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT Attempting to download maven-SNAPSHOT.jar. Overriding previous definition of reference to clover.classpath java:prepare-filesystem: java:compile: [echo] Compiling to F:\workarea\SquidBuild\sequence\common/target/classes java:jar-resources: test:prepare-filesystem: test:test-resources: test:compile: test:test: [junit] Running edu.mit.wi.genome.common.dba.AllTests [junit] Tests run: 29, Failures: 0, Errors: 1, Time elapsed: 3.225 sec Its like Maven can't find its jar files. I've verified that $MAVEN_HOME/lib contains the same set of jar files on both systems. Any suggestions on things to look at would be really appreciated. -- Erik Husby Team Lead for Software Quality Automation Genome Center at MIT Rm. 2192 320 Charles St Cambridge, MA 02141-2023 mobile: 781.354.6669 office: 617.258.9227 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Child project using parent sources
Couldn't you just change the child's to point to the
parent?
${basedir}/../src/java
-Original Message-
From: Eric Giguere [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 2:58 PM
To: Maven Users List
Subject: Child project using parent sources
Hi all
Is there a property somewhere in the projet that can be set to tell a
sub project to use the parents directories? I'm trying to build multiple
jars using multiple maven projects but each uses its own sources and
targets. The class files are in the parent's target.
thx for any advice
Eric.
-
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]
Child project using parent sources
Hi all Is there a property somewhere in the projet that can be set to tell a sub project to use the parents directories? I'm trying to build multiple jars using multiple maven projects but each uses its own sources and targets. The class files are in the parent's target. thx for any advice Eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
Same error message. Tried using a bunch of different plugin contexts (test, java, idea)...
do you "import" the test context by declaring the 'test' namespace ?
this works for me :
m.t.d =
${pom.getPluginContext('maven-test-plugin').getVariable('maven.test.dest')}
-- gd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: single artifact mantra and ejb projects
I would be very interested to hear other peoples opinion on this as well. I'm currently working on 4 separate EJB projects and have gone through this same situation. I have heard talk on the mailing list about adding support for an artifact type "ejb-client.jar", but I don't remember who was looking into that. I've used the multiproject setup you've listed above, and with a little hack on the xdoclet plugin, got it up and running without any major problems. I would really like to flesh out some kind of "maven methodology" on this subject as I know it is a big area of question. I might put some time into putting something on the wiki regarding this. Ryan -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 7:25 AM To: Maven Users List Subject: single artifact mantra and ejb projects I have a question about the mantra that a single project should produce a single artifact. I can buy into that in every case I have run across or have thought about, except for projects involving ejb creation. Typically an ejb project will produce both an ejb-jar file as well as a client-jar file. But wouldn't that be two artifacts? I have read a lot of external docs on setting up j2ee projects using maven, most of which suggest a multi project layout. I can totally justify that for say a j2ee project producing an ear made up of sub ejb-jars and wars. But in the case of a stand-alone ejb-jar producing project or an ejb-jar producing subproject of an ear project it seems like overkill to define a subproject for the ejb-jar generation and the client-jar generation, especially when both are ultimately logically tied to the attainment of an ejb goal. Could someone help me out in my understanding here? Thanks, Steve - 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 jelly tag and build.properties properties
I've had various problems when the variable has a . or - in it. I use a
workaround like this:
Usage: maven -Dbuild.number=x releaseNotes
If I put , it doesn't work. This is a
different code example then yours, but you can apply the idea.
-jake
On Wednesday 14 January 2004 03:25 pm, Ebersole, Steven wrote:
> Same error message. Tried using a bunch of different plugin contexts
> (test, java, idea)...
>
>
> -Original Message-
> From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 14, 2004 1:43 PM
> To: Maven Users List
> Subject: Re: maven jelly tag and build.properties properties
>
> Ebersole, Steven wrote:
> >How is it possible to reference a property defined in one of the maven
> > properties files (specifically the ~/build.properties) in one of the
> > maven jelly tags? The tag I am trying to use is
> > . What I have tried so far is:
> >
> >1) > path="${maven.test.dest}" separator="/" /> 2) > var="testDest" basedir="${basedir}"
> > path="${context.getVariable('maven.test.dest')}" separator="/" />
>
> what if you try
> path='${pom.getPluginContext("maven-test-plugin").getVariable("maven.test.d
>est")}' ?
>
> -- gd
>
>
> -
> 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]
RE: maven jelly tag and build.properties properties
Same error message. Tried using a bunch of different plugin contexts (test, java,
idea)...
-Original Message-
From: Gilles Dodinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 14, 2004 1:43 PM
To: Maven Users List
Subject: Re: maven jelly tag and build.properties properties
Ebersole, Steven wrote:
>How is it possible to reference a property defined in one of the maven properties
>files (specifically the ~/build.properties) in one of the maven jelly tags? The tag
>I am trying to use is . What I have tried so far is:
>
>1) path="${maven.test.dest}" separator="/" />
>2) path="${context.getVariable('maven.test.dest')}" separator="/" />
>
>
what if you try
path='${pom.getPluginContext("maven-test-plugin").getVariable("maven.test.dest")}'
?
-- gd
-
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 jelly tag and build.properties properties
Ebersole, Steven wrote:
How is it possible to reference a property defined in one of the maven properties files (specifically the ~/build.properties) in one of the maven jelly tags? The tag I am trying to use is . What I have tried so far is:
1)
2)
what if you try
path='${pom.getPluginContext("maven-test-plugin").getVariable("maven.test.dest")}'
?
-- gd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and EJB Testing
> -Original Message- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Rob Moore > Sent: 14 January 2004 16:53 > To: [EMAIL PROTECTED] > Subject: Re: Maven and EJB Testing > > Vincent Massol wrote: > > > >>-Original Message- > >>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Rob Moore > >>Sent: 13 January 2004 08:19 > >>To: [EMAIL PROTECTED] > >>Subject: Re: Maven and EJB Testing > >> > >>I noticed you made a lot of changes in December to assist with testing > >>EJBs. Any chance you might provide the updated plug-in jar on the > > > > site? > > > > Will do today. > > Thanks, Vincent. I'm looking forward to trying out the changes. So where > should I look for it? Hehe... I'm a bit late :-) I had to fix a nasty bug before publishing the result. I think I have found the reason for it. I'm fixing it as we speak. Should be ready tonight or tomorrow. Thanks -Vincent > > Rob > > > - > 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: Style of generated site
Jörg Schaible wrote:
Yeah, but wait ... how does xdoc know anything about a css file in a xdoc/style directory (still searching for some docs ...)? Looking into my project, xdoc generates three css files out of nowhere (maven-base, maven-theme, print ... OK, I know they're coming from the plugin's resources). But what I have to do, that a xdoc/style/my.css for my project is working? Is it just locating a file there or must it have the name of onw of the files above? What are the used ids from xdoc that I can assign an own style ... ?
Jorg,
there is three css used (site.jsl), if im not wrong :
o maven-base.css (always)
o theme - property maven.xdoc.theme.url, defaults to
${relativePath}/style/maven-theme.css
o ${maven.docs.src}/style/project.css
-- gd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Multiproject usage
Hello, I am quite somewhat curious to understand how multiproject really works. I have following project layout with more projects to come: + - base + - root + - project a + - xdocs + - project b + - xdocs root/project.xml contains the common definitions and the root/project.properties includes any /project.xml and excludes root/project.xml. Base does currently not contain any file. Now it seems it does not matter it I call "maven multiproject:site" from root or base. The site is generated for project a in both cases, but only in /target/docs. I do not have a multiproject subdirectory in base as I would assume reading the description to the aggregateDir attribute. Is it because I do not have a root/xdocs yet? Looking at the documented attributes I would assume, that the aggregation mode is defualt and would generate the overview html docs by default ... ?!? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven jelly tag and build.properties properties
How is it possible to reference a property defined in one of the maven properties files (specifically the ~/build.properties) in one of the maven jelly tags? The tag I am trying to use is . What I have tried so far is: 1) 2) Plus some other off the wall stuff. But I could not get anything I tried to work. I keep getting " You must define an attribute called 'path' for this tag" error message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Style of generated site
Rafal Krzewski wrote on Wednesday, January 14, 2004 3:04 PM: > Jörg Schaible wrote: > >> with the current version of 1.0-rc2 (from CVS) and all plugins built >> fom CVS, I had to notice that the style of new generated sites differ >> a lot. I had previsouly used properties mensioned in the >> xdoc-plugin-docs to adjust colors to our companies' CI, but they are >> not respected with the new style anymore. How can I return to the >> previous style? And where can I create such a complete new style on >> my own? > > Create xdocs/style/project.css and work from here. It's much > more powerful and flexible than the eariler peorperties approach. Yeah, but wait ... how does xdoc know anything about a css file in a xdoc/style directory (still searching for some docs ...)? Looking into my project, xdoc generates three css files out of nowhere (maven-base, maven-theme, print ... OK, I know they're coming from the plugin's resources). But what I have to do, that a xdoc/style/my.css for my project is working? Is it just locating a file there or must it have the name of onw of the files above? What are the used ids from xdoc that I can assign an own style ... ? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and EJB Testing
Vincent Massol wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Rob Moore Sent: 13 January 2004 08:19 To: [EMAIL PROTECTED] Subject: Re: Maven and EJB Testing I noticed you made a lot of changes in December to assist with testing EJBs. Any chance you might provide the updated plug-in jar on the site? Will do today. Thanks, Vincent. I'm looking forward to trying out the changes. So where should I look for it? Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Junit report failure
my junit tests always fail with the following exception. In searching, I
have found several proect pages on the net with the same error "" in the "Success Rate" column at teh top of
the junit-report.html page
There is a test to be run.
Thanks in advance,
Cary
==
test:test:
[junitreport] [DEBUG] fileset: Setup scanner in dir
/home/cacc/workspace/COM/enterprise/target/test-reports with patternSet{
includes: [TEST-*.xml] exclud
es: [] }
java.lang.NumberFormatException: NaN
at
java.lang.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1171)
at java.lang.Double.valueOf(Double.java:163)
at
org.apache.maven.util.DVSLFormatter.formatNumber(DVSLFormatter.java:113)
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invok
e(UberspectImpl.java:304)
at
org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:56)
at
org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:106)
at
org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:88)
at
org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:123)
at
org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExpress
ion.java:115)
at
org.apache.commons.jelly.expression.jexl.JexlExpressionFactory$ExpressionSup
portLocal.evaluate(JexlExpressionFactory.java:168)
at
org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(Expres
sionSupport.java:106)
at
org.apache.commons.jelly.expression.ExpressionSupport.evaluateAsString(Expre
ssionSupport.java:91)
at
org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java:112
)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:111)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:318)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:111)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:318)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
[snip]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
html on generated site
Hello, I've notice that sometimes, the HTML produced by maven site:generate cut words in 2 parts. For example, I wrote in the xdocs dir : The objectives of this project is to automatised the documentation of a projet. and I see in the HTML page : The objectives of this proj ect is to automatised the (...) Note the line break in the middle of "project". However I'haven't be able to determine precise circumstances when this arrives. On the same idea, why the HTML code generated is not properly indented ? Where can I fix this ? Have you some idea ? Carl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javadoc plugin
Yeah, same thing happened to me. I modified the javadoc's plugin.jelly to get it
working. Here's the diff:
93,94c93
< packagenames="${pom.package}"
< sourcepath="${pom.build.sourceDirectory}"
---
> packagenames="${pom.package}.*"
109a108,124
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
and then in your project.xml file, put a line like:
java.util,java.lang,javax.xml.parsers
I'm using JDK 1.3.1 and Maven 1.0-rc1
-jake
On Wednesday 14 January 2004 07:25 am, Ebersole, Steven wrote:
> whenever I run the maven javadoc plugin, it does not generate any package
> information (package-list is blank and package-summary is missing). Any
> ideas what I am missing?
>
> -
> 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: Style of generated site
Jörg Schaible wrote: > with the current version of 1.0-rc2 (from CVS) and all plugins built > fom CVS, I had to notice that the style of new generated sites differ > a lot. I had previsouly used properties mensioned in the > xdoc-plugin-docs to adjust colors to our companies' CI, but they are > not respected with the new style anymore. How can I return to the > previous style? And where can I create such a complete new style on > my own? Create xdocs/style/project.css and work from here. It's much more powerful and flexible than the eariler peorperties approach. R. Create xdocs/style/project.css and work from here. It's much more powerful and flexible than the eariler peorperties approach. R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Style of generated site
Hello, with the current version of 1.0-rc2 (from CVS) and all plugins built fom CVS, I had to notice that the style of new generated sites differ a lot. I had previsouly used properties mensioned in the xdoc-plugin-docs to adjust colors to our companies' CI, but they are not respected with the new style anymore. How can I return to the previous style? And where can I create such a complete new style on my own? Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: aspectj plugin
Hi Vincent, > > I cannot imagine that this is so hard to solve as a jar is nothing > > different > > (only that is zipped and containg some meta-inforamation). Should I > ask > > them > > or could you do? > > I'll let you do it... ;-) *lol* Okay. I'll try to contact the aspectj team and inform you about it. Bye Toby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple remote repository + proxy settings
> -Original Message- > From: Eric Giguere [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 13, 2004 9:34 PM > To: Maven User List > Subject: Multiple remote repository + proxy settings > > > Hi all > A quick one. We're behind a firewall and use a proxy server > to go on the Net. > And we have a "remote" repository for jars that is on our > internal network. > > Lets say I want to still use the one at ibiblio.org as a > fallback repository. > I know how to configure multiple remote repositories but, is > it possible to > specify proxy settings for lets say only the second remote > repository in the > list? I ask because if I set proxy settings, I can access the default > repository, but not our local one. If I don't set proxy > properties, then its > the fallback (ibiblio.org) that becomes innaccessible because > of our proxy > server. > > Is there a work around? > The simplest way of doing this is to use file:// protocol for accessing your intranet repository Just map a network drive to you repository and you are done. You can even map a network drive to FTP/HTTP/WebDav repository and have a support for all those protocols which are currently unsupported by Maven (haven't tested such things but normally it should work) but are supported by your operating system. You must be just careful with SNAPSHOT artifact and see exactly what will happen and how they will be resolved. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
single artifact mantra and ejb projects
I have a question about the mantra that a single project should produce a single artifact. I can buy into that in every case I have run across or have thought about, except for projects involving ejb creation. Typically an ejb project will produce both an ejb-jar file as well as a client-jar file. But wouldn't that be two artifacts? I have read a lot of external docs on setting up j2ee projects using maven, most of which suggest a multi project layout. I can totally justify that for say a j2ee project producing an ear made up of sub ejb-jars and wars. But in the case of a stand-alone ejb-jar producing project or an ejb-jar producing subproject of an ear project it seems like overkill to define a subproject for the ejb-jar generation and the client-jar generation, especially when both are ultimately logically tied to the attainment of an ejb goal. Could someone help me out in my understanding here? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven.username question
I think you can define in a preGoal of site:deploy the maven.username redefinition. And in a postGoal redefine the properties to the old one. This could be a way to change this property only for one goal. Nicolas "Ebersole, Steven" <[EMAIL PROTECTED]> 14/01/2004 13:53 Veuillez répondre à "Maven Users List" Pour : "Maven Users List" <[EMAIL PROTECTED]> cc : Objet : maven.username question What is the explicit purpose of the maven.username property? Initially I had setup such that maven.username was a generic user for our development team on the machine serving as our internal remote repository and project web server. So that worked fine for all the deploy goals pushing out to that server. Then I started to think that it would be better to set up maven.username to be the developer's specific username (which is there NT userid, cvs username, unix account name, etc...). The problem I ran into with this, however, was on attempting to deploy the project website using site:deploy. The issue had to do with the fact that different users were now owners (it was actually the chmod command which failed). How does everyone usually handle this? - 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]
maven.username question
What is the explicit purpose of the maven.username property? Initially I had setup such that maven.username was a generic user for our development team on the machine serving as our internal remote repository and project web server. So that worked fine for all the deploy goals pushing out to that server. Then I started to think that it would be better to set up maven.username to be the developer's specific username (which is there NT userid, cvs username, unix account name, etc...). The problem I ran into with this, however, was on attempting to deploy the project website using site:deploy. The issue had to do with the fact that different users were now owners (it was actually the chmod command which failed). How does everyone usually handle this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
javadoc plugin
whenever I run the maven javadoc plugin, it does not generate any package information (package-list is blank and package-summary is missing). Any ideas what I am missing? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: aspectj plugin
> -Original Message- > From: Rademacher Tobias [mailto:[EMAIL PROTECTED] > Sent: 14 January 2004 08:26 > To: 'Maven Users List' > Subject: RE: aspectj plugin > > Dear Vincent, > > thx for your quick reply. > > > > > You're right. This is a current limitation of the iajc task > > (it can only > > weave jars). > > Okay. Then I'll go with the old version (1.1) as Unit Testing is essential > for me. > I hope this is okay for you ;-). Of course it is! > > > It seems this is something that the aspectj team also wanted to add > > (weaving directories in addition to jars). I don't know what > > the status > > is. > > I cannot imagine that this is so hard to solve as a jar is nothing > different > (only that is zipped and containg some meta-inforamation). Should I ask > them > or could you do? I'll let you do it... ;-) I'd be happy to know the outcome though. Thanks -Vincent > > Bye > Toby > > - > 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: aspectj plugin
Dear Vincent, thx for your quick reply. > > You're right. This is a current limitation of the iajc task > (it can only > weave jars). Okay. Then I'll go with the old version (1.1) as Unit Testing is essential for me. I hope this is okay for you ;-). > It seems this is something that the aspectj team also wanted to add > (weaving directories in addition to jars). I don't know what > the status > is. I cannot imagine that this is so hard to solve as a jar is nothing different (only that is zipped and containg some meta-inforamation). Should I ask them or could you do? Bye Toby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: aspectj plugin
> -Original Message- > From: Rademacher Tobias [mailto:[EMAIL PROTECTED] > Sent: 14 January 2004 07:36 > To: 'Maven Users List' > Subject: RE: aspectj plugin > > Dear Vincent, > > thank you for your informations. I'll definitivly give it a try. > > The only bear in mind I have is unit testing. As far as I understand the > current plugin weaves > in the aspects into the generated assembly. Who can I test this as > test:test > is called before the assembly has been build? > Or do you weave-in aspects into the class files in target\classes > directory, > so that unit testing works fine? You're right. This is a current limitation of the iajc task (it can only weave jars). Here's what I wrote in the plugin.jelly file (in the header): TODO: - Need to add back the ajdoc goal - Try to find a solution to weave at the class level instead of at the jar level as some other plugins (like the war one) do not go through the jar:jar goal (they stop at the java:compile step). - Add goals/properties xdoc documentation - Add other iajc attributes as plugin properties - Add a aspectj:jar-deploy goal See item 2. It seems this is something that the aspectj team also wanted to add (weaving directories in addition to jars). I don't know what the status is. Thanks -Vincent > > Thx again for your nice help. > > Bye > Toby > > > -Original Message- > > From: Vincent Massol [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 13, 2004 5:32 PM > > To: 'Maven Users List' > > Subject: RE: aspectj plugin > > > > > > Hi Tobias, > > > > I'm probably the last one to have modified the aspectj plugin... :-) I > > can't remember exactly what I did (it was a long way back). The only > > thing I remember is that I have completely rewritten it. I had to do > > that because I moved from the old AspectJ version to the new > > one (using > > the new iajc Ant task). This required a major overhaul. > > > > In the process, I may have dropped compilation support as it is no > > longer required: the weaving is done on bytecode and not on sources. > > > > I wanted to add improvements (they're listed in the plugin.jelly file) > > but unfortunately I have not had the time for them since then. > > > > I don't remember how far I went with the rewrite and I don't > > know if it > > is fully functional (I usually always leave stuff in full functional > > state - even though it might not be complete - but in that > > case, I don't > > remember). Maybe you could try it? If it's too broken, we can always > > revert to a previous version. > > > > Thanks > > -Vincent > > > > > -Original Message- > > > From: Rademacher Tobias [mailto:[EMAIL PROTECTED] > > > Sent: 13 January 2004 12:04 > > > To: '[EMAIL PROTECTED]' > > > Subject: aspectj plugin > > > > > > Hi Folks, > > > > > > I'm a bit confused right now about the cvs version and the release > > version > > > of the plugin. The cvs version don't longer have a aspectj:compile > > only a > > > aspectj:weave. Can you please clarify why compile goal has been > > dropped? > > > > > > Thx > > > Toby > > > > > > > > - > > > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
