Re: velocity-1.4-dev.jar gone from Ibibli, what to do?
Hi Jason, Unsure where to file the issue exactly I filed it here: http://jira.codehaus.org/browse/MAVEN-1719 Dennis On 10/26/05, Carlos Sanchez [EMAIL PROTECTED] wrote: We¡re working on this and it'll be fixed in the next hours. On 10/26/05, Jason van Zyl [EMAIL PROTECTED] wrote: On Wed, 2005-10-26 at 14:09 +, Ruud Wijnands wrote: Is it possible that it has something to do with load balancing of servers? The problem got 'solved' about half an hour after I posted my mail. Via the webserver the file still were not there. I thing this is something that can go wrong when load balancing is applied, but the servers are not in sync. No, this is a problem on our end. With our sync'ing process and with some code in m2. We're looking into it. On 10/25/05, Ruud Wijnands [EMAIL PROTECTED] wrote: I just removed my complete maven 1.0.2 repository to perform a full clean build and download everything fresh. I ran into the problem that now velocity-1.4-dev.jar cannot be downloaded. When I look at the ibiblio site this seems correct. Has this been removed by mistake? How can I fix this? I don't have a local copy. Regards, Ruud Wijnands -- jvz. Jason van Zyl jason at maven.org http://maven.org http://maven.apache.org Simplex sigillum veri. (Simplicity is the seal of truth.) - 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: velocity-1.4-dev.jar gone from Ibibli, what to do?
Funny, I just noticed the same !!! If you can find it at http://www.ibiblio.org/maven2/velocity/velocity/1.4-dev/ I agree it's of course much nicer to be able to automatically download it after a repo clean... as a side note: It also seems that commons-logging-1.1-dev.jar is also missing... (also available at maven2 repo) http://www.ibiblio.org/maven2/commons-logging/commons-logging/1.1-dev/ both jars are dependencies for various 'important' plugins (e.g. xdoclet plugin) Should I post a JIRA issue to request for an update of these plugins to depend on jars that are NOT development versions ?? Dennis On 10/25/05, Ruud Wijnands [EMAIL PROTECTED] wrote: I just removed my complete maven 1.0.2 repository to perform a full clean build and download everything fresh. I ran into the problem that now velocity-1.4-dev.jar cannot be downloaded. When I look at the ibiblio site this seems correct. Has this been removed by mistake? How can I fix this? I don't have a local copy. Regards, Ruud Wijnands
Re: gRE: M2 and annotations
It's probably the best to look at Sun's documentation
APT (Annotation Processing Tool):
http://java.sun.com/j2se/1.5.0/docs/guide/apt/index.html
Annotations in general:
http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html
Dennis
p.s. I'm also not experienced myself with annotations to be giving others
any well-funded advice
but there's something called retention policy i.e. you can supply to the
compiler/ VM whether
it should expose the annotation metadata during runtime or not.
Seems odd though that one VM (eclipse) does seem to expose it and another
(maven w/ JUnit) does not.
Could it be that the 'tools.jar' is needed ?? (the APT api can be found in
com.sun.mirror.* )
On 9/11/05, Kaare Nilsen [EMAIL PROTECTED] wrote:
Hi.
I am compiling with source level of 1.5 by doing this :
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
But I do not know how to run annotation processor. (I am not that
experienced with annotations myself, so I did not even know there was
one),
so if anyone know how I do this I would be glad for any tips.
Best regards
Kaare Nilseb
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: 11. september 2005 04:57
To: Maven Users List
Subject: Re: M2 and annotations
I'm not familiar with using Java5 annotations at this point, but I think
you
need to run the annotation processor first, or at least compile with
source
level of 1.5. Have these been done?
- Brett
On 9/11/05, Kaare Nilsen [EMAIL PROTECTED] wrote:
Hi I have a little problem.
I am trying to make a testng plugin for maven2, but I have reached a
point
where I really don't know what to do.
Here is the case:
TestNG uses annotations and have an annotation called Test with fully
qualified name : org.testng.annotations.Test
So..
Then I have a testclass looking like this .
package org.codehaus.mojo.testng;
import org.testng.annotations.Test;
public class ATest {
@Test
public void test(){
System.out.println(A test is run);
}
And. Then I do like this:
public void execute()
throws MojoExecutionException
{
Object o = loader.loadClass(org.codehaus.mojo.testng.ATest
).newInstance();
Method[] met = o.getClass().getMethods();
Class annotation = Class.forName(org.testng.annotations.Test);
Object thisAnnotation = met[0].getAnnotation((ClassAnnotation)
annotation);
}
So far so good.. But this is what happens.
When I run this plugin in eclipse with a junit test. thisAnnotation !=
null
But when I run this plugin as a part of a maven build thisAnnotation ==
null
Anyone have a clue of why this happens ?
Best regards
Kaare Nilsen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[6]: xdoclet dependency
Hi Dmitry, only for the xjavadoc jar, you should use a groupId of xjavadoc and version 1.1 for the xdoclet jars groupId=xdoclet and version=1.2 so: dependency groupIdxjavadoc/groupId artifactIdxjavadoc/artifactId version1.1/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet/artifactId version1.2/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet-web-module/artifactId version1.2/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet-ejb-module/artifactId version1.2/version /dependency etcetera... Dennis On 8/22/05, Dmitry Ochnev [EMAIL PROTECTED] wrote: Hello Jörg, Monday, August 22, 2005, 1:58:33 PM, you wrote: Attempting to download xjavadoc-1.2.jar. This does not exist. Latest release is 1.1. It does exist: http://www.ibiblio.org/maven/xdoclet/jars/ You should stay with the original version (or at least check, that your used version of XDoclet is compliant with the one of xjavadoc). What do you mean the original version? -- Best regards, Dmitry mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re[8]: xdoclet dependency
Dmitry, maven-xdoclet-plugin depends on xjavadoc-1.0.2 this file seems to have disappeared from ibiblio.org/mavenhttp://ibiblio.org/maven! i do not know how to get it back there... Dennis On 8/22/05, Dmitry Ochnev [EMAIL PROTECTED] wrote: Hello Dennis, Monday, August 22, 2005, 3:01:35 PM, you wrote: only for the xjavadoc jar, you should use a groupId of xjavadoc and version 1.1 for the xdoclet jars groupId=xdoclet and version=1.2 so: dependency groupIdxjavadoc/groupId artifactIdxjavadoc/artifactId version1.1/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet/artifactId version1.2/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet-web-module/artifactId version1.2/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet-ejb-module/artifactId version1.2/version /dependency etcetera... Dennis It became better but it is still not working. Here is the part of the project.xml: ---begin--- !-- XDoclet dependencies -- dependency idxdoclet/id version1.2/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet-web-module/artifactId version1.2/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet-ejb-module/artifactId version1.2/version /dependency dependency groupIdxjavadoc/groupId artifactIdxjavadoc/artifactId version1.1/version /dependency dependency groupIdxdoclet/groupId artifactIdmaven-xdoclet-plugin/artifactId version1.2/version typeplugin/type /dependency ---end--- And here is the output: ---begin--- Tag library requested that is not present: 'maven' in plugin: ' maven-xdoclet-plugin-1.2' Attempting to download xjavadoc-1.0.2.jar. Response content length is not known Response content length is not known Response content length is not known WARNING: Failed to download xjavadoc-1.0.2.jar. BUILD FAILED File.. D:\apptest2\maven.xml Element... attainGoal Line.. 23 Column 43 The build cannot continue because of the following unsatisfied dependency: xjavadoc-1.0.2.jar ---end--- Where is the error? -- Best regards, Dmitry mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xdoclet dependency
ok nicolas, thanks for the info (is must have copied it 'eons' ago and forgot about it afterwards), seems that some alteration is in order; either move/ copy the xjavadoc-1.0.* to xjavadoc or the maven-xdoclet-plugin (version 1.2) should incorporate a correct dependency. I do not think it is a good programming practice to define an invalid dependency and subsequently requiring from the developer that it should copy the dependency from its (apparently) default location to some other undocumented location. any comments ?? dennis On 8/22/05, Nicolas De Loof [EMAIL PROTECTED] wrote: xjavadoc-1.0.* exists on ibiblio with groupId 'xdoclet' latter versions (1.1) are registered under groupId xjavadoc. Dennis Geurts a écrit : Dmitry, maven-xdoclet-plugin depends on xjavadoc-1.0.2 this file seems to have disappeared from ibiblio.org/maven http://ibiblio.org/mavenhttp://ibiblio.org/maven! i do not know how to get it back there... Dennis On 8/22/05, Dmitry Ochnev [EMAIL PROTECTED] wrote: Hello Dennis, Monday, August 22, 2005, 3:01:35 PM, you wrote: only for the xjavadoc jar, you should use a groupId of xjavadoc and version 1.1 for the xdoclet jars groupId=xdoclet and version=1.2 so: dependency groupIdxjavadoc/groupId artifactIdxjavadoc/artifactId version1.1/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet/artifactId version1.2/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet-web-module/artifactId version1.2/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet-ejb-module/artifactId version1.2/version /dependency etcetera... Dennis It became better but it is still not working. Here is the part of the project.xml: ---begin--- !-- XDoclet dependencies -- dependency idxdoclet/id version1.2/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet-web-module/artifactId version1.2/version /dependency dependency groupIdxdoclet/groupId artifactIdxdoclet-ejb-module/artifactId version1.2/version /dependency dependency groupIdxjavadoc/groupId artifactIdxjavadoc/artifactId version1.1/version /dependency dependency groupIdxdoclet/groupId artifactIdmaven-xdoclet-plugin/artifactId version1.2/version typeplugin/type /dependency ---end--- And here is the output: ---begin--- Tag library requested that is not present: 'maven' in plugin: ' maven-xdoclet-plugin-1.2' Attempting to download xjavadoc-1.0.2.jar. Response content length is not known Response content length is not known Response content length is not known WARNING: Failed to download xjavadoc-1.0.2.jar. BUILD FAILED File.. D:\apptest2\maven.xml Element... attainGoal Line.. 23 Column 43 The build cannot continue because of the following unsatisfied dependency: xjavadoc-1.0.2.jar ---end--- Where is the error? -- Best regards, Dmitry mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: Multiproject resources problem
Michael,
you specify:
directory${basedir}/build/testclasses/directory
shouldn't that be:
directory${basedir}/target/test-classes/directory
??
Dennis
On 7/27/05, Michael Owen [EMAIL PROTECTED] wrote:
Hi,
I have a problem when doing jar:install in a multiproject scenerio. In my
individual project I have:
resources
resource
directory${basedir}/build/testclasses/directory
includes
include**/*/include
/includes
/resource
/resources
to include the testclasses into the produced jar when I do jar:install.
This
happens when doing it for the individual project, but when done as a goal
for a multiproject goal ie:
goal name=multi:build
j:set var=goal value=jar:install/
attainGoal name=multiproject:goal/
/goal
The testclasses don't get put into the jar. Any help? Looked on the
multiproject plugin documentation page and it says to use ${basedir} to
solve the problem, but I've done that.
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiproject resources problem
ok, reasonable, just checking...
the 'java:jar-resources' goal that should copy your test-classes comes
before the 'test:compile' goal
could it be that you start with a clean (multi)project ?? the
'build/testclasses' dir will still be empty,
and you'll copying all the files that are there (that is to say: none at
all) ;-)
Dennis
On 7/27/05, Michael Owen [EMAIL PROTECTED] wrote:
No. I've changed it to put the test classes into that directory.
Mike
brbrbrFrom: Dennis Geurts
[EMAIL PROTECTED]brReply-To: Dennis Geurts
[EMAIL PROTECTED]brTo: Maven Users List
users@maven.apache.orgbrSubject: Re: Multiproject resources
problembrDate: Wed, 27 Jul 2005 13:16:56
+0200brbrMichael,br you specify:br
directory${basedir}/build/testclasses/directorybr
shouldn't that
be:brdirectory${basedir}/target/test-classes/directorybr
??br Dennisbrbr On 7/27/05, Michael Owen
[EMAIL PROTECTED] wrote:br br br
Hi,br br I have a problem when doing jar:install
in a multiproject scenerio. In mybr individual project I
have:br br resourcesbr
resourcebr
directory${basedir}/build/testclasses/directorybr
includesbr include**/*/includebr
/includesbr /resourcebr
/resourcesbr br to include the testclasses into
the produced jar when I do jar:install.br Thisbr
happens when doing it for the individual project, but when done as a
goalbr for a multiproject goal ie:br br
goal name=multi:buildbr j:set
var=goal value=jar:install/br
attainGoal name=multiproject:goal/br
/goalbr br The testclasses don't get put into
the jar. Any help? Looked on thebr multiproject plugin
documentation page and it says to use ${basedir} tobr solve the
problem, but I've done that.br br Mikebr
br br br
-br
To unsubscribe, e-mail: [EMAIL PROTECTED]br
For additional commands, e-mail: [EMAIL PROTECTED]br
br br
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m102] Using multiproject with plugin projects ?
Haryon, I also came across this issue. my resolution was as follows: For all the projects, I specified the 'maven.multiproject.type' property to 'war', 'jar', 'ear', whatever; for the 'special' project I set the abovementioned property to 'mygoal' Furthermore, in the maven.xml (of this special project) I defined two new goals called 'mygoal:mygoal' and 'mygoal:install' In your case the goals would (could/ should) be: goal name=mygoal:mygoal attainGoal name=plugin:install/ /goal goal name=mygoal:install attainGoal name=plugin:repository-install/ /goal As such, the normal projects can be as simple as you want, and don't even need a maven.xml and both 'maven multiproject:artifact' and 'maven multiproject:install' do the things you want it to do... Hope this helps, Dennis On 7/22/05, Haryon [EMAIL PROTECTED] wrote: Hi, multiproject:install does TYPE:install on every subprojects, where TYPE is the project type (jar, war, etc. based on what we input in projects.properties). But when TYPE is 'plugin', it will do plugin:install. But if I'm not mistaken plugin:install doesn't put the plugin jar in the repository but instantiate and run the plugin on the current maven installation. I need to use plugin:repository-install. I could try a multiproject:goal -Dgoal=repository-install, but I have jar projects there too, that need jar:install not jar:repository-install. Help :) any advice on how you would proceed ? I would create a my-install goal on every project, on jars that would attainGoal install, and on plugins that would attain repository-install. But I find that very bad (needs edit maven.xml in every project I create in the multiproject tree). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternate build step
Reis, To get your colleagues 'hot' for maven (if that's what's going on), check out the maven-ant-plugin while you are fully mavenized, your colleagues can still use ant... http://maven.apache.org/reference/plugins/ant/ Dennis On 7/21/05, Reid Pinchback [EMAIL PROTECTED] wrote: Thanks to everybody. I now have Maven working exactly as I want it to. Not bad, 3 pieces of advice from one request, all of them useful in combination. :-) Final solution was: - specify the sourceDirectory - override the java:compile goal - specify checkstyle as (currently) the only report I want. JDepend was one of the default reports, and it definitely forced a compile to happen. Something I want to use eventually, but not the most immediate priority. I'll tackle more of the Ant-to-Maven conversion later so we can use other reports, but for now I'll just be happy if availability of the checkstyle reports curbs folks from littering code with bogus imports and introducing method names like setFOO_BAR and getFOO_BAR. --- David Jackman [EMAIL PROTECTED] wrote: Then what I would do is list those reports you care about in the reports section of the project.xml. Some of those reports may require that the code gets compiled first. If you can't do the compile with maven, then you won't be able to include those reports. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJBDoclet in Maven
) 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.tags.core.WhenTag.doTag(WhenTag.java:92) 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.tags.core.ChooseTag.doTag(ChooseTag.java:84) 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.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTa g.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.perfor mAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java: 671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:488) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Final Memory: 18M/32M Total time: 5 seconds Finished at: Mon Jul 18 16:29:23 EDT 2005 See anything? Thanks, Ken -Original Message- From: Dennis Geurts [mailto:[EMAIL PROTECTED] Sent: Monday, July 18, 2005 4:14 PM To: Maven Users List Subject: Re: EJBDoclet in Maven mmhh, let's not forget the j2ee interfaces... it is also recommended to let generated source files be created in the target directory instead of creating them alongside your own source files... Dennis On 7/18/05, Ballard, Ken [EMAIL PROTECTED] wrote: Thanks, but it still isn't working, although it builds successfully. Here's the output form running maven -X xdoclet:ejbdoclet: [DEBUG] Finding class xjavadoc.DefaultXTag [DEBUG] Class xjavadoc.DefaultXTag loaded from ant loader [DEBUG] Class java.lang.IllegalArgumentException loaded from parent loader [DEBUG] Finding class xjavadoc.XDoc [DEBUG] Finding class xjavadoc.event.XTagListener [DEBUG] Class java.util.EventListener loaded from parent loader [DEBUG] Class xjavadoc.event.XTagListener loaded from ant loader [DEBUG] Class xjavadoc.XDoc loaded from ant loader [DEBUG] Class java.util.Iterator loaded from parent loader [DEBUG] Class java.util.EventObject loaded from parent loader [DEBUG] Finding class xjavadoc.event.XTagEvent [DEBUG] Class xjavadoc.event.XTagEvent loaded from ant loader [DEBUG] Class java.lang.StringIndexOutOfBoundsException loaded from parent loade r [DEBUG] Class java.io.IOException loaded from parent loader [DEBUG] Class java.io.Reader loaded from parent loader [DEBUG] Class java.io.StringReader loaded from parent loader [DEBUG] Finding class xjavadoc.JavaDocReader [DEBUG] Class java.io.FilterReader loaded from parent loader [DEBUG] Class xjavadoc.JavaDocReader loaded from ant loader [DEBUG] Class java.lang.System loaded from parent loader [DEBUG] Class java.util.LinkedList loaded from parent loader [DEBUG] Finding class xjavadoc.XExecutableMember [DEBUG] Finding class xjavadoc.XMember [DEBUG] Class xjavadoc.XMember loaded from ant loader [DEBUG] Class xjavadoc.XExecutableMember loaded from ant loader [DEBUG] Class java.lang.UnsupportedOperationException loaded from parent loader [DEBUG] Finding class xjavadoc.Util [DEBUG] Class xjavadoc.Util loaded from ant loader [DEBUG] Class java.io.FileFilter loaded from parent loader [DEBUG] Finding class xjavadoc.Util$1 [DEBUG] Class xjavadoc.Util$1 loaded from ant loader [DEBUG] Finding class xjavadoc.Util$2 [DEBUG] Class xjavadoc.Util$2 loaded from ant loader [DEBUG] Finding class xdoclet.loader.ModuleFinder [DEBUG] Class xdoclet.loader.ModuleFinder loaded from ant loader [DEBUG] Class java.util.zip.ZipException loaded from parent loader [DEBUG] Class java.util.zip.ZipEntry loaded from parent loader [DEBUG] Class java.util.jar.JarEntry loaded from parent loader [DEBUG] Class java.io.FileInputStream loaded from parent loader [DEBUG] Class java.io.InputStream loaded from parent loader [DEBUG] Finding class xdoclet.loader.ModuleFinder$1 [DEBUG] Class xdoclet.loader.ModuleFinder$1 loaded from ant loader [DEBUG] Class org.apache.tools.ant.AntClassLoader loaded from parent loader [DEBUG] Finding class xdoclet.modules.ejb.EjbDocletTask$EjbSpecVersion [DEBUG] Class
Re: EJBDoclet in Maven
java.lang.SecurityException loaded from parent
loa
der
[ejbdoclet] [DEBUG] Class java.lang.reflect.InvocationTargetException
loaded
from parent loader
[ejbdoclet] [DEBUG] Class java.lang.NoSuchMethodException loaded from
parent
loader
[ejbdoclet] [DEBUG] Finding class
xdoclet.ConfigParamIntrospector$NullObject
[ejbdoclet] [DEBUG] Class xdoclet.ConfigParamIntrospector$NullObject
loaded
from ant loader
[ejbdoclet] [DEBUG] Class java.lang.reflect.Method loaded from parent
loader
[ejbdoclet] [DEBUG] Class java.lang.reflect.Modifier loaded from parent
load
er
[ejbdoclet] [DEBUG] Class java.lang.Void loaded from parent loader
[ejbdoclet] [DEBUG] Class java.beans.Introspector loaded from parent
loader
[ejbdoclet] [DEBUG] Class java.lang.Character loaded from parent loader
[ejbdoclet] [DEBUG] Finding class javax.ejb.EntityBean
[ejbdoclet] [DEBUG] Finding class javax.ejb.EnterpriseBean
[ejbdoclet] [DEBUG] Class javax.ejb.EnterpriseBean loaded from ant
loader
[ejbdoclet] [DEBUG] Class javax.ejb.EntityBean loaded from ant loader
[ejbdoclet] [DEBUG] Finding class xjavadoc.filesystem.FileSourceSet
[ejbdoclet] [DEBUG] Class xjavadoc.filesystem.FileSourceSet loaded from
ant
loader
[ejbdoclet] [DEBUG] fileset: Setup scanner in dir
C:\workspaces\dfs\poc-v001
8-middletier\dfs\ear\src\main\java with patternSet{ includes:
[**/*Bean.java] ex
cludes: [] }
[ejbdoclet] [DEBUG] Class org.apache.tools.ant.DirectoryScanner loaded
from
parent loader
[ejbdoclet] [DEBUG] Finding class xjavadoc.filesystem.AbstractFile
[ejbdoclet] [DEBUG] Class xjavadoc.filesystem.AbstractFile loaded from
ant l
oader
[ejbdoclet] [DEBUG] Finding class xdoclet.XDocletMain
[ejbdoclet] [DEBUG] Class xdoclet.XDocletMain loaded from ant loader
[DEBUG] Adding reference: ejbdoclet.java.compile.src.set -
attaining goal build:end
popping off [EMAIL PROTECTED] for
org.apache.maven
[EMAIL PROTECTED] in
maven-xdoclet-plugin:maven-xdoclet-plugin
popping off [EMAIL PROTECTED] for
org.apache.maven
[EMAIL PROTECTED] in dfs:dfs-ear
BUILD SUCCESSFUL
Final Memory: 17M/32M
Total time: 5 seconds
Finished at: Mon Jul 18 15:51:29 EDT 2005
Any ideas?
Thanks,
Ken
-Original Message-
From: Dennis Geurts [mailto:[EMAIL PROTECTED]
Sent: Monday, July 18, 2005 3:33 PM
To: Maven Users List
Subject: Re: EJBDoclet in Maven
Hi Ken,
I did a quick scan of your mail, and noticed the dependency to the
jmx-module isn't there...
I think this dependency is needed for ejbdoclet to work.
please try a 'maven -X' to see a more verbose output.
hope it helps, if you need more help, just ask.
Dennis
On 7/18/05, Ballard, Ken [EMAIL PROTECTED] wrote:
Anyone,
I can't get ejbdoclet to work in Maven. I think I've seen every post out
there and I still seem to be missing something. I have hibernatedoclet
working without any problems, but ejbdoclet doesn't generate anything.
It's
the same code that I was using ejbdoclet to generate classes and
descriptors
in ANT, so I'm confident that it works. I just think I have Maven
configured
incorrectly.
I'm using the following in the project.properties file:
maven.xdoclet.ejbdoclet.ejbspec=2.0
[EMAIL PROTECTED] at
${TODAY},@copyright
Affiliated Computer Services, [EMAIL PROTECTED] xxx
[EMAIL PROTECTED],@author
#maven.xdoclet.ejbdoclet.mergeDir=
maven.xdoclet.ejbdoclet.verbose=true
maven.xdoclet.ejbdoclet.destDir=${maven.src.dir}
maven.xdoclet.ejbdoclet.fileset.0=true
maven.xdoclet.ejbdoclet.fileset.0.includes=**/*.java
maven.xdoclet.ejbdoclet.deploymentdescriptor.0=false
maven.xdoclet.ejbdoclet.deploymentdescriptor.0.destDir=${maven.src.dir}/META
-INF
maven.xdoclet.ejbdoclet.entitybmp.0=false
maven.xdoclet.ejbdoclet.entitycmp.0=false
maven.xdoclet.ejbdoclet.entitypk.0=false
maven.xdoclet.ejbdoclet.homeinterface.0=true
maven.xdoclet.ejbdoclet.localhomeinterface.0=true
maven.xdoclet.ejbdoclet.localinterface.0=true
maven.xdoclet.ejbdoclet.remoteinterface.0=true
maven.xdoclet.ejbdoclet.remoteinterface.0.pattern={0}Remote
maven.xdoclet.ejbdoclet.session.0=false
maven.xdoclet.ejbdoclet.utilobject.0=false
maven.xdoclet.ejbdoclet.valueobject.0=false
maven.xdoclet.ejbdoclet.strutsform.0=false
I have these XDoclet dependencies in my project.xml:
dependency
groupIdxdoclet/groupId
artifactIdxdoclet/artifactId
version2.0/version
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxdoclet-ejb-module/artifactId
version1.2.3/version
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxdoclet-jboss-module/artifactId
version1.2/version
/dependency
And this is my maven.xml:
project
xmlns:j=jelly:core
xmlns:maven=jelly:maven
xmlns:ant=jelly:ant
preGoal name=java:compile
attainGoal name=xdoclet:ejbdoclet/
/preGoal
/project
Re: EJBDoclet in Maven
Hi Ken,
I did a quick scan of your mail, and noticed the dependency to the
jmx-module isn't there...
I think this dependency is needed for ejbdoclet to work.
please try a 'maven -X' to see a more verbose output.
hope it helps, if you need more help, just ask.
Dennis
On 7/18/05, Ballard, Ken [EMAIL PROTECTED] wrote:
Anyone,
I can't get ejbdoclet to work in Maven. I think I've seen every post out
there and I still seem to be missing something. I have hibernatedoclet
working without any problems, but ejbdoclet doesn't generate anything.
It's
the same code that I was using ejbdoclet to generate classes and
descriptors
in ANT, so I'm confident that it works. I just think I have Maven
configured
incorrectly.
I'm using the following in the project.properties file:
maven.xdoclet.ejbdoclet.ejbspec=2.0
[EMAIL PROTECTED] at
${TODAY},@copyright
Affiliated Computer Services, [EMAIL PROTECTED] xxx
[EMAIL PROTECTED],@author
#maven.xdoclet.ejbdoclet.mergeDir=
maven.xdoclet.ejbdoclet.verbose=true
maven.xdoclet.ejbdoclet.destDir=${maven.src.dir}
maven.xdoclet.ejbdoclet.fileset.0=true
maven.xdoclet.ejbdoclet.fileset.0.includes=**/*.java
maven.xdoclet.ejbdoclet.deploymentdescriptor.0=false
maven.xdoclet.ejbdoclet.deploymentdescriptor.0.destDir=${maven.src.dir}/META
-INF
maven.xdoclet.ejbdoclet.entitybmp.0=false
maven.xdoclet.ejbdoclet.entitycmp.0=false
maven.xdoclet.ejbdoclet.entitypk.0=false
maven.xdoclet.ejbdoclet.homeinterface.0=true
maven.xdoclet.ejbdoclet.localhomeinterface.0=true
maven.xdoclet.ejbdoclet.localinterface.0=true
maven.xdoclet.ejbdoclet.remoteinterface.0=true
maven.xdoclet.ejbdoclet.remoteinterface.0.pattern={0}Remote
maven.xdoclet.ejbdoclet.session.0=false
maven.xdoclet.ejbdoclet.utilobject.0=false
maven.xdoclet.ejbdoclet.valueobject.0=false
maven.xdoclet.ejbdoclet.strutsform.0=false
I have these XDoclet dependencies in my project.xml:
dependency
groupIdxdoclet/groupId
artifactIdxdoclet/artifactId
version2.0/version
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxdoclet-ejb-module/artifactId
version1.2.3/version
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxdoclet-jboss-module/artifactId
version1.2/version
/dependency
And this is my maven.xml:
project
xmlns:j=jelly:core
xmlns:maven=jelly:maven
xmlns:ant=jelly:ant
preGoal name=java:compile
attainGoal name=xdoclet:ejbdoclet/
/preGoal
/project
My dir structure is:
+- ear/
+- src/
| +- main/
| | +- application/
| | | +- META-INF/
| | +- ejb/
| | | +- META-INF/
| | +- java/
| | | +- com
| | | | +- ...
| | +- resources/
| +- test/
| +- java/
| +- com
| +- ...
+-target/
+- maven.xml
+- project.xml
+- project.properties
When I run maven -X xdoclet:ejbdoclet it says BUILD SUCCESSFUL, but
nothing is generated. Does anybody have any idea about what I'm doing
incorrectly?
Thanks,
Ken
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
Re: Local Repository Issue
Hi Dylan, Could you try and remove the jarj2ee-1.4.jar/jar part ?? the other tags should suffice ... btw, your command says 'maven -0 ...' I assume you want to run in offline mode. The -0 ( minus-zero ) should then be -o ( minus-ooh ) Dennis On 7/15/05, Dylan Stamat [EMAIL PROTECTED] wrote: I'm having problems getting Maven (1.0.2) to find .JAR files in my local repository. Basic problem, but I can't get it to work for the life of me. Here is my setup: My repository is in the default location (/.maven/repository/), and I added a path to a j2ee .JAR I placed in this directory... ie: /.maven/repository/j2ee/jars/j2ee-1.4.jar Here is my dependency entry in the project.xml. I even tried using the jar tag to explicitly name the file, with no luck: dependency groupIdj2ee/groupId artifactIdj2ee/artifactId version1.4/version typejar/type jarj2ee-1.4.jar/jar /dependency I'm running: maven -0 jar:jar, and I get the following error: The build cannot continue because of the following unsatisfied dependency: j2ee-1.4.jar Any help would be appreciated ! Thanks ! == Dylan
Re: [M2] Mix between Provided and Test Scopes
Hi David, I encountered the same problem a while ago. The following was suggested: 'The workaround is to split your war files and your sources. Put all your java sources in an other project and add them in the new jar dep of your war.' So, make a multi module project, one 'jar-project' containing all classes ( servletapi in compile scope ) and a 'war-project' that depends on the 'jar-project' ( runtime scope ) the tests are then run while installing the 'jar-project' and the war-project will automatically package the 'jar-project.jar' Dennis On 7/15/05, Kenney Westerhof [EMAIL PROTECTED] wrote: On Thu, 14 Jul 2005, David H. DeWolf wrote: What you could do is depend on a pom, scopetest/scope, that itself depends on the servlet api. -- Kenney I'm attempting to utilize the servlet api within some mock tests (in addition to needing it to compile my main source). I have attempted to mark the scope of the servlet api in the following manners: 1) Provided Scope 2) Test Scope 3) Two Separate Dependencies of Provided Scope AND Test Scope And none of these seem to work. When the scope is 'provided', the tests throw a class not found exception. When the scope is 'test' the main source fails to compile. When I attempt to use both, it appears as though the second dependency is ignored. Has anyone else encountered this and found a work around? Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unit testing verbosity
Hi Dan, After testing, did you have a look at the files in 'target\test-reports' ?? Dennis On 7/15/05, Dan Bradley [EMAIL PROTECTED] wrote: I'm new to Maven, but can't find an resolution to this problem: unit tests don't run with enough verbosity to be useful. When I run unit tests that fail, there is nothing reported other than that the tests failed. For example: [junit] Running com.foo.FooTest [junit] Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 1.875 sec [junit] [ERROR] TEST com.foo.FooTest FAILED If I want to see the reason the test failed I have to generate the site and then look at the HTML output, which takes a lot longer, but does provide the full reason for failure: Error creating bean with name 'com.foo.FooTest' defined in null: Unsatisfied dependency expressed through bean property 'fooManager': There are 2 beans of type [class com.foo.FooTest] for autowire by type. There should have been 1 to be able to autowire property 'productManager' of bean 'com.foo.FooTest'. Is there a way to get the failure reason on the command line? In a separate problem, when I run test:ui it appears to have a different classpath than when running test. Is there a way to make sure these are the same? When running the Swing test runner from Maven I get classpath-related errors in my unit tests that don't appear when I run the console tests. Thanks Dan Bradley [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add other repository [m2]
Wilfred, I must confess I never used the 'repo override' myself... ;-) people: correct me if I'm wrong !! I guess since you want to always override you best create a profile that always 'activates' e.g. profile idjdk-1.5/id activation jdk1.5/jdk /activation repositories repository idmy own repo/id nameMy own Repository/name urlhttp://localhost:8080/myownrepo/maven2/url layoutdefault/layout snapshotPolicyalways/snapshotPolicy /repository /repositories /profile Dennis On 7/14/05, Peter van de Hoef [EMAIL PROTECTED] wrote: If you specify a plugin repository in your POM, like: pluginRepositories pluginRepository idmy-plugins/id nameMy Plugin Repository/name urlhttp://repository.mycompany.org/url /pluginRepository /pluginRepositories then, this plugin repository is always consulted before the central maven plugin repository. At least, that is what I experience. I'm using the latest from SVN. Could this be different for alpha-3 or whatever version you are using? HTH, Peter Wilfred Springer wrote: I have seen this URL, thanks. In fact, I even tried a number of things to understand how it works, but I'm not sure if I'm required to add a mirror add a server add a profile with a repository What do you suggest? Thanks, Wilfred On Thu, 2005-07-14 at 16:34, Dennis Geurts wrote: try this URL: http://maven.apache.org/maven2/maven-settings/settings.html Dennis On 7/14/05, Wilfred Springer [EMAIL PROTECTED] wrote: All, I want my project to check for a maven plugin from my own repository, before trying the http://repo1.maven.org/maven2/plugins repository. Any clues? Thanks, Wilfred -- _ Wilfred Springer Phone : +31 (0)3 3451 5736 Software Architect Mobile : +31 (0)6 2295 7321 Client Solutions Fax : +31 (0)3 3451 5734 Enterprise Web Services Mail : [EMAIL PROTECTED] Sun Microsystems Netherlands AIM : wilfred springer http://blogs.sun.com/wilfred/ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - 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: [m2] i18n .properties files in war
Hi Adam, what's the command you supply ?? 'm2 war:war' or 'm2 package' (it should be the latter) this might be a stupid question, but is the ' ApplicationResources.properties' file located at the 'src/main/resources' location in yout project ? Dennis On 7/13/05, Adam Hardy [EMAIL PROTECTED] wrote: I have exhausted the mailing list archives and the documentation on the website and I cannot see why my .properties file is not being included in my war, since my pom.xml appears to be correct. The file is not copied into the target directory nor is it included in the war file. I see from the archives that other people appear to be managing this fine. Here is my pom.xml (shortened): ?xml version=1.0 encoding=UTF-8? 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 maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdcom.mystuff/groupId artifactIdmystuff-web/artifactId packagingwar/packaging version1.0-SNAPSHOT/version dependencies dependency /dependency /dependencies build finalNamemystuff-web/finalName resources resource directorysrc/main/resources/directory includes includeApplicationResources.properties/include /includes /resource /resources /build /project I tried it with a targetPath element too, but with no joy either. Thanks Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] i18n .properties files in war
maven 1.x maybe ?? I was fooled myself too when I started getting to know maven 2... Dennis On 7/13/05, Adam Hardy [EMAIL PROTECTED] wrote: I don't know where I picked up the instruction to run war:war. I see it's not on the list of common lifecycle phases on the website. Rather misleadingly (obviously in my case) the output from war:war contains this: [INFO] [war:war] [INFO] Copy webapp resources to /home/adam/java/projects/garg-web/target/garg-web Hence the reason I thought my pom was wrong, since it was carrying out the webapp resources copy operation. The 'resources' mentioned here then do not include *.properties files - I wish it had been clearer. It may save future maven users a bit of pain by changing that 'resources' to something more explicit (if anyone reading this is in such a position). Thanks for the help, Adam Dennis Geurts on 13/07/05 15:09, wrote: Hi Adam, what's the command you supply ?? 'm2 war:war' or 'm2 package' (it should be the latter) this might be a stupid question, but is the ' ApplicationResources.properties' file located at the 'src/main/resources' location in yout project ? Dennis On 7/13/05, Adam Hardy [EMAIL PROTECTED] wrote: I have exhausted the mailing list archives and the documentation on the website and I cannot see why my .properties file is not being included in my war, since my pom.xml appears to be correct. The file is not copied into the target directory nor is it included in the war file. I see from the archives that other people appear to be managing this fine. Here is my pom.xml (shortened): ?xml version=1.0 encoding=UTF-8? 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 maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdcom.mystuff/groupId artifactIdmystuff-web/artifactId packagingwar/packaging version1.0-SNAPSHOT/version dependencies dependency /dependency /dependencies build finalNamemystuff-web/finalName resources resource directorysrc/main/resources/directory includes includeApplicationResources.properties/include /includes /resource /resources /build /project I tried it with a targetPath element too, but with no joy either. Thanks Adam - 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]
[m2] adding an existing tld to a war file
Hi all, I'm using maven 2.0-alpha-3. To get used to the new structure in maven2 I started converting some of my projects to maven2 and came up with the following: 1) Suppose I want to package a war file and want to include the spring-1.0.2.tld in /WEB-INF how do I go about automatically inserting this file at all ? I added the dependency as follows: dependency groupIdspring/groupId artifactIdspring/artifactId version1.0.2/version typetld/type scoperuntime/scope /dependency Did I miss a feature in the maven-war-plugin ? Should I use the maven-resource-plugin ? 2) the second thing I noticed was the fact that when I set the scope of the *servletapi* dependency to 'provided' (to prevent inclusion in the war file), my tests that contain references to the 'javax.servlet' packages fail to compile. Is there a workaround to include the dependencies in the 'provided' scope into the 'test' scope ? thanks in advance, Dennis Geurts
Re: [m2] adding an existing tld to a war file
Thanks Emmanuel, If I'm not mistaken, the spring-1.0.2.tld is not added to the war at all... I'll check as soon as possible... I also notice that the maven-eclipse-plugin will add the dependency of type 'tld' to the classpath, resulting in an incorrect build classpath in eclipse. (but I'll look into this first in more detail) pertaining question #2: You mention the word 'workaround'. Does this mean you consider it a bug that jar of scope 'provided' are not available in 'test' scope ?? (btw, thanks: the workaround will resolve the issue !!!) Dennis On 7/12/05, Emmanuel Venisse [EMAIL PROTECTED] wrote: Dennis Geurts wrote: Hi all, I'm using maven 2.0-alpha-3. To get used to the new structure in maven2 I started converting some of my projects to maven2 and came up with the following: 1) Suppose I want to package a war file and want to include the spring-1.0.2.tld in /WEB-INF how do I go about automatically inserting this file at all ? I added the dependency as follows: dependency groupIdspring/groupId artifactIdspring/artifactId version1.0.2/version typetld/type scoperuntime/scope /dependency it's correct. Do you have an error? a wrong destination? Did I miss a feature in the maven-war-plugin ? Should I use the maven-resource-plugin ? 2) the second thing I noticed was the fact that when I set the scope of the *servletapi* dependency to 'provided' (to prevent inclusion in the war file), my tests that contain references to the 'javax.servlet' packages fail to compile. Is there a workaround to include the dependencies in the 'provided' scope into the 'test' scope ? The workaround is to split your war files and your sources. Put all your java sources in an other projet and add them in the new jar dep of your war. Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] adding an existing tld to a war file
On 7/12/05, Emmanuel Venisse [EMAIL PROTECTED] wrote: Dennis Geurts wrote: Thanks Emmanuel, If I'm not mistaken, the spring-1.0.2.tld is not added to the war at all... I'll check as soon as possible... Add a jira issue done: http://jira.codehaus.org/browse/MNG-579 I also notice that the maven-eclipse-plugin will add the dependency of type 'tld' to the classpath, resulting in an incorrect build classpath in eclipse. (but I'll look into this first in more detail) Add a jira issue done: http://jira.codehaus.org/browse/MNG-578 pertaining question #2: You mention the word 'workaround'. Does this mean you consider it a bug that jar of scope 'provided' are not available in 'test' scope ?? It isn't a bug. I don't know for the moment if we'll extend this scope for tests or if we'll create a new scope. ok, please be careful not to add too many scopes !! p.s. This is my first-time-jira-issueing-experience, so please correct me if the issues where too vague.. Dennis (btw, thanks: the workaround will resolve the issue !!!) Dennis On 7/12/05, Emmanuel Venisse [EMAIL PROTECTED] wrote: Dennis Geurts wrote: Hi all, I'm using maven 2.0-alpha-3. To get used to the new structure in maven2 I started converting some of my projects to maven2 and came up with the following: 1) Suppose I want to package a war file and want to include the spring-1.0.2.tld in /WEB-INF how do I go about automatically inserting this file at all ? I added the dependency as follows: dependency groupIdspring/groupId artifactIdspring/artifactId version1.0.2/version typetld/type scoperuntime/scope /dependency it's correct. Do you have an error? a wrong destination? Did I miss a feature in the maven-war-plugin ? Should I use the maven-resource-plugin ? 2) the second thing I noticed was the fact that when I set the scope of the *servletapi* dependency to 'provided' (to prevent inclusion in the war file), my tests that contain references to the 'javax.servlet' packages fail to compile. Is there a workaround to include the dependencies in the 'provided' scope into the 'test' scope ? The workaround is to split your war files and your sources. Put all your java sources in an other projet and add them in the new jar dep of your war. Emmanuel - 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: Question: maven 1 - native plugin usage
Hi Ruud,
What you want is certainly possible...
Although I haven't used this plugin on a linux platform (yet) I hope I'm
able
to get you up and running:
(but please provide your compiler/ linker args yourself :-) )
in your properties file:
maven.native.compiler.name=gcc
maven.native.link=executable /// or shared if you want to
maven.native.compiler.arg.start= your compiler args that end up at the
start of the command line
maven.native.compiler.arg.mid= your compiler args that end up in the
middle
maven.native.compiler.arg.end= your compiler args that end up at the end
maven.native.linker.arg.start= your linker args that end up at the start
maven.native.linker.arg.mid= your linker args that end up in the middle
maven.native.linker.arg.end = your linker args that end up at the end
after maven native the executable (or .so file) ends up in
'target/native/'
and is named '_' (underscore), for the executable or 'lib_.so' for the
shared library
If it's a libary, the file is copied to: ${maven.build.dir}/native/lib${
pom.artifactId}-${pom.currentVersion}.so
This is done (i think) for your convenience, but you can easily create a
postGoal yourself to copy the executable
(the 'underscore' file) to a human readable name.
I always read the project.jelly. Even if you don't know jelly you can
'infer' from the jelly code how the properties are used
and why things happen.
Hope this helps, feel free to ask more...
Dennis
On 7/7/05, Ruud Wijnands [EMAIL PROTECTED] wrote:
Hi,
I am new to maven and I would like to find out whether or not it is
possible to build native c++ code via the native plugin. I have a few
requirements and after investigating the native plugin I think they
are not meet.
By studying the plugin I have the impression that I can only build
shared libraries, since the native:compile target is always renamed to
something like artifactId-version.so Is that true?
Here are my requirements:
- build a set of c++ files into a single shared library for linux
- build a set of c++ files into a single static library for linux
- build a c++ file into an application
- link against third-party libraries
- provide include paths to thirdparty libraties
- set compiler and link flags
If the stuff mentioned above is possible, does anyone have an or some
examples for me?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 site plugin property not recognized
Hi Heiko,
If I understand correctly, you run 'm2 site:site', and you wonder
why the output ends up in 'target/site' instead of in '${basedir}/www'.
shouldn't you specify the 'outputDirectory' property instead ??
Dennis
On 7/1/05, puschteblume [EMAIL PROTECTED] wrote:
Hi
I have following entry in pom.xml:
project
build
sourceDirectorysrc/main/sourceDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
configuration
siteDirectory${basedir}/www/siteDirectory
/configuration
/plugin
/plugins
/build
/project
But the site is deployed to /target directory. Do you know if I have
missed something?
Thanks Heiko
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Different Java Versions for different sub-projects?
Aidan, I don't know if this'll solve your problem, but isn't is enough to specify the following properties: maven.compile.source=1.4 maven.compile.target=1.4 for the projects that need to compile with jdk1.4 compatibility ?? http://maven.apache.org/reference/plugins/java/properties.html provides more info. Dennis On 7/1/05, Aidan Donohoe [EMAIL PROTECTED] wrote: Hi, Does anybody know if there is there is a way to specify different JDKs for different projects? I have two sub projects, one of which must be compiled and ran with JDK 1.5 and another which should be compiled and ran with JDK 1.4. Is there a property which I can change which will point maven to a different JDK before compiling a project? Or would I have to dynamically change JAVA_HOME - but would this be possible? Thanks for any info, Aidan. (Using Maven 1.0.2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I have the xdoclet generated files be included in the compile?
Aidan,
I guess you want something like this:
Suppose the generated source code location is referred to with '${gen.dir}'
( 'target/xdoclet/ejbdoclet' in your case )
then you can make sure they get compiled at the same time as your
manually typed java files do, by defining the following preGoal:
preGoal name=java:compile
path id=generated.java.compile.src.set location=${gen.dir}/
maven:addPath id=maven.compile.src.set refid=
generated.java.compile.src.set/
/preGoal
please note that it is stated in the documentation that including sources in
such a way
is discouraged. As you mention correctly, it is unwise to copy the generated
source files
into the 'official' source directory (src/main/java).
furthermore, as an eclipse fan I must add that by adding the property:
'maven.eclipse.classpath.include=${gen.dir}'
to your project and subsequently executing 'maven eclipse'
the generated source file are also included in the classpath of your eclipse
project.
a 'clean project' in eclipse could delete the generated sources
this can be prevented by adding the property: 'maven.gen.src=${gen.dir}'
Dennis
On 6/17/05, Pascal Thivent [EMAIL PROTECTED] wrote:
Hi
i think that the maven.ejb.includes property of the maven ejb plugin
is what you're looking for.
Regards,
On 6/17/05, Aidan Donohoe [EMAIL PROTECTED] wrote:
Hi,
I am generating java files from xdoclet (into target/xdoclet/ejbdoclet),
and I want these files to be included in the compilation along with the
src directory.
Do I have to copy them into the src dir? (which seems nasty)
Or is there a better/right way to do this?
Thanks for any info,
Aidan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pascal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and ejbdoclet/xdoclet examples
Hi nathan,
the thing is,maven does not complain about missing dependencies ( for instance, the jmx-module is needed, but if you don't addits jar tothe list of dependencies, maven won't tell !!) -- maybethis iseven the cause you're experiencing failure to generate the interfaces...
running 'maven -X ...' will probably warn you saying: missing 'xxx.jar' but it will be easy to miss
I myself have used ejbdoclet in combination with middlegen. I personally didn't like to use the ejbdoclet plugin. Instead, I used
the ant task from within maven:
- relevant dependencies in project.xml are included in deps.txt
- relevantproperties are included in props.txt
Since I used the Ant task, I needed to define some extra goals in the maven.xml
- relevantgoals are included in goals.txt
I really hope this helps getting you on the road.
Since I'm new at this list, please excuse me if this is totally off topic...
Dennis Geurts
On 6/16/05, Nathan Sowatskey [EMAIL PROTECTED] wrote:
HiI have tried to follow the examples that I can find for Maven andxdoclet, and I have it apparently running, that it doesn't complain
about dependencies, but it doesn't seem to be processing my EJB togenerate the interfaces and deployment descriptors that I expect.I can get this to work with Ant, but not Maven it seems.Does anyone have any pointers to a project that I could peruse to get
some hints please? I looked at geronimo, but it doesn't seem to employejbdoclet.Many thanksNathan--Nathan Sowatskey - Technical Leader, NMTG CTO Engineering - Desk+44-208-824-4259/+1-408-527-2595 - Mobile +44-7740-449794 - AIM id
NathanCisco - [EMAIL PROTECTED]-To unsubscribe, e-mail:
[EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
!-- XDoclet dependencies --
dependency
groupIdservletapi/groupId
artifactIdservletapi/artifactId
version2.3/version
typejar/type
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxdoclet/artifactId
version1.2/version
typejar/type
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxdoclet-web-module/artifactId
version1.2/version
typejar/type
urlhttp://xdoclet.sf.net//url
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxdoclet-ejb-module/artifactId
version1.2/version
typejar/type
urlhttp://xdoclet.sf.net//url
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxdoclet-jmx-module/artifactId
version1.2/version
typejar/type
urlhttp://xdoclet.sf.net//url
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxjavadoc/artifactId
version1.0.2/version
typejar/type
urlhttp://xdoclet.sf.net//url
/dependency
dependency
groupIdxdoclet/groupId
artifactIdmaven-xdoclet-plugin/artifactId
version1.2/version
typeplugin/type
urlhttp://xdoclet.sf.net//url
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxdoclet-jboss-module/artifactId
version1.2/version
typejar/type
/dependency
gen.dir=${maven.build.dir}/middlegen/cmp20
ejb.dir=${maven.build.dir}/xdoclet/ejbdoclet
ejb.meta.dir=${maven.build.dir}/xdoclet/ejb
xdoclet.ejbdoclet.mergedir=${maven.src.dir}/merge/xdoclet/ejbdoclet
maven.eclipse.classpath.include=target/middlegen/cmp20/,target/xdoclet/ejbdoclet
maven.war.webapp.dir=${maven.build.dir}/xdoclet/webdoclet
maven.xdoclet.webdoclet.0=true
maven.xdoclet.webdoclet.0.destDir=${maven.build.dir}/xdoclet/webdoclet/WEB-INF
maven.xdoclet.webdoclet.0.mergeDir=${maven.src.dir}/merge/xdoclet
maven.xdoclet.webdoclet.deploymentdescriptor.0.destDir=${maven.build.dir}/xdoclet/webdoclet/WEB-INF
maven.xdoclet.webdoclet.deploymentdescriptor.0.mergeDir=${maven.src.dir}/merge/xdoclet
preGoal name=java:compile
!-- mkdir dir=${maven.build.dir}/xdoclet/webdoclet/WEB-INF /--
!-- attainGoal name=xdoclet:webdoclet /--
attainGoal name=ejbdoclet /
/preGoal
goal name=ejbdoclet
ant:taskdef name=ejbdoclet
classname=xdoclet.modules.ejb.EjbDocletTask
ant:classpath
ant:path refid=maven.dependency.classpath/
/ant:classpath
/ant:taskdef
ant:mkdir dir=${ejb.dir}/
ejbdoclet
destdir=${ejb.dir}
excludedtags=@version,@author
ejbspec=2.0
packageSubstitution packages=ejb substituteWith=ejb.interfaces/
ant:fileset
ant:setProperty name=dir
value=${pom.build.sourceDirectory}/
include name=**/ejb
