RE: tests fail if xml-apis are not in $MAVEN_HOME/lib?
I removed an xml-apis dependency from my project.xml and
started getting
errors while transforming my xml test reports. (stack trace below)
(java.lang.NoClassDefFoundError:
org/w3c/dom/ranges/DocumentRange) I fixed the problem by
putting the xml-apis.jar from the latest Xerces
into the $MAVEN_HOME/lib directory.
Was this the correct thing to do? Or did I just cover up some larger
issue by doing so? It just seems like a weird fix, and I've
never heard anyone else talk about having to do this on the
list here, so I'm
wondering if there's something else going on.
Adding a jar to ${MAVEN_HOME}/lib means that it will get bootstrapped into
the maven classloader and now that jar doesn't become a dependency on your
particular project but instead it will be there for any project that you
create in the future.
If you need org/w3c/dom/ranges/DocumentRange for your project I would add
that artifact to your dependencies element.
Christopher Farnham
Senior Consultant at Wrycan, Inc.
[EMAIL PROTECTED]
http://www.wrycan.com
[junit] Running com.wrycan.common.io.FilePipeTest
[junit] java.lang.NoClassDefFoundError:
org/w3c/dom/ranges/DocumentRange
[junit] at java.lang.ClassLoader.defineClass0(Native Method)
[junit] at
java.lang.ClassLoader.defineClass(ClassLoader.java:537)
[junit] at
java.security.SecureClassLoader.defineClass(SecureClassLoader
.java:123)
[junit] at
java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
[junit] at
java.net.URLClassLoader.access$100(URLClassLoader.java:55)
[junit] at
java.net.URLClassLoader$1.run(URLClassLoader.java:194)
[junit] at
java.security.AccessController.doPrivileged(Native Method)
[junit] at
java.net.URLClassLoader.findClass(URLClassLoader.java:187)
[junit] at
java.lang.ClassLoader.loadClass(ClassLoader.java:289)
[junit] at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
[junit] at
java.lang.ClassLoader.loadClass(ClassLoader.java:235)
[junit] at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
[junit] at java.lang.ClassLoader.defineClass0(Native Method)
[junit] at
java.lang.ClassLoader.defineClass(ClassLoader.java:537)
[junit] at
java.security.SecureClassLoader.defineClass(SecureClassLoader
.java:123)
[junit] at
java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
[junit] at
java.net.URLClassLoader.access$100(URLClassLoader.java:55)
[junit] at
java.net.URLClassLoader$1.run(URLClassLoader.java:194)
[junit] at
java.security.AccessController.doPrivileged(Native Method)
[junit] at
java.net.URLClassLoader.findClass(URLClassLoader.java:187)
[junit] at
java.lang.ClassLoader.loadClass(ClassLoader.java:289)
[junit] at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
[junit] at
java.lang.ClassLoader.loadClass(ClassLoader.java:235)
[junit] at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
[junit] at
org.apache.xerces.jaxp.DocumentBuilderImpl.init(Unknown Sou
rce)
[junit] at
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocument
Builder(Unknown Source)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFo
rmatter.getDocumentBuilder(XMLJUnitResultFormatter.java:93)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFo
rmatter.startTestSuite(XMLJUnitResultFormatter.java:138)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.
fireStartTestSuite(JUnitTestRunner.java:445)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.
run(JUnitTestRunner.java:279)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.
main(JUnitTestRunner.java:536)
[junit] Exception in thread main
[junit] [ERROR] TEST com.wrycan.common.io.FilePipeTest FAILED
[junit] Running com.wrycan.common.io.ZipUtilsTest
[junit] java.lang.NoClassDefFoundError:
org/w3c/dom/ranges/DocumentRange
[junit] at java.lang.ClassLoader.defineClass0(Native Method)
[junit] at
java.lang.ClassLoader.defineClass(ClassLoader.java:537)
[junit] at
java.security.SecureClassLoader.defineClass(SecureClassLoader
.java:123)
[junit] at
java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
[junit] at
java.net.URLClassLoader.access$100(URLClassLoader.java:55)
[junit] at
java.net.URLClassLoader$1.run(URLClassLoader.java:194)
[junit] at
java.security.AccessController.doPrivileged(Native Method)
[junit] at
java.net.URLClassLoader.findClass(URLClassLoader.java:187)
[junit] at
java.lang.ClassLoader.loadClass(ClassLoader.java:289)
[junit] at
RE: Dependency issues for junit tests [brain dump]
I totally disagree. And that's fine, but what I''m going to do is make both for a simple experiment that users can participate in and make patches for if they like. People look too much at the type and attribute that to packaging. I still hold that one marker per dependency would cover everything and you would end up with a small number of handlers, but I'll make another flavour which uses kind decorators then you users can throw whatever you like as use cases and we'll see how both unfold. This poor horse has been beaten so much that it can't be recognized now. If the two dependency attributes can be blended into one then that is fine with me. I don't really know how that can be implemented but 1) if it can - sweet! (less XML), 2) you often espouse great ideas and I believe that your handler architecture can address the aforementioned task. An interesting note: my colleagues and I at work are learning more about XP techniques and one of the idioms we are trying to live by is less debate and more testing. In the past we often sit around and debate over what is the correct solution is and we never get anywhere of conseqence because we have strong personalities. In addition we usually agree on overall architecture but then spend an inordinate amount of time arguing over details that affects only 1% of the application or 1% of performance improvement. Anyway we have a saying: If an argument extends over 10 minutes, stop debating and do a test to see who is right! (the argument usually ends after that. :-)). Easy enough to do with the components, just flip one implementation out for the other and we can try one, the other, or any variant in between. It's something that users feel concerned about so we'll throw it out there as a little hack-a-thon as the debate will go on ad nauseum. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - 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: Scripting [was Simple properties question...]
I know little about these tools mentioned recently like Beanshell, OGNL, Groovy, etc. Although I recently downloaded Beanshell and it appears to be a brillant application. It's like writing shell scripts in Java. Anyway, if Maven moves away from Jelly and into Beanshell (or whatever other scripting language) are plugins still use Ant constructs? Tha is, will javac/ compile source or will it be replaced with some completely other way of compiling? -Original Message- From: Stephen Colebourne To: Maven Users List Sent: 1/10/2004 8:17 AM Subject: Re: Scripting [was Simple properties question...] I suspect we would all like to dump jelly ASAP. I've come to realise that my initial problems, and thus opposition, to maven are due to jelly in a large part. And I do find ant fustrating too. What I want to use is a proper java-like (so I don't have to learn anything new) scripting language (so it doesn't need precompiling). I want eclipse/ide integration such that it offers completions just like other coding (so I don't need to go to the website all the time). And I want it to work the way I expect it to first time (as I don't have time to waste) Of course wish lists are easy, and I suspect you wouldn't disagree with the above. As I said, I have no experience with any of the script tools, so I have to leave the judgement to others :-) Stephen maven.javadoc.destdir=target/apidocs maven.javadoc.sourcedir=src/java maven.javadoc.private=true maven.javadoc.generate() maven.artifact.deploy-snapshot(maven.javadoc) From: Jason van Zyl [EMAIL PROTECTED] Things like Beanshell and OGNL just work. I have never had a single problem with OGNL which is simply just awesome for dealing with expressions. And I've rarely had any problems with Beanshell. There aren't many blog entries about either. Groovy may eventually be good if it outlasts the hype. The ideas behind Groovy are awesome, I'll wait to see if the implementation is equally so. This is a decision not to be taken lightly, as maven can't afford to get it wrong a second time! Well, I'm not too worried about it. Right now I'll take the tool where it's not a crap shoot what comes out the other end. I've spent an ungodly number of hours trying to figure out why Jelly contexts that seem to have popped into existence with no ryhme or reason, why some classloading mechanism is used, and simply been baffled at what comes out of Jexl. These things just don't happen with Beanshell and OGNL. - 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: Dependency issues for junit tests [brain dump]
The type and kind elements are really doing the same function which is really providing attribute information of a sort. I honestly don't think you would gain more with several kind elements over several type elements. What has happened though is the type has come to represent part of the path to the artifact but to my mind there really wouldn't be much distinction to a first time onlooker between type and kind to me they mean essentially the same thing. Many who participated in this thread want to specify the following properties for a dependency: .jar, .war, .ejb, .class, .zip, .ear and anything else that is a legal CLASSPATH element in Java. Whether this is called a type or kind or extension is just a matter of doing it. It doesn't really matter. You're right that type has manifested itself as part of the artifact file name. Maybe it isn't needed? How often are dependency elements differentiated only on type? Like commons-lang-1.0.jar and commons-lang-1.0.zip. I really don't know. My example is silly but I don't do much EJB stuff where maybe one would differentiate artifacts by .ejb or .jar. To me this is simply a conveinent way of specifying the path entries in the CLASSPATH. This says absolutely nothing about how the CLASSPATH is created (besides the obvious that there is a dependency element.) To me if you you look at that block above someone might guess the type really refers to the packaging and the path in the repository. What we are essentially after is that the handler for a particular type deal with the how that type is packaged, how it can be found, how it is processed and how it is integrated into the build. With the single type element a particular handler should know what to do. Might a dependency need more than one type of attribute? I honestly don't think so. With the type = test we are making the assumption that the packaging and path refers to a JAR and that it shouldn't be part of the standard classpath. This is the issue - why is that a valid assumption? A CLASSPATH can contain any number of valid entries. It can contain a .zip, .class, .jar, .ear, even a directory! (well that can't fit in the artifact model). For a developer who wants to add the Oracle classes12.zip artifact only to his unit tests, I don't know how that would look. dependency groupIdoracle/groupId artifactIdclasses12/artifactId typetest/type dependency Under your model Maven would try to find the classes12.jar file and that doesn't exist. One could also build, for example, test EJB implementations different than production EJB implementations (for instance that don't have to do round trips to the server.) So doing something like dependency groupIdcompany.com/groupId artifactIdtest-ejb/artifactId typetest/type dependency Again would try to find test-ejb.jar and NOT test-ejb.ejb which is not the desired effect. If there is another requirement for a particular artifact for testing then you simply make another handler that deals with that type. What's not OK with adding dependecies to unitTest block? First of all I think that there could be more then two kind of dependecies. I see at least three kinds: compile-time, runtime, test There could be an unlimited number of types of dependencies as people may decide to arbitrarily handle those in specifiec ways with a specific handler but these dependencies but I think having them within the unitTest element (at some point in the future just test/ might be more appropriate) I think it's very clear what they are for. I honestly don't think compile-time and runtime are things that we will need to differentiate. For a period of time I felt the same way as you did but there was opposition at my work about this and they did bring up a legitimate point. We use commons.log for our logging package and our commons-log implementor is log4j. So log4j is a runtime dependency but not a compile-time dependency. That is, we want developers only to write Java code with commons.log. If they put log4j logging statements in the code we should get a compile error indicating that the log4j package cannot be resolved. So it is necessary in this case to specify that an artifact is compile-time or runtime. This actually brings up another point about the discussion of handlers mentioned. Log4j is a legitimate compile-time and runtime dependency. There might be other projects that only want to use log4j. In that case it's a compile-time dependency. So an artifact can play more than one role. In that case you have to preserve the attribute information (groupId, versionId, artifactId so you can find it in the repository) and then use an additional property to indicate when it is supposed to be added to the CLASSPATH. Currently most of the time people add runtime requirements or testing which the transitive dependency mechanism should handle. Really, all you want
RE: Classpath issue - Want to use jars from my directory and not from maven repository
The best way: Maven works only with repositories (local and remote), but you can define a remote repository with the file protocol. maven.remote.repo = http://www.ibiblio.org/maven,file:/// your_directory/ If you use the file protocol, you must respect the repository structure in your directory. The bad way: You can write a maven.xml, and add all you jars present in your lib directory to the maven classpath with addpath tag. You can also specify maven.jar.override = on in your project.properties file and then explicity declare the location of each dependency you want to override. http://maven.apache.org/reference/user-guide.html#Overriding%20Stated%20Depe ndencies Emmanuel - Original Message - From: Tapan Nanawati [EMAIL PROTECTED] To: Maven List (E-mail) [EMAIL PROTECTED] Sent: Friday, January 09, 2004 1:01 PM Subject: Classpath issue - Want to use jars from my directory and not from maven repository Hi all We have a specified lib folder where we have our library files. We want to use that for compiling the source and not download from the repository. Please tell me how to do that. I struggled with setting up various parameters in dependencies but could not succeed. If some one can give a sample dependency element, it would be a great help. Thanks very much. Regards Tapan - 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: unknown site generation error
-Original Message- From: Felipe Gaúcho [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 10:09 AM To: Maven Users List Subject: unknown site generation error When I tryied to generate the site reports, it failed but I didn´t understand why !? C:\gaucho_WEB\webvob\implementacaomaven site __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT site: xdoc:register-reports: maven-jdepend-plugin:register: maven-checkstyle-plugin:register: maven-changes-plugin:register: maven-changelog-plugin:register: maven-developer-activity-plugin:register: maven-file-activity-plugin:register: maven-license-plugin:register: maven-javadoc-plugin:register: maven-jxr-plugin:register: maven-junit-report-plugin:register: maven-linkcheck-plugin:register: maven-tasklist-plugin:register: site:run-reports: [echo] Generating the Metrics... maven-jdepend-plugin:report: java:prepare-filesystem: java:compile: [echo] Compiling to C:\gaucho_WEB\webvob\implementacao/target/classes BUILD FAILED File.. file:/C:/Documents and Settings/gaucho/.maven/plugins/maven-xdoc-plug in-1.4/ Element... j:include Line.. 110 Column 55 org/dom4j/Element Total time: 43 seconds Finished at: Thu Jan 08 15:05:05 GMT-03:00 2004 Can you successfully compile? Its failing after the java:compile step (even though the maven-xdoc-plugin is being invoked). You can also run maven -X site and look at the stack trace. C:\gaucho_WEB\webvob\implementacao - 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: unknown site generation error
(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) Root cause java.lang.NoClassDefFoundError: org/dom4j/Element at org.dom4j.xpath.XPathPattern.getContextSupport(XPathPattern.java:131) at org.dom4j.xpath.XPathPattern.init(XPathPattern.java:62) at org.dom4j.DocumentFactory.createPattern(DocumentFactory.java:249) at org.dom4j.DocumentHelper.createPattern(DocumentHelper.java:149) at org.apache.commons.jelly.tags.jsl.JSLTagLibrary.createExpression(JSLT agLibrary.java:118) at org.apache.commons.jelly.parser.XMLParser.createTag(XMLParser.java:10 70) at org.apache.commons.jelly.parser.XMLParser.startElement(XMLParser.java :647) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Sour ce) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unkn own Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent Dispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un known Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.jelly.parser.XMLParser.parse(XMLParser.java:357) at org.apache.commons.jelly.JellyContext.compileScript(JellyContext.java :489) at org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:608 ) at org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:584 ) at org.apache.commons.jelly.tags.core.IncludeTag.doTag(IncludeTag.java:1 43) 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.FileTag.writeBody(FileTag.java:207 ) at org.apache.commons.jelly.tags.core.FileTag.doTag(FileTag.java:103) 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.impl.DynamicTag.doTag(DynamicTag.java:125) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.jav a:145) 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.tags.core.IfTag.doTag(IfTag.java:88) 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 com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128) 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: 448) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:348) at org.apache.maven.cli.App.doMain(App.java:543) at org.apache.maven.cli.App.main(App.java:1109) 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) Total time: 41 seconds Finished at: Thu Jan 08 15:47:56 GMT-03:00 2004 C:\gaucho_WEB\webvob\implementacao -Mensagem original- De: Steve Garcia [mailto:[EMAIL PROTECTED] Enviada em: quinta-feira, 8 de janeiro de 2004 15:15 Para: 'Maven Users List' Assunto: RE: unknown site generation error -Original Message- From: Felipe Gaúcho [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 10:09 AM To: Maven Users List Subject: unknown site
RE: unknown site generation error
I would have guessed that your Maven installation would have this jar.
The only other thing I can think of is doing drastic things like deleting
your plugin directory (so Maven will unpack them again), reinstalling Maven,
and trying other things too like
maven -X maven-jdepend-plugin:report and look at the plugin.jelly and the
Maven output. At this point I can't really help you any further.
You can also not run the jdepend report. Remove that section from the POM
reports section.
That's the easiest step. :-)
-- Steve
-Original Message-
From: Felipe Gaúcho [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 11:17 AM
To: Maven Users List
Subject: RES: unknown site generation error
there is the bellow version:
dom4j-1.4-dev-8.jar
-Mensagem original-
De: Steve Garcia [mailto:[EMAIL PROTECTED]
Enviada em: quinta-feira, 8 de janeiro de 2004 16:10
Para: 'Maven Users List'
Assunto: RE: unknown site generation error
You are missing the dom4j API. I would check your
${MAVEN_HOME}/lib directory to see if you have the dom4j jar
file there.
-Original Message-
From: Felipe Gaúcho [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 10:49 AM
To: Maven Users List
Subject: RES: unknown site generation error
BUILD FAILED
File.. file:/C:/Documents and
Settings/gaucho/.maven/plugins/maven-xdoc-plug
in-1.4/
Element... j:include
Line.. 110
Column 55
org/dom4j/Element
com.werken.werkz.UnattainableGoalException: Unable to obtain goal
[maven-jdepend -plugin:report] -- file:/C:/Documents and
Settings/gaucho/.maven/plugins/maven-x
doc-plugin-1.4/:110:55: j:include org/dom4j/Element
at com.werken.werkz.Goal.fire(Goal.java:646)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:
448)
at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:348)
at org.apache.maven.cli.App.doMain(App.java:543)
at org.apache.maven.cli.App.main(App.java:1109)
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)
org.apache.commons.jelly.JellyTagException:
file:/C:/Documents and Settings/gauc
ho/.maven/plugins/maven-xdoc-plugin-1.4/:110:55: j:include
org/dom4j/Element
at
org.apache.commons.jelly.impl.TagScript.handleException(TagScript.jav
a:702)
at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:296)
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.FileTag.writeBody(FileTag.java:207
)
at
org.apache.commons.jelly.tags.core.FileTag.doTag(FileTag.java:103)
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.impl.DynamicTag.doTag(DynamicTag.java:125)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.jav
a:145)
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.tags.core.IfTag.doTag(IfTag.java:88)
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
com.werken.werkz.jelly.GoalTag$1.performAction(GoalTag.java:128)
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:
448)
at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:348)
at org.apache.maven.cli.App.doMain(App.java:543)
at org.apache.maven.cli.App.main(App.java:1109)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl
RE: unknown site generation error (a new hope)
I would refrain from commenting out lines in maven released plugins unless
it is something that the committers or others who know a lot about the
plugin advise to do.
The very first time I used Maven I tried porting a large, existing software
application at my work. It was a painful and frustrating process because
our project layout was so vastly different from Maven's. Simple plugins
like compile wouldn't work until much tweaking, and various reports wouldn't
run either.
The next time I used Maven I began a new project from scratch. My Maven POM
was small and comprenehsible, and I didn't have a need for a maven.xml file.
All of my reports ran. It was great. As I added more code Maven blissfully
managed it. I was adding .properties files, xml files, wrote some custom
goals in maven.xml.
It was actually better for me to learn Maven the latter way. I was
frustrated with Maven when I first used it.
When I originally became familiar with Maven I thought it was a fault of the
tool. But now I think that there are so many software development processes
and styles that it would be hard to build a tool that can seamlessly manage
all of them. I think Maven is not yet there (I don't recommend it for the
very large software dev projects) but now that I've used it more and I
listen in (and occasionally contribute) on the user and dev mailing lists I
think like Jason said a little bit ago that Maven has only touched the tip
of the iceberg as to how powerful and useful it can be.
I do think in time that Maven will be used as much as Ant. Ant is really
cool and there are tons of third party libraries for it but at some level
the build.xml files just become unmanageable because there is so much crap
in them. Maven allows you to delete 70-90% of the targets in your build.xml
file.
OK I'll stop now because this is not what you were looking for. :-) Anyway
if you really need the jdepend report then I'm not sure how to help you. You
said 'commented the bellow lines I don't see any lines commented out so I'm
not sure what you did. But I would start doing small things like getting
compile, jar, javadoc working and then move to the bigger more fancy reports
since it's not all working for you at right out of the box.
-- Steve
-Original Message-
From: Felipe Gaúcho [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 1:14 PM
To: Maven Users List
Subject: RES: unknown site generation error (a new hope)
When I comented the bellow lines in the
maven-xdoc-plugin-1.4, the mavem generated some reports..
but bugged another ones...:
j:include uri=${stylesheetURI.toString()}/
any ideas ?
the problem seems reside in this variable stylesheet ...
-Mensagem original-
De: Felipe Gaúcho [mailto:[EMAIL PROTECTED]
Enviada em: quinta-feira, 8 de janeiro de 2004 16:31
Para: Maven Users List
Assunto: RES: unknown site generation error
Thank you very much...
I´m a maven begginer, and I will study the documentation a
little bit more.
your tips were really very usefull...
regards,
Felipe Gaúcho
-Mensagem original-
De: Steve Garcia [mailto:[EMAIL PROTECTED]
Enviada em: quinta-feira, 8 de janeiro de 2004 16:25
Para: 'Maven Users List'
Assunto: RE: unknown site generation error
I would have guessed that your Maven installation would have this jar.
The only other thing I can think of is doing drastic things
like deleting your plugin directory (so Maven will unpack
them again), reinstalling Maven, and trying other things too
like maven -X maven-jdepend-plugin:report and look at the
plugin.jelly and the Maven output. At this point I can't
really help you any further.
You can also not run the jdepend report. Remove that section
from the POM reports section. That's the easiest step. :-)
-- Steve
-Original Message-
From: Felipe Gaúcho [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 11:17 AM
To: Maven Users List
Subject: RES: unknown site generation error
there is the bellow version:
dom4j-1.4-dev-8.jar
-Mensagem original-
De: Steve Garcia [mailto:[EMAIL PROTECTED]
Enviada em: quinta-feira, 8 de janeiro de 2004 16:10
Para: 'Maven Users List'
Assunto: RE: unknown site generation error
You are missing the dom4j API. I would check your
${MAVEN_HOME}/lib
directory to see if you have the dom4j jar file there.
-Original Message-
From: Felipe Gaúcho [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 10:49 AM
To: Maven Users List
Subject: RES: unknown site generation error
BUILD FAILED
File.. file:/C:/Documents and
Settings/gaucho/.maven/plugins/maven-xdoc-plug
in-1.4/
Element... j:include
Line.. 110
Column 55
org/dom4j/Element
com.werken.werkz.UnattainableGoalException: Unable to obtain goal
[maven-jdepend -plugin:report] -- file:/C:/Documents
RE: Mutliple source directories in project.xml
What about specifying sourceDirectory as a fileset? This would add a lot more work to retrofit plugins but it really would give developers good flexibility. sourceDirectory include name=dir1 / include name=dir2 / include name=dir3 / /sourceDirectory Absolutely never going to happen. With that you've just made everything to do with sources an order of magnitude more difficult which means maven internals and all the plugins. Well...I'm not surprised to hear that. I think generatedSourceDirectory sounds OK but would like to hear from more people who use extensively use code generation in their projects. I'm sure Maven will hear stories about how that strategy is not compatible for various reasons. Would the java plugin compile sourceDirectory first then generatesSourceDirectory second? Well it would presumably occur at the same time. Other plugins that require access to a source directory would need to be tweaked to accept two directories. For some like java:compile and I think javadoc I think that's OK. What each individual plugin could do though is make their own private Ant fileset from sourceDirectory and generatedSourceDirectory if they are unable to process multiple source directories. This would never be visible to the core Maven model or to other plugins for that matter. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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: Mutliple source directories in project.xml
On Thu, 2004-01-08 at 17:16, Steve Garcia wrote: [ snip ] Would the java plugin compile sourceDirectory first then generatesSourceDirectory second? Well it would presumably occur at the same time. Other plugins that require access to a source directory would need to be tweaked to accept two directories. For some like java:compile and I think javadoc I think that's OK. There is only one sourceDirectory/ but what happens internally is that we track a source directory set which takes into account additional sources primarily resulting from generation. So if you look at the Antlr plugin is generates the sources before java:compile and then adds the sources it generates to the internal source directory set. Plugins have access to this source directory set. What each individual plugin could do though is make their own private Ant fileset from sourceDirectory and generatedSourceDirectory if they are unable to process multiple source directories. This would never be visible to the core Maven model or to other plugins for that matter. Plugins that operate on sources should typically deal with the internal source set which is currently the Ant reference of maven.compile.src.set. So you could generate some sources using Antlr and then run xdoclet on the maven.compile.src.set and it would operate on the all the sources, static and generated. Fantastic. Then it sounds like adding generatedSourceDirectory to the POM should be a fairly easy task. This would amount to adding that directory to the maven.compile.src.set Ant reference? I think this sounds completely reasonable and while it may not help out every project that extensively uses code generation it would help many projects. The specific semantics I'm still in the blue (re: what John Casey wrote previous in this thread where Maven would only compile sourceDirectory if generatedSourceDirectory didn't exist. Maybe I didn't understand what he wrote and I'll reread his emails again. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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]
Articles on Artifact Repository
Does anybody know of any articles I can find on the Internet detailing the advantages and drawbacks of using an artifact repository (instead of sticking artifacts in an SCM) for software development? I want to read more about this style of development - I have some colleagues who are not convinced that it is a good idea to put artifacts somewhere else besides a SCM system. While there is general agreement that a repository is a good thing (preventing duplicate copies of the same jar) my colleagues argue that backing the repository with a SCM provides more security (can't accidently put a patch into a third party jar) and allows anyone to, at any past point in time, to get a complete, unadulterated snapshot of a project and build it. I think there are good arguments both ways (even though I support the Maven artifact model.) Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Articles on Artifact Repository
Who says its an either/or proposition? Oh I know there are discussions about how you shouldn't put jars into an SCM system, but if you're a paranoid product developer (like me) and you have to be able to recreate any build of your published product 'as at' any time in the past, I think you definitely want all dependent jars in SCM (I know I do) There is nothing to stop you using the maven repository model, but get to the repository via an SCM checkin (or both) Maven artifact repositories are *not* hooked in with SCM systems. That is, when you compile your project, Maven tries to satisfy the dependencies by fetching the artifact via a URL (http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-1.0.jar or /home/user/java/repository/commons-lang/jars/commons-lang-1.0.jar). Maven does NOT talk SCM speak. It does not, for instance, do a SCM sync and then look in your local or remote repository to satisfy the project dependencies and build the classpath. How the 3rd party jars get onto ibiblio is one thing, but how 3rd party jars get into your own remote repository is entirely another. I am toying with the idea of a 3-tieres remote repository approach. One will be for published artifacts (i.e. jar:install etc not under SCM otherwise I'd probably have to monkey with the deploy plugin?). The second will be for 3rd party libraries (under SCM control) and the 3rd would be ibiblio, probably just for maven and anything maven directly needs. I haven't set this up yet so maybe it's a really bad idea Well...this is a different question than what I originally wrote. There are two groups of people at my work that want to configure our software projects in different ways. First way: If your project must follow another project's HEAD, then everytime you want to compile your own project you must also *compile* the other project you depend on. So you have to sync the other project, build the other project, then build your own project. This methodology obviates the need to install the other project's SNAPSHOT into a repository. Second way: The maven way - you depend on the SNAPSHOT jar and you don't build the other project yourself. Most companies have a dedicated Build and Test (BAT) machine for vetting changes to code and provide a single point of failure. I think the first way is daft but the argument for it is you are getting the very LATEST of a branch, not something that is almost near the HEAD. I think there are more drawbacks with this than advantages. Matthew -Original Message- From: Steve Garcia [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 6:28 PM To: '[EMAIL PROTECTED] ' Subject: Articles on Artifact Repository Does anybody know of any articles I can find on the Internet detailing the advantages and drawbacks of using an artifact repository (instead of sticking artifacts in an SCM) for software development? I want to read more about this style of development - I have some colleagues who are not convinced that it is a good idea to put artifacts somewhere else besides a SCM system. While there is general agreement that a repository is a good thing (preventing duplicate copies of the same jar) my colleagues argue that backing the repository with a SCM provides more security (can't accidently put a patch into a third party jar) and allows anyone to, at any past point in time, to get a complete, unadulterated snapshot of a project and build it. I think there are good arguments both ways (even though I support the Maven artifact model.) 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]
RE: Extra space after links
So how do we fix this? I've seen many Maven sites that don't have the problem. Why not? I'm not sure how to fix this. I just looked at http://db.apache.org/torque and there are several pages that contain anchor tags that have an extra space. In this case the extra space comes after the end of the a tag, so you'll see on your browser Turbine Framework . (where Turbine Framework is a link) and the HTML looks like a href=http://jakarta.apache.org/turbine/;Turbine Framework/a . There is a CRLF after the /a and the period . I think this is annoying but the reason why I haven't put more time into it is it's not that big of a deal to me and it would probably involve looking at the source code for Anakia, which is the tool that transforms XML into documentation. It's located here http://jakarta.apache.org/velocity/anakia.html So the fix would be a lot of work and in my opinion is low priority. In any event, a bug should be logged for this. First need to find out if it's Maven responsibility (using an old version of Anakia or Velocity) or if it's Velocity's responsibility. -- Steve Steve Garcia wrote: I don't think this is your problem - I think this is a snafu with whatever tool is used to convert xml - html (I think it's Anakia?). Anyway that pecularity happens with me too. In fact I get random spaces throughout my site - it's not necessarily related to the text in the anchor tag. If you look closely at other Maven sites too I remember seeing that phenonemon as well. -Original Message- From: Brian S O'Neill To: [EMAIL PROTECTED] Sent: 1/2/2004 7:34 PM Subject: Extra space after links When I run Maven, (version 1.0 rc1) all the generated HTML links have an extra space at the end which is underlined. When I view the HTML source, there is a bunch of whitespace and newlines before the closing anchor tag. I've not seen this problem on other Maven generated sites, but some have a stylesheet which doesn't show links as underlined. Still, when I view the source of those pages, the extra whitespace is not there. What am I doing wrong to cause all this extra whitespace to be generated? - 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: When to add or not add dependencies?
Your java software project must specify all of it's dependencies in the project.xml file under the dependencies tag. Even though you have a local repository with a bunch of jar files, you need to specify which ones you need for your project because they are not all included automagically when you create your project.xml. -- Steve Hi, I just added all the dependencies that were not in my local repository to my remote repository. BTW, the JARS in the local repository were downloaded when I initiated my first 'maven java:compile'. Now, does one have to add these dependencies to the project.xml too? At this time, I'm getting error messages when I perform the above mentioned command. It's not clear in the document when and when not to add dependencies to the project.xml file. Thanks in advance for any development advice in regards to this issue. -Conrad - 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 repositories?
You can point your browser to http://www.ibiblio.org/maven and you'll get a directory listing of all the artifacts main directories (groupId). -Original Message- From: Jonathan Hawkes [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 9:18 AM To: [EMAIL PROTECTED] Subject: Maven repositories? Hey, Is there any way to browse the repository at ibiblio.org to see if a particular component/library is installed there? What about alternative repositories? Thanks! Jonathan Hawkes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: groupId naming convention
On Tue, 2003-12-23 at 14:37, Sonnek, Ryan wrote:
Is there any reason for the current groupId naming
convention? I find
it unnecessary that nearly all of the artifacts on ibiblio have
duplicate groupIds and artifactIds. Could the groupId be
changed to
use the reverse DNS name (ie: org.apache.maven)?
That's what the plan is, look in the Wiki. Ben's got
something there on that specifically I believe.
Even though I think the DNS methodology is a good one it sure is nice to be
able to go to ibiblo.org/maven and see every type of artifact that is up
there from the repository root. Once Maven goes to the DNS way we will have
to navigate the package structure to find out if an artifact is present.
And sometimes you don't even know the artifact package structure so you may
not find the jar you are looking for.
For instance someome tells me to use the rhino jar, now it's located at
${REPO}/rhino, but in the future it will be located in
${REPO}/org/mozilla/rhino.
Eclipse has used this convention for
naming their plugins, and it really helps organize and
differentiate
between files.
Ryan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a
rational and technical order to justify his work and to be
justified in it.
-- Jacques Ellul, The Technological Society
-
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: groupId naming convention
Yea there are advantages and disadvantages either way. A big advantage of
keeping the existing repository is when I see jar packages I'm not familiar
with, there is a better change I'll look into them out of curiosity. I've
learned more about third-party tools since I've started using Maven on the
majority of my projects. :) That is really a good thing.
At the same time a DNS layout is also beneficial for better layout
scenarios. We have so many projects at my work that the groupId/artifactId
is not an excellent approach, but we will make do with it.
I agree with you that both ways have their advantages and disadvantages -
and with the new Maven-Wagon my understanding is that both ways will be
supported. :)
-Original Message-
From: Sonnek, Ryan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 23, 2003 2:10 PM
To: 'Maven Users List'
Subject: RE: groupId naming convention
I know what you mean. I'm not 100% sold on having the
reverse DNS name break into folders. I think that a flat
directory structure would also be useful, for reasons like
you mentioned (browsing for artifacts). This is how eclipse
organizes their plugins, and we have adopted this same
structure on my company's maven repository. All of our
internal artifacts are hosted using something like
${REPO}/org.mozilla.rhino/jars/rhino-x.x.jar
I could live with either scenario.
Ryan
-Original Message-
From: Steve Garcia [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 23, 2003 3:55 PM
To: 'Maven Users List'
Subject: RE: groupId naming convention
On Tue, 2003-12-23 at 14:37, Sonnek, Ryan wrote:
Is there any reason for the current groupId naming
convention? I find
it unnecessary that nearly all of the artifacts on ibiblio have
duplicate groupIds and artifactIds. Could the groupId be
changed to
use the reverse DNS name (ie: org.apache.maven)?
That's what the plan is, look in the Wiki. Ben's got
something there on that specifically I believe.
Even though I think the DNS methodology is a good one it sure
is nice to be able to go to ibiblo.org/maven and see every
type of artifact that is up there from the repository root.
Once Maven goes to the DNS way we will have to navigate the
package structure to find out if an artifact is present. And
sometimes you don't even know the artifact package structure
so you may not find the jar you are looking for.
For instance someome tells me to use the rhino jar, now it's
located at ${REPO}/rhino, but in the future it will be
located in ${REPO}/org/mozilla/rhino.
Eclipse has used this convention for
naming their plugins, and it really helps organize and
differentiate
between files.
Ryan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a
rational and technical order to justify his work and to be
justified in it.
-- Jacques Ellul, The Technological Society
-
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]
RE: Simple Maven example?
http://maven.apache.org/misc/articles.html Click on the first link Apache Maven Simplifies... -Original Message- From: Jonathan Hawkes [mailto:[EMAIL PROTECTED] Sent: Monday, December 22, 2003 11:59 AM To: [EMAIL PROTECTED] Subject: Simple Maven example? Is there a simple example anywhere on how to get started using Maven? Thanks! Jonathan Hawkes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weird Clover Behavior
I set maven.junit.fork = true and now I have classpath issues, java.lang.NoClassDefFoundError: org/w3c/dom/ranges/DocumentRange. Do I need to twiddle my dependencies tag? I put the xerces jar in my root classloader but that didn't help. But xerces-2.4.0.jar doesn't have org/w3c/dom/ranges/DocumentRange. I'm not even sure what artifact that is coming from. I'm running Java 1.4.2 ... hmm. jeez I'm tired. I can't even think straight. :( I have commons-lang, commons-logging, freemarker, junit, xerces, and hsqldb in my dependencies element. -Original Message- From: Jason van Zyl To: Maven Users List Sent: 12/19/2003 10:55 PM Subject: Re: Weird Clover Behavior On Sat, 2003-12-20 at 00:58, Steve Garcia wrote: The Clover report that gets produced from my code is totally off - I have close to 90% total coverage for my project and Clover is reporting only 8.5%. When I run maven clover manually the coverage numbers are closer to what they should be. But I still see weird behavior like a branch not being hit in my equals method when it obviously is. Anybody else see this kind of behavior? Basically if I do maven clean clover I get totally inaccurate coverage numbers. If I then invoke maven clover they are much closer to what they should be. You set: maven.junit.fork = true In order for clover to work correctly. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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: Weird Clover Behavior
Vincent, that makes sense - thanks for the explanation. I'll work on it from here. FWIW, I don't believe Maven actually interprets the value of the maven.junit.fork property - it just detects that the property is set to anything. If maven.junit.fork=Christmas, then Maven will fork the JVM. :-) -Original Message- From: Vincent Massol To: 'Maven Users List' Sent: 12/20/2003 1:49 AM Subject: RE: Weird Clover Behavior Steve, More information for the record. What happens is the clover flushes data at JVM shutdown. Thus if your run your tests AND generate the report in one go (which is the behavior currently coded in the plugin unfortunately), Clover will not flush its data, leading to wrong statistics. Running the tests in a separate JVM (fork = true) will force the flush. There is a JIRA bug entry to fork by default. -Vincent -Original Message- From: Steve Garcia [mailto:[EMAIL PROTECTED] Sent: 20 December 2003 08:42 To: 'Maven Users List ' Subject: RE: Weird Clover Behavior I set maven.junit.fork = true and now I have classpath issues, java.lang.NoClassDefFoundError: org/w3c/dom/ranges/DocumentRange. Do I need to twiddle my dependencies tag? I put the xerces jar in my root classloader but that didn't help. But xerces-2.4.0.jar doesn't have org/w3c/dom/ranges/DocumentRange. I'm not even sure what artifact that is coming from. I'm running Java 1.4.2 ... hmm. jeez I'm tired. I can't even think straight. :( I have commons-lang, commons-logging, freemarker, junit, xerces, and hsqldb in my dependencies element. -Original Message- From: Jason van Zyl To: Maven Users List Sent: 12/19/2003 10:55 PM Subject: Re: Weird Clover Behavior On Sat, 2003-12-20 at 00:58, Steve Garcia wrote: The Clover report that gets produced from my code is totally off - I have close to 90% total coverage for my project and Clover is reporting only 8.5%. When I run maven clover manually the coverage numbers are closer to what they should be. But I still see weird behavior like a branch not being hit in my equals method when it obviously is. Anybody else see this kind of behavior? Basically if I do maven clean clover I get totally inaccurate coverage numbers. If I then invoke maven clover they are much closer to what they should be. You set: maven.junit.fork = true In order for clover to work correctly. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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]
Weird Clover Behavior
The Clover report that gets produced from my code is totally off - I have close to 90% total coverage for my project and Clover is reporting only 8.5%. When I run maven clover manually the coverage numbers are closer to what they should be. But I still see weird behavior like a branch not being hit in my equals method when it obviously is. Anybody else see this kind of behavior? Basically if I do maven clean clover I get totally inaccurate coverage numbers. If I then invoke maven clover they are much closer to what they should be. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Adding Maven dependencies to the System Classpath?
Hi there,
I am currently using Maven and am running into a bit
of a problem.
Using Maven, I unit test a piece of code that
leverages an implementation of
java.util.prefs.Preferences.
To do so, I set the java.util.prefs.PreferencesFactory
to my custom implementation. All of this resides under
my usual target/classes and target/test-classes.
The issue is that the Sun Preferences implemetation
uses:
try
{
factory = (PreferencesFactory)
Class.forName(factoryName, false,
ClassLoader.getSystemClassLoader()).newInstance();
}
Now, how do I get the Maven dependencies in the System
class loader.
You can specify an artifact to be loaded by the root (Maven) classloader by
adding the
propertiesclassloaderroot/classloader/properties at the same level
as your artifact dependency elements.
As anyone run in that problem before?
Regards,
David Le Strat.
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tasklist / vdoclet report exception
I found out what the problem was. I was somehow using a bad version of the
velocity-1.4-dev.jar artifact.
I found it strange that some of my Maven projects worked just fine and
others didn't. I've been managing different local artifact repositories so
I decided to swap out one for another and try generating site doco for my
projects. This is how I figured out that my velocity jar was bad.
FWIW, the bad velocity-1.4-dev.jar in my local repository is 368,352 bytes.
I replaced it with a good version of the velocity-1.4-dev.jar which is
359,924 bytes which is the same one up at ibiblio.org. I also had the MD5
hashes for both jars too (but I don't know if Maven validates artifact files
against their hashes.)
-- Steve
-Original Message-
From: Steve Garcia
Sent: Sunday, December 14, 2003 1:37 PM
To: ''Maven Users List' '
Subject: RE: Tasklist / vdoclet report exception
Hi, I tracked down this problem to a problem initializing the
VelocityEngine, specifically it is this line that is raising
the exception:
InputStream inputStream = getClass()
.getResourceAsStream('/' +
DEFAULT_RUNTIME_PROPERTIES);
configuration.load( inputStream );
where DEFAULT_RUNTIME_PROPERTIES =
org/apache/velocity/runtime/defaults/velocity.properties
I can create a simple project (one class and one test) and
Maven site:generate works fine. However with a big project,
I can't run that same goal because the code above doesn't work.
I'm still stuck, any advice?
-Original Message-
From: Steve Garcia
To: 'Maven Users List'
Sent: 12/13/2003 11:45 AM
Subject: Tasklist / vdoclet report exception
I'm running the site:generate goal on my project and my
tasklist report fails with the following exception (and
relevant stack trace info): Has anyone seen this error
before? Does anyone know how I can fix it?
I'm able to do other things like compile, test, javadoc, etc.
I have seen site:generation work in the past on other
projects I've used, but this is the largest one I've tried
mavenizing. I'm using Maven 1.0 rc1, and the plugin version
should be a part of the stack trace.
Thanks for your help.
[echo] Generating the Task List...
xdoc:init:
maven-tasklist-plugin:report:
[echo] Generating tasklist ...
BUILD FAILED
File.. file:/C:/Documents and
Settings/SGarcia/.maven/plugins/maven-vdoclet-pl
ugin-1.1-SNAPSHOT/
Element... vdoclet:vdocletBean
Line.. 21
Column 11
vdoclet.GeneratorException
com.werken.werkz.UnattainableGoalException: Unable to obtain
goal [site]
--
file:/
C:/Documents and
Settings/SGarcia/.maven/plugins/maven-vdoclet-plugin-1.1-SNAPSHOT
/:21:11: vdoclet:vdocletBean null
at com.werken.werkz.Goal.fire(Goal.java:646)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
[snip]
org.apache.commons.jelly.JellyTagException:
file:/C:/Documents and Settings/SGarci
a/.maven/plugins/maven-vdoclet-plugin-1.1-SNAPSHOT/:21:11:
vdoclet:vdocletBean n
ull
at
org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBean
Tag.java:
243)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScr
ipt.java:
145)
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)
[snip]
Caused by: vdoclet.GeneratorException
at vdoclet.Generator.initVelocityEngine(Generator.java:89)
at vdoclet.Generator.init(Generator.java:71)
at
org.apache.maven.vdoclet.VDocletBean.generate(VDocletBean.java:145)
at
org.apache.maven.vdoclet.VDocletBean.execute(VDocletBean.java:103)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[snip] Caused by: java.lang.NullPointerException
at java.io.Reader.init(Reader.java:61)
at java.io.InputStreamReader.init(InputStreamReader.java:55)
at
org.apache.commons.collections.ExtendedProperties.load(Unknown
Source)
at
org.apache.commons.collections.ExtendedProperties.load(Unknown
Source)
at
org.apache.velocity.runtime.RuntimeInstance.setDefaultProperti
es(Runtim
eInstance.java:356)
at
org.apache.velocity.runtime.RuntimeInstance.initializeProperti
es(Runtim
eInstance.java:481)
at
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstan
ce.java:2
63)
at
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstan
ce.java:4
99)
at
org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:144)
at vdoclet.Generator.initVelocityEngine(Generator.java:87
RE: Tasklist / vdoclet report exception
Hi, I tracked down this problem to a problem initializing the
VelocityEngine, specifically it is this line that is raising the exception:
InputStream inputStream = getClass()
.getResourceAsStream('/' + DEFAULT_RUNTIME_PROPERTIES);
configuration.load( inputStream );
where DEFAULT_RUNTIME_PROPERTIES =
org/apache/velocity/runtime/defaults/velocity.properties
I can create a simple project (one class and one test) and Maven
site:generate works fine. However with a big project, I can't run that same
goal because the code above doesn't work.
I'm still stuck, any advice?
-Original Message-
From: Steve Garcia
To: 'Maven Users List'
Sent: 12/13/2003 11:45 AM
Subject: Tasklist / vdoclet report exception
I'm running the site:generate goal on my project and my tasklist report
fails with the following exception (and relevant stack trace info): Has
anyone seen this error before? Does anyone know how I can fix it?
I'm able to do other things like compile, test, javadoc, etc. I have
seen
site:generation work in the past on other projects I've used, but this
is
the largest one I've tried mavenizing. I'm using Maven 1.0 rc1, and the
plugin version should be a part of the stack trace.
Thanks for your help.
[echo] Generating the Task List...
xdoc:init:
maven-tasklist-plugin:report:
[echo] Generating tasklist ...
BUILD FAILED
File.. file:/C:/Documents and
Settings/SGarcia/.maven/plugins/maven-vdoclet-pl
ugin-1.1-SNAPSHOT/
Element... vdoclet:vdocletBean
Line.. 21
Column 11
vdoclet.GeneratorException
com.werken.werkz.UnattainableGoalException: Unable to obtain goal [site]
--
file:/
C:/Documents and
Settings/SGarcia/.maven/plugins/maven-vdoclet-plugin-1.1-SNAPSHOT
/:21:11: vdoclet:vdocletBean null
at com.werken.werkz.Goal.fire(Goal.java:646)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
[snip]
org.apache.commons.jelly.JellyTagException: file:/C:/Documents and
Settings/SGarci
a/.maven/plugins/maven-vdoclet-plugin-1.1-SNAPSHOT/:21:11:
vdoclet:vdocletBean n
ull
at
org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:
243)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:
145)
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)
[snip]
Caused by: vdoclet.GeneratorException
at vdoclet.Generator.initVelocityEngine(Generator.java:89)
at vdoclet.Generator.init(Generator.java:71)
at
org.apache.maven.vdoclet.VDocletBean.generate(VDocletBean.java:145)
at
org.apache.maven.vdoclet.VDocletBean.execute(VDocletBean.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[snip]
Caused by: java.lang.NullPointerException
at java.io.Reader.init(Reader.java:61)
at java.io.InputStreamReader.init(InputStreamReader.java:55)
at
org.apache.commons.collections.ExtendedProperties.load(Unknown
Source)
at
org.apache.commons.collections.ExtendedProperties.load(Unknown
Source)
at
org.apache.velocity.runtime.RuntimeInstance.setDefaultProperties(Runtim
eInstance.java:356)
at
org.apache.velocity.runtime.RuntimeInstance.initializeProperties(Runtim
eInstance.java:481)
at
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:2
63)
at
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:4
99)
at
org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:144)
at vdoclet.Generator.initVelocityEngine(Generator.java:87)
... 59 more
Root cause
vdoclet.GeneratorException
at vdoclet.Generator.initVelocityEngine(Generator.java:89)
at vdoclet.Generator.init(Generator.java:71)
at
org.apache.maven.vdoclet.VDocletBean.generate(VDocletBean.java:145)
at
org.apache.maven.vdoclet.VDocletBean.execute(VDocletBean.java:103)
-
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]
Tasklist / vdoclet report exception
I'm running the site:generate goal on my project and my tasklist report fails with the following exception (and relevant stack trace info): Has anyone seen this error before? Does anyone know how I can fix it? I'm able to do other things like compile, test, javadoc, etc. I have seen site:generation work in the past on other projects I've used, but this is the largest one I've tried mavenizing. I'm using Maven 1.0 rc1, and the plugin version should be a part of the stack trace. Thanks for your help. [echo] Generating the Task List... xdoc:init: maven-tasklist-plugin:report: [echo] Generating tasklist ... BUILD FAILED File.. file:/C:/Documents and Settings/SGarcia/.maven/plugins/maven-vdoclet-pl ugin-1.1-SNAPSHOT/ Element... vdoclet:vdocletBean Line.. 21 Column 11 vdoclet.GeneratorException com.werken.werkz.UnattainableGoalException: Unable to obtain goal [site] -- file:/ C:/Documents and Settings/SGarcia/.maven/plugins/maven-vdoclet-plugin-1.1-SNAPSHOT /:21:11: vdoclet:vdocletBean null at com.werken.werkz.Goal.fire(Goal.java:646) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) [snip] org.apache.commons.jelly.JellyTagException: file:/C:/Documents and Settings/SGarci a/.maven/plugins/maven-vdoclet-plugin-1.1-SNAPSHOT/:21:11: vdoclet:vdocletBean n ull at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java: 243) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java: 145) 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) [snip] Caused by: vdoclet.GeneratorException at vdoclet.Generator.initVelocityEngine(Generator.java:89) at vdoclet.Generator.init(Generator.java:71) at org.apache.maven.vdoclet.VDocletBean.generate(VDocletBean.java:145) at org.apache.maven.vdoclet.VDocletBean.execute(VDocletBean.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [snip] Caused by: java.lang.NullPointerException at java.io.Reader.init(Reader.java:61) at java.io.InputStreamReader.init(InputStreamReader.java:55) at org.apache.commons.collections.ExtendedProperties.load(Unknown Source) at org.apache.commons.collections.ExtendedProperties.load(Unknown Source) at org.apache.velocity.runtime.RuntimeInstance.setDefaultProperties(Runtim eInstance.java:356) at org.apache.velocity.runtime.RuntimeInstance.initializeProperties(Runtim eInstance.java:481) at org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:2 63) at org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:4 99) at org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:144) at vdoclet.Generator.initVelocityEngine(Generator.java:87) ... 59 more Root cause vdoclet.GeneratorException at vdoclet.Generator.initVelocityEngine(Generator.java:89) at vdoclet.Generator.init(Generator.java:71) at org.apache.maven.vdoclet.VDocletBean.generate(VDocletBean.java:145) at org.apache.maven.vdoclet.VDocletBean.execute(VDocletBean.java:103) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
velocity:merge xdoc exception
In my previous email I mentioned an exception occuring in the tasklist plugin. I don't really need the tasklist plugin so I removed it from my POM report tag. Another site:generate run and I'm getting an error again with velocity, this time with the xdoc:generate-from-pom task. The exception and relevant stack info is below: I looks like I have an overall problem with Velocity but I'm not sure how to proceed. I'm running Maven 1.0 rc1. xdoc:generate-from-pom: [echo] Generating xdocs from POM ... BUILD FAILED File.. file:/C:/Documents and Settings/SGarcia/.maven/plugins/maven-xdoc-plugi n-1.4-SNAPSHOT/ Element... velocity:merge Line.. 393 Column 9 null:-1:-1: null null com.werken.werkz.UnattainableGoalException: Unable to obtain goal [site] -- file:/ C:/Documents and Settings/SGarcia/.maven/plugins/maven-xdoc-plugin-1.4-SNAPSHOT/:3 93:9: velocity:merge null:-1:-1: null null at com.werken.werkz.Goal.fire(Goal.java:646) at com.werken.werkz.Goal.attain(Goal.java:575) [snip] org.apache.commons.jelly.JellyTagException: file:/C:/Documents and Settings/SGarci a/.maven/plugins/maven-xdoc-plugin-1.4-SNAPSHOT/:393:9: velocity:merge null:-1:- 1: null null at org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag. java:242) at org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:108 ) 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.ForEachTag.doTag(ForEachTag.java:145 ) [snip] Caused by: org.apache.commons.jelly.JellyTagException: null:-1:-1: null null at org.apache.commons.jelly.tags.velocity.VelocityTagSupport.getVelocityEn gine(VelocityTagSupport.java:101) at org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag. java:226) ... 34 more Caused by: java.lang.NullPointerException at java.io.Reader.init(Reader.java:61) at java.io.InputStreamReader.init(InputStreamReader.java:55) at org.apache.commons.collections.ExtendedProperties.load(Unknown Source) at org.apache.commons.collections.ExtendedProperties.load(Unknown Source) at org.apache.velocity.runtime.RuntimeInstance.setDefaultProperties(Runtim eInstance.java:356) at org.apache.velocity.runtime.RuntimeInstance.initializeProperties(Runtim eInstance.java:481) at org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:2 63) at org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:118) at org.apache.commons.jelly.tags.velocity.VelocityTagSupport.getVelocityEn gine(VelocityTagSupport.java:98) ... 35 more Root cause org.apache.commons.jelly.JellyTagException: null:-1:-1: null null at org.apache.commons.jelly.tags.velocity.VelocityTagSupport.getVelocityEn gine(VelocityTagSupport.java:101) at org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag. java:226) at org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:108 ) 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) Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: location of generated source
It does seem like code generation is a more common strategy today than it
was a couple of years ago. Back in 2000 we never generated any code, but
tools today make it so easy to generate Java code. The Maven POM does
support a sourceModifications element which can alleviate some
frustration, and you can also (as mentioned below) modify the
maven.compile.src.dir property (or whatever it is) with the mavenAddPath Ant
Task.
I think it would be great if the POM somehow accomodated the notion of
generated source code directory.
I also remember one of the outstanding, low-priority tasks from the Maven
website was to introduce to the POM the notion of a sample application.
More compilable code that, in this case, is not part of the project source
tree but somewhere else. One could make little Maven projects, one per
sample application, and maybe that is the solution to take when POM
inheritance becomes a little more stable.
The single java source tree is an elegant solution but sometimes its
difficult to work with model.
-Original Message-
From: Kevin Hagel [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 1:42 PM
To: Maven Users List
Subject: Re: location of generated source
I agree completely. It would also be nice to see some documentation
regarding xdoclet settings in project.properties, how they map to values
that are used by xdoclet. If I hadn't been so busy trying to write an
xdoclet module myself, I would still be regularly lost on this.
maven.xdoclet.hibernatedoclet.0=true
maven.xdocelt.hibernatedoclet.0.fileset=blah
and so on. I actually find it easier to use ant taskdefs in my maven.xml,
rather than use the maven settings that the xdoclet plugin suggests.
Kevin
- Original Message -
From: Sonnek, Ryan [EMAIL PROTECTED]
To: 'Maven Users List' [EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 1:38 PM
Subject: RE: location of generated source
I'm in a similar situation in my project. Originally built using
mainly
BMP
entity beans, I'm at a point of reevaluation and thinking about
hibernate. I think for the time being I'll stick with the generated
classes in the target directory, and see if I need them saved in
CVS.
I can't think of many J2EE applications that aren't using xdoclet, so
maybe
it would be a good idea to put together a Best Practices guide for
this kind of thing? I'm sure there are several people using maven
that have these same questions. I think maven does a great job at
handling it, but with several different options, a short HOWTO might
be beneficial to
newbies
(and the not so newbielike myself).
Ryan
-Original Message-
From: Kevin Hagel [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 3:28 PM
To: Maven Users List
Subject: Re: location of generated source
I haven't dealt with XDoclet and EJBs much beyond experimentation.
I'm staying away from entity beans anyway, since I'm using hibernate.
when
the
project gets to the point where I want remote access, I'm plan to use
Stateless Session Beans only.
I mostly use it right now for hibernate and jmx/jboss stuff, and I'm
busy trying to write a module for handling springframework stuff.
I can suggest an experiment maybe ...? do a touch *.* and run
xdoclet,
then
run it again ...?
- Original Message -
From: Sonnek, Ryan [EMAIL PROTECTED]
To: 'Maven Users List' [EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 1:27 PM
Subject: RE: location of generated source
Thanks for the response.
Do you find the build to be fast enough for doing incremental
builds? I mean, even if xdoclet doesn't generate the files in
question, does the timestamp check take unnecessarily long? The
reason I was thinking of taking my generated files out of
'target/xdoclet', was because the interfaces and utility classes it
generates are so rarely updated, that
the
constant refreshing of the classes becomes tedious. How large is
your project and what do you use xdoclet for (entity and session
ejbs,
taglibs)?
Thanks again.
Ryan
-Original Message-
From: Kevin Hagel [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 3:18 PM
To: Maven Users List
Subject: Re: location of generated source
I always put XDoclet-generated files in
target/xdoclet/hibernatedoclet, target/xdoclet/springdoclet, that
kind of thing. Isn't it true that XDoclet won't bother re-creating
your generated
classes
if the timestamps on the source and destination files match? I mean
is there a force=false kind of setting or something?
You can also set
maven -DdoXDoclet=true
on the command line and just
j:if test=${doXDoclet == 'true'}
xdoclet things
copy xdoclet-generated source over to src/java... /j:if
- Original Message -
From: Sonnek, Ryan [EMAIL PROTECTED]
To: 'Maven Users List' [EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 8:07 AM
Subject: location
xdoc plugin
I'm getting a NullPointerException with the xDoc plugin. I'm not sure how to address this. The relevant debug info is: C:\source\itm\main\mavenmaven -X xdoc __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT ... maven-jxr-plugin:register: xdoc:generate-from-pom: [echo] Generating xdocs from POM ... BUILD FAILED File.. file:/C:/Documents and Settings/SGarcia/.maven/plugins/maven-xdoc-plugi n-1.4-SNAPSHOT/ Element... velocity:merge Line.. 393 Column 9 null:-1:-1: null null com.werken.werkz.UnattainableGoalException: Unable to obtain goal [xdoc:generate-f rom-pom] -- file:/C:/Documents and Settings/SGarcia/.maven/plugins/maven-xdoc-plug in-1.4-SNAPSHOT/:393:9: velocity:merge null:-1:-1: null null at com.werken.werkz.Goal.fire(Goal.java:646) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:44 [snip] org.apache.commons.jelly.JellyTagException: file:/C:/Documents and Settings/SGarci a/.maven/plugins/maven-xdoc-plugin-1.4-SNAPSHOT/:393:9: velocity:merge null:-1:- 1: null null at org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag. java:242) at org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:108 ) 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.ForEachTag.doTag(ForEachTag.java:145 ) 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) [snip] org.apache.commons.jelly.JellyTagException: file:/C:/Documents and Settings/SGarci a/.maven/plugins/maven-xdoc-plugin-1.4-SNAPSHOT/:393:9: velocity:merge null:-1:- 1: null null at org.apache.commons.jelly.tags.velocity.MergeTag.mergeTemplate(MergeTag. java:242) at org.apache.commons.jelly.tags.velocity.MergeTag.doTag(MergeTag.java:108 ) 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.ForEachTag.doTag(ForEachTag.java:145 ) 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) Does anybody have any advice? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: how to use Hibernate in Maven?
XDoclet does have a hibernate javadoc tag library to easily make the Hibernate O/R mapping files. -Original Message- From: Konstantin Priblouda [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 2:59 AM To: Maven Users List; Eric Chow Subject: Re: how to use Hibernate in Maven? --- Eric Chow [EMAIL PROTECTED] wrote: Hi, Thank you for your reply. I am now can use Hibernate in Maven now. Another question, how can I generate hibernate.cfg.xml with Maven ??? Does xdoclet generates this? ( never used it to do that ) If yes - just activate subtask. I use property bases configuration + DAO class... Handmade :) regards, = [ Konstantin Pribluda ( ko5tik ) ] Zu Verstärkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] für die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich [ http://www.pribluda.de ] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - 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: Finding artifact dependencies
I (for one) would love to see a feature like this. This would as cool, perhaps even cooler, than the existing artifact dependency feature Maven has so elegantly employed. I presume that this would require that each individual project deploy meta-data about what their dependencies are...wait that is the POM! :-) Maybe distributing the POM, or a POM like structure, with each artifact that is installed in the remote repository? That will work with projects that use Maven to build, but it won't work nicely for non Maven software. How do I found out what the dependencies for a given artifact are? Example: I can place a dependency on struts-1.1 in project.xml, which will be fine for compilation, but to deploy an app using this I need a whole bunch of stuff that struts depends on, and I can't see any thing under struts on ibiblio that tells me what jars and versions I need. It seems the only way to find this out is to download struts from apache look at what's inside and fill in a bunch of dependencies. Would it not be sensible to have every artifact in ibiblio define its dependencies (within ibiblio) and have maven resolve the lot - else its just a big collection of versioned jars - So when the next version of struts is out I have to make sure I update every dependency in project.xml again. Is this the case? Cheers Kevin - 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]
Source XRef Double Spacing
My source xref javadoc-style documentation is double-spaced so to speak, in the left upper and lower frame. I would like to have it single-spaced like the normal Javadoc frameset HTML files. How do I do that? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Trying to include j2ee.jar
I'm very new to maven and I'm trying to figure out how
to include j2ee.jar as a dependency.
Is it possible to do a file:// in the URL, like so:
dependency
idj2ee/id
urlfile:///c:\\java\\j2sdkee1.3.1\\lib\\j2ee.jar/url
jarj2ee.jar/jar
/dependency
You should put your j2ee.jar into your local repository, and if you have a
central repository at your workplace you should add it there (if
applicable).
I would also rename that jar and add the version to it too...like
j2ee-1.2.jar (or whatever the version is).
Once you put it into your local repository, and add it to your dependency
list, then it will always be used in your classpath.
Alternatively you can override it's location by adding a specific path in
one of your .properties files (build.properties, project.properties,
${user.home}/build.properties).
The specific information on how to do this is documented on Maven's website
at
http://maven.apache.org/reference/user-guide.html#Overriding%20Stated%20Depe
ndencies
-- Steve
Something tells me I'm going about this completely the
wrong way. Do I need to set up a j2ee directory in
my local repository?
Steve
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Source code analyzer for unused method detection?
We use Clover (and there is a plugin for it last time I checked) which gives you a bunch of statistics (method completion, statement completion, and conditional completion) on code coverage in your source directory. These statistics are bsed on your unit test coverage. -Original Message- From: Tim Anderson To: Maven Users List Sent: 10/5/2003 5:04 AM Subject: RE: Source code analyzer for unused method detection? The results wouldn't be all that meaningful on reusable components, but at the application level, it would be useful to detect cruft. -Tim -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Sunday, 5 October 2003 6:09 PM To: 'Maven Users List' Subject: RE: Source code analyzer for unused method detection? Hi Tim, How do you know a public method is not used by external code? -Vincent -Original Message- From: Tim Anderson [mailto:[EMAIL PROTECTED] Sent: 05 October 2003 07:48 To: Maven Users List Subject: Source code analyzer for unused method detection? Hi, does anyone know of a code analyzer which can detect unused methods? The PMD plugin only reports on unused private methods - I'm looking for one which can also do public or protected methods. Thanks, Tim - 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]
RE: Source code analyzer for unused method detection?
Clover actually reports on all method/statement/conditional level usage in your code. You first have to instrument your code and all that means is running your source through the Clover filter which adds clover java lines after every statement in your class. Then when you run your units against that instrumented code a small clover database is updated with statistics on which statements were hit. I think it's a great product and raises the quality of my unit tests. -Original Message- From: Siegfried Goeschl To: Maven Users List Sent: 10/5/2003 8:42 AM Subject: Re: Source code analyzer for unused method detection? Oops, considering dynamic class loading and reflection it is actually impossible ... Cheers, Siegfried Goeschl On Sunday 05 October 2003 17:27, Siegfried Goeschl wrote: It is actually not easy to detect an unused method due inheritance and polymorphism since the class of the instance you use is determined at runtime. If you have some time to spend you can either search the web (there are many static source code analyzers out there and tell us your findings!!) or use a code profiler such as CLOVER or JProbe . Cheers, Siegfried Goeschl On Sunday 05 October 2003 14:04, Tim Anderson wrote: The results wouldn't be all that meaningful on reusable components, but at the application level, it would be useful to detect cruft. -Tim -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Sunday, 5 October 2003 6:09 PM To: 'Maven Users List' Subject: RE: Source code analyzer for unused method detection? Hi Tim, How do you know a public method is not used by external code? -Vincent -Original Message- From: Tim Anderson [mailto:[EMAIL PROTECTED] Sent: 05 October 2003 07:48 To: Maven Users List Subject: Source code analyzer for unused method detection? Hi, does anyone know of a code analyzer which can detect unused methods? The PMD plugin only reports on unused private methods - I'm looking for one which can also do public or protected methods. Thanks, Tim - 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] - 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: Beginner's question about reactor
Hi Brian - the way I used Maven reactor is similar to the way you have it. I have a few sub projects and the main project is just a shell which executes the sub projects. Based on the dependencies, the sub projects are executed in the right order (that is so cool). In your case I'm not sure if you can specify more filters in your reactor tag for includes and excludes to get only the projects you want done. Say if you have 5 projects (A, B, C, D, E) and project A depends on artifacts from B, and C, in your outer maven empty project I think you can write the maven:reactor tag to point to project A, and exclude any project.xml's found in the path to project D and E. I haven't tried that myself but it's worth trying. Hope this helps, Steve -Original Message- From: Hartin, Brian [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 1:46 PM To: '[EMAIL PROTECTED]' Subject: Beginner's question about reactor I've just started using Maven and I'm having trouble with multiproject builds using reactor. Suppose I don't have a main project with subprojects, but rather a set of projects and dependencies between them, and I want to be able to build a particular project, recursively building its dependencies if necessary? The examples I've seen have all assumed that we have a 'main' project, with no dependencies in its project.xml file, and that it's got a goal in maven.xml which uses the reactor to build all its subprojects in the correct order. Can this be accomplished? Thanks, Brian Hartin NCS Pearson Iowa City, IA USA A ship in harbor is safe, but that is not what ships are built for. - John Shedd http://www.digitalconsumer.org/bill.html This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. - 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: Beginner's question about reactor
Yea you basically got it right. However I was under the impression that when you specify the include and exclude tags of the maven:reactor tag it would 1) first find all project.xml files according to the fileset and exclude the ones that match your exclude pattern and 2) work out which projects to compile first based on the project.xml dependencies. I think what you are asking for should be reasonable, however it's not in. Suppose I have a single maven project and it requires the Log4J jar file and some jar file called projectB-1.0.jar. All maven would do is try to download the projectB artifact from the maven.repo.local, and if that failed it would to go a remote repository. If that failed the compile goal fails. I think what you want is for Maven to recognize that the projectB-1.0.jar is actually an artifact that can be produced by some other maven project, and have it find that project.xml and compile/jar:install that jar into the maven.repo.local repository. How would maven know that projectB is an artifact that can be produced on your system and not a normal one that can be downloaded? At this point I'm not sure. I don't think that is in there. Perhaps it's reasonable to say Maven, compile the buildA project and if it has any dependencies first look at the other project.xml files in this fileset to see if any other project can build that artifact. If not then go to the repository. Right now, if you use the maven:reactor does it build all projects (A, B, C, D, E) even if you only want to build A and it's dependencies, in this case B and C? I guess it still builds D and E. -Original Message- From: Hartin, Brian [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 2:13 PM To: 'Maven Users List' Subject: RE: Beginner's question about reactor If I understand correctly, you're suggesting that I create main project with no dependencies, and for the case of project A, a 'buildA' goal in the main project's maven.xml file. In that goal's reactor tag I would exclude projects that A doesn't depend on. I did try this approach, but rejected it because: a) A's dependency information is already in it's project XML file. It doesn't seem right to express it yet again in a 'fake' main project's build file. b) If A depends on B and C, shouldn't A's build be ignorant of what B and C depend on, and defer to their project.xml files for that? If so, then we can't exclude anything in the 'buildA' tag. I wonder if there's a way to write a maven.xml file for project A that will build project A, and everything in its dependency graph, in the proper order. The only problem seems to be that Maven can't get past the fact that A has dependencies, so the reactor never does its work. I wonder why this is? It would seem trivial to ignore the dependencies until after the reactor has done its thing. Any ideas? -Original Message- From: Steve Garcia [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 3:52 PM To: 'Maven Users List' Subject: RE: Beginner's question about reactor Hi Brian - the way I used Maven reactor is similar to the way you have it. I have a few sub projects and the main project is just a shell which executes the sub projects. Based on the dependencies, the sub projects are executed in the right order (that is so cool). In your case I'm not sure if you can specify more filters in your reactor tag for includes and excludes to get only the projects you want done. Say if you have 5 projects (A, B, C, D, E) and project A depends on artifacts from B, and C, in your outer maven empty project I think you can write the maven:reactor tag to point to project A, and exclude any project.xml's found in the path to project D and E. I haven't tried that myself but it's worth trying. Hope this helps, Steve -Original Message- From: Hartin, Brian [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 1:46 PM To: '[EMAIL PROTECTED]' Subject: Beginner's question about reactor I've just started using Maven and I'm having trouble with multiproject builds using reactor. Suppose I don't have a main project with subprojects, but rather a set of projects and dependencies between them, and I want to be able to build a particular project, recursively building its dependencies if necessary? The examples I've seen have all assumed that we have a 'main' project, with no dependencies in its project.xml file, and that it's got a goal in maven.xml which uses the reactor to build all its subprojects in the correct order. Can this be accomplished? Thanks, Brian Hartin NCS Pearson Iowa City, IA USA A ship in harbor is safe, but that is not what ships are built for. - John Shedd http://www.digitalconsumer.org/bill.html ** ** This email may
RE: AW: Maven book and user input
For what it's worth, I think these are all legitimate, good reasons. Especially the point that experienced writers can communicate much better than most other people who don't write (like me.) I understand that it can be an enjoyable experience, and I look forward to seeing the book. The only thing I wanted to say is often I don't have books with me while I'm doing coding, especially at work. I do use the Internet all the time to lookup Javadoc, find examples, etc. For instance there are Struts books (even from O'Reilly) but because I don't have that book with me at all times I usually do searches to find out the info I need. If there were only books and no online documentation for Hibernate, XDoclet, Ant, and numerous other libraries, I would probably be frustrated and out hundreds of dollars in book fees. :) Books are great for communicating theories and ideas, best practices, strategies, etc. For instance I carry around Effective Java by Joshua Bloch every where I go. I find that book to be one of the best, if not the best, overall Java programming books for advanced Java developers. At one point I did buy Java in a Nutshell but I don't use it because all of the info can be found on the web. On Wed, 2003-10-01 at 04:46, Roland Berger wrote: It is only fair that contributors and commiters can get a pay back for the great work they do in their free time. Is it by writting a book or by providing some consulting work. Right, I see writing the book as pleasurable experience. It will certainly be hard work but I think it will be enjoyable. And it's certainly for the recognition that I write the book, I can't speak for Bob. It's not going to be a money making endeavour and we're not writing it to make money. I also have enough work to keep me busy 'til the end of time (or longer) so I doubt I'll be doing much other work as a result of the book. To me I hope for the book to be a labour of love. When I use open source software I usually buy the book when it is written by one of the contributors or commiters. And one of the reasons I buy them is to honor the work they have done. 30U$ really is not much. And it just supports OSS in general which I personally think is always good. Which is why I am happy O'Reilly is involved. They are staunch supporters of OSS and realize what most of us are like and are adept at working with my kind i.e. very difficult to work with most likely :-) You should go over to Prentice Hall, they are very open to publishing free e copies. If you go over to Manning Publications they usually offer an electronic version to a lower price bevor the hard copy is available. Also they submit some of the core chapters for public review to www.theserverside.com like they do currently for JSF in Action (http://www.theserverside.com/resources/JSFInA ctionReview.jsp). Since it will take a long time to finish the book it would be great to make some chapters available for the public to review bevor it is finished. I'm hoping to at least get some chapters out for viewing but I don't know what will be possible yet insofar as electronic pre-releases. I would like to because it will only make the book better and think it would actually help to sell more hard copies. With Thinking in Java I bought the hard copy not only because it was an excellent primer but I respected the fact that the author made the book available in electronic form for people who might not have 40 bucks to spend on a book, or people who would rather not chew up a tree and for that reason I bought the book. Cheers Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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 book and user input
Will the book provide documentation in addition to (hopefully) the 1.0 final documentation that will get updated at maven.apache.org? Or will the book contain a substantial amount of documentation that cannot be found on the web? I myself would like to see a complete Maven documentation effort be released on the maven website, much like Ant's documentation is all on the website. I'm not sure spending between $30 and $40 for the Maven book for documentation would be something that the masses want. Are you volunteering to write that documetation ? If not your aren't speaking for the masses, just yourself. I feel very luck that publishing companies are willing to write books on Maven. $30-$40 dollars is a very very small price to pay for a good book ! And the software is thrown in for free. !!! Well, I was, prima facie, just speaking for myself. At a very high level I'm not sure how Maven's value proposition is any different from other OSS that provide tools for software development. Ant, XDoclet, Hibernate are some examples of advanced complicated libraries that have their documentation online. And it's good documentation too (XDoclet uses Maven! :). Unless it's a mechanism for making money, which in-of-itself is not a bad thing at all. I'm all for folks making as much money as they can. Why does Maven's product necessitate documentation in book form when other advanced tools and API's can be satisfactorily summed up online? I have actually tackled some of the Maven documentation, I started writing an outline of what I think would be good information. The problem is I'm developing it from looking at the Maven source, and sometimes I can't explain why a particular idiom was used. The source itself is not well documented and rationales for design patterns (which are not usually put in the source) are mostly in people's head. Complete documentation, with the general specificity that Ant provides, would be sufficient for me, and I probably speak for the majority of Maven users. Would the book target the Maven 1.0 release? Or the Maven 2.0 release? (or the Maven-New 1.0 release?) - 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 book and user input
On Tue, 2003-09-30 at 16:03, Steve Garcia wrote: Will the book provide documentation in addition to (hopefully) the 1.0 final documentation that will get updated at maven.apache.org? Or will the book contain a substantial amount of documentation that cannot be found on the web? It will more than likely be information that can't be found on the web. I would like to release an electronic copy of the book for free but I don't think I'll be able to swing that. I myself would like to see a complete Maven documentation effort be released on the maven website, much like Ant's documentation is all on the website. Publishers are not really into giving away the content of books they intend to sell. I think it could work in their favour much like it did for Bruce Eckel's books but the decision is not ultimately up to me. I can only ask that an electronic copy be put on the web at no cost. Yea. That makes complete sense. I'm not sure spending between $30 and $40 for the Maven book for documentation would be something that the masses want. That why publishers try to do a little market research. The book won't be printed unless they can expect to sell a reasonable number of copies, say 10k copies. I have heard that is usually the minimum number of copies that must be sold in order for a book to be published. Complete documentation, with the general specificity that Ant provides, would be sufficient for me, and I probably speak for the majority of Maven users. Would the book target the Maven 1.0 release? Or the Maven 2.0 release? (or the Maven-New 1.0 release?) I'm shooting for the new version and you have to remember it can take quite a bit of time to write a book. Even with two people. It could take more than a year (and it most likely will.) Maven is still evolving, right? It seems reaonable to assume that in 12-18 months enough changes will have been put into Maven that writing a book, that is accurate, might make it even that more challenging. I can see a time when core Maven really doesn't change and the only thing that evolves are the plugins. In that case having a book, or online documentation, for core Maven would be excellent. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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: Specifying a CVS password (.cvspass?)
You can set the password property (or any for that matter) at the command line with the -D option which sets the system property. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2003 9:08 PM To: Maven Users List Subject: RE: Specifying a CVS password (.cvspass?) Jason Horne [EMAIL PROTECTED] wrote on 27/09/2003 02:05:57 PM: Well, yup, that worked. But... is that a workaround? It seems like the changelog plugin (or whichever component is accessing CVS) should know how to log in properly using a password, like Ant. This solution requires that the user have cvs installed locally. (Right?) Thanks for the tip. Ant requires you to have CVS installed to use the ant tasks too. I'm really against storing CVS (or any other password) in properties or project.xml. Can we find a way to do this that doesn't require this? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - 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: Combining ant and maven (was (Fwd) Re: Corporate constructive criticism)
There is... org.apache.maven.ant.MavenTask There is an existing version of it in the maven.jar, and there is a patch for it in JIRA that I don't think has been applied yet (it improves on the existing archaic task.) Should help you out. -- Steve -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2003 2:07 PM To: Maven Users List Subject: Re: Combining ant and maven (was (Fwd) Re: Corporate constructive criticism) Yes, on reflection I realised that a combination of tools could do the job. I can successfully do - java:compile - jar:install - site:deploy so I will get benefits from maven. It seems to be the distribution and release steps where I hit the really hard problems. So, question to maven guys - is there a maven ant task? Stephen - Original Message - From: Joakim Erdfelt [EMAIL PROTECTED] Siegfried Göschl wrote: There is a third option - I just integrated MAVEN into an existing ANT build environment without giving up the large existing build (400 KByte of ANT scripts) and more than 100 subprojects. Basically I reap the report generation of MAVEN and everything else is done by the existing ANT build plus a few more ANT scripts for invoking MAVEN. The setup is not for the faint hearted but there was no other way doing it with the given timeframe of two weeks. Do you have any Best Practices or Lessons Learned type tips for this kind of hybrid setup? We are also in the process of moving a large corporate project into maven, and would greatly benefit from the lesson's learned in your setup. /* joakim */ - 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: Multiple Source Paths
Steve Garcia wrote: Yup, I feared that almost all of Maven's plugins rely on a single source directory. It is a conscious design decision, not an unintended mis-feature. I understand this is an intended feature. I guess another solution is to move all of the source to a single temp directory before any plugins are executed. Yet another one, but much more Mavenish is to break down your project into multiple smaller projects connected with a network of dependencies. Each of these will have a directory for sources and tests. Yes...and I am looking into this right now. I might prefer this solution because then each component owner can maintain their own documentation, unit tests, etc. All nice and pretty. I know that this approach may not be easy to adopt for certain projects especially in corporate enviroments. The end goal of our product is to deploy two jar files, one containing our core platform and the other containing our dependencies. By breaking up our components into little subprojects, there has to be a way of delivering our product as it always has. Maybe UberJar is our answer for combining all of the sub projects, maybe I have to write our own maven plugin. Are there any suggestions or enhancement requests to require plugins to handle multiple source directories? If that can be a requirement, then this idea wouldn't seem difficult to deal with. Proposals to enhance plugins in this way are very unlikely to be accepted (see above). Here is my thought - in the end the maven.compile.src.set path is represented as an Ant-like path structure. maven.compile.src.set can contain one path, 2 paths, perhaps 35 paths. Plugins do use maven.compile.src.set so it would seem sensible that if each plugin cannot support a path like structure to do it's task, then it should iterate through every path in maven.compile.src.set and do it's work. Therefore the javadoc plugin, for example, would definitely work without the hack I put in. Does this seem sensible? With jelly scripting, it looks easy to write a for loop and go through each path and do something. I understand that Maven emphasizes a single directory for source, but because plugins handle everything it seems reasonable that They receive an array of source paths and iterate through each one. R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple Source Paths
Yet another one, but much more Mavenish is to break down your project into multiple smaller projects connected with a network of dependencies. Each of these will have a directory for sources and tests. Yes...and I am looking into this right now. I might prefer this solution because then each component owner can maintain their own documentation, unit tests, etc. All nice and pretty. I know that this approach may not be easy to adopt for certain projects especially in corporate enviroments. The end goal of our product is to deploy two jar files, one containing our core platform and the other containing our dependencies. By breaking up our components into little subprojects, there has to be a way of delivering our product as it always has. Maybe UberJar is our answer for combining all of the sub projects, maybe I have to write our own maven plugin. Re: multiple projects...does Maven package (or better yet re-generate) the javadoc from multiple projects into one big javadoc package? For example...there is a 1-1 relationship between project and javadoc. If I break up the project to 3 subprojects Maven can produce three javadocs for each subproject (and three jar files, etc.) Maven can produce an uberjar for those three subprojects, which I presume has the same contents as the jar file from the original master project. Can Maven also produce a master set of javadoc documentation from the 3 subprojects? If so point me in the right direction and I'll take it from there! Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Reactor Idiosyncracies
I've had some good luck integrating Maven Reactor with my product. In this
process I've come up with a few questions (I couldn't find answers in the
Wiki):
I have
project.xml
maven.xml
|
--Project A (project.xml, maven.xml)
|
--Project B (project.xml, maven.xml)
|
--Project C (project.xml, maven.xml)
The root project and maven xml files just kickoff reactor to build
Project A, B, and C. There is no source for the root project.
1) in my root maven.xml file I declare a property
property name=projects.base.dir value=${basedir}/projects /
echoprojects.base.dir = ${projects.base.dir}/echo
When the reactor runs I get different paths echoed to the screen. Each
one is based on the Project A, B, and C. I don't want that, I want
to persist my projects.base.dir and make it sticky. Can I do that?
I guess for Project A, B, and C, Maven generates the environment
properties based on merging the project and maven files, so child
elements take precedent over parent elements. I think that is right.
Can I make some parent elements not-overridable? Is each invocation
of the project.xml file create some local stack of environment
variables?
2) in my root maven.xml file I declare two goals platform:clean and
platform:compile. The first goal uses maven:reactor to clean each
subproject e.g. and only calls the clean goal
goal name=platform:clean
maven:reactor
basedir=${projects.base.dir}
includes=**/project.xml
goals=clean
banner=Cleaning
ignoreFailures=false/
/goal
my other goal platform:compile compiles each project and I want it to
first call platform:clean but fails and says Unable to attain goal
[platform:clean].
goal name=platform:compile
maven:reactor
basedir=${projects.base.dir}
includes=**/project.xml
goals=platform:clean, java:compile
banner=Generating
ignoreFailures=false/
/goal
Are we not allowed to chain custom goals like this?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiple Source Paths
Yup, I feared that almost all of Maven's plugins rely on a single source directory. I guess another solution is to move all of the source to a single temp directory before any plugins are executed. Are there any suggestions or enhancement requests to require plugins to handle multiple source directories? If that can be a requirement, then this idea wouldn't seem difficult to deal with. Thanks, Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 4:18 PM To: Maven Users List Subject: Re: Multiple Source Paths Steve Garcia [EMAIL PROTECTED] wrote on 24/09/2003 08:12:32 AM: I am mavenizing my application we use at work. I believe I've made a good attempt to solve my problem by reading through the Maven archives and and the MavenWiki site. But I still encountering problems. My application at work has several source directories, both for our application source and our unittest source. I am trying to get all of the standard Maven reports to run (correctly) and some of them fail, even after modifying their jelly.plugins file. I used maven:addPath to build up my source tree, and it basically works. However the maven:addPath goals are attained in my java:compile preGoal tag, and I really want those addPath declarations to occur *anytime* maven does any goal. I want to force maven to build these paths for any task, so all plugins are consistently using the same maven.compile.src.set property. For instance maven javadoc only goes against the first dir I specified, not my complete fileset. Almost all of Maven assumes a SINGLE source directory. Is there a way to specify some script for any goal? Like before doing any maven goal, execute this goal and the specified goal I would build up my maven.compile.src.set and maven.test.compile.src.set path ids. Put it in maven.xml outside of a goal. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - 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: adding a path to maven.compile.src.set
I just asked this two messages ago... You can use maven:addPath to do your work. Check out the MavenWiki website (linked from maven.apache.org) -Original Message- From: Nathan Coast [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 6:27 PM To: maven users Subject: adding a path to maven.compile.src.set Hi, Is there any way to add a path to the maven.compile.src.set? I have sources that are used to generate other sources (using ejbgen - like xdoclet). At the moment I'm generating the sources into the same place as the original source and then compiling. I'd like to keep my generated sources away from the 'real' source but still be able to compile them together. Ideally I'd like to be able to add to the maven.compile.src.set in one plugin then call the java:compile goal. I guess the alternative would be to copy the java:compile goal into my plugin and add the appropriate dir to the ant:src set. thanks Nathan - 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: adding a path to maven.compile.src.set
I don't see why not. My maven:addPath declarations are outside of the
goal tag so all goals see the changes (although this may not be what you are
looking for.)
-Original Message-
From: Nathan Coast [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2003 6:59 PM
To: Maven Users List
Subject: Re: adding a path to maven.compile.src.set
can this be used within a plugin?
goal ..
ant:path
id=my.other.src.dir
location=${basedir}/debug/src/
maven:addPath
id=maven.compile.src.set
refid=my.other.src.dir/
attainGoal name=java:compile/
/goal
Brett Porter wrote:
There is a question in the FAQ about this... Have you had a look there
yet?
Cheers,
Brett
-Original Message-
From: Nathan Coast [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 24 September 2003 11:27 AM
To: maven users
Subject: adding a path to maven.compile.src.set
Hi,
Is there any way to add a path to the maven.compile.src.set?
I have sources
that are used to generate other sources (using ejbgen - like
xdoclet). At the
moment I'm generating the sources into the same place as the
original source and
then compiling. I'd like to keep my generated sources away
from the 'real'
source but still be able to compile them together. Ideally
I'd like to be able
to add to the maven.compile.src.set in one plugin then call
the java:compile
goal. I guess the alternative would be to copy the
java:compile goal into my
plugin and add the appropriate dir to the ant:src set.
thanks
Nathan
-
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]
Link Checker Plugin
Hi, right before the my site is generated I get something like this... Setting project: Media Publisher Express, v1.0 Received: [301] for http://java.sun.com/cgi-bin/bugreport.cgi Received: [301] for http://java.sun.com/products/jdk/1.3/devdocs-vs-specs.html Received: [404] for http://www.omg.org/corba/corbiiop.htm Received: [404] for http://www.omg.org/pub/docs/formal/97-12-10.ps Received: [404] for http://www.omg.org/pub/docs/formal/97-12-10.pdf Received: [302] for http://www.awl.com/cp/javaseries/jcl1_2.html Received: [301] for http://java.sun.com/doc/books/tutorial/uiswing/components/menu.ht ml Received: [301] for http://java.sun.com/products/jfc/swingdoc-archive/mixing.html Received: [301] for http://java.sun.com/Series/Tutorial/index.html . . . Received: [301] for http://java.sun.com/docs/books/tutorial/post1.0/ui/textlistener.h tml Received: [301] for http://java.sun.com/docs/books/tutorial/post1.0/ui/windowlistener .html Received: [301] for http://java.sun.com/docs/books/tutorial/post1.0/ui/componentliste ner.html Received: [301] for http://java.sun.com/docs/books/tutorial/post1.0/ui/eventmodel.htm l maven-linkcheck-plugin:report-real: xdoc:performJSL: [echo] Generating C:/java/mpexpress/target/docs/linkcheck.html from C:\java\mpexp ress\target\linkcheck\docs\linkcheck.xml BUILD SUCCESSFUL Total time: 29 minutes 17 seconds C:\java\mpexpress I was under the impression that I could remove the link check report by removing it from my project.xml reports element. It currently looks like reports reportmaven-checkstyle-plugin/report reportmaven-javadoc-plugin/report reportmaven-jdepend-plugin/report reportmaven-junit-report-plugin/report reportmaven-tasklist-plugin/report /reports Yet the link checker still runs. And I do NOT want it to run, because as you can see it takes almost 30 minutes for it to complete. (I have the j2se javadoc, it's validating all the links in that). How can I prevent the link checker from running? I understand that I could also remove the javadocs from the appropriate directory (but I like it being there). Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to add classpath to JUnit Tests
Although in the case of my previous question I think the manual is straight forward. On this topic in general, I am confused about some things in the manual. For instance does Maven support the unitTest and unitTestPatterns elements in the build node? I'm playing around with it now to see if there is a difference. Regards, Steve -Original Message- From: Steve Garcia Sent: Friday, May 30, 2003 10:30 AM To: Maven Users List Subject: RE: How to add classpath to JUnit Tests I have read the user manual, but I have found inconsistencies with it in the past so I'm a little hesistant to completely trust it. Thanks, Steve -Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 10:29 AM To: Maven Users List Subject: RE: How to add classpath to JUnit Tests It is usually good idea to read manual (User Guide): http://maven.apache.org/reference/user-guide.html#Test%20Resources Michal -Original Message- From: Steve Garcia [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 7:12 PM To: Maven Mailing List (E-mail) Subject: How to add classpath to JUnit Tests I wish to add additional classpath entries when I run maven test because there are additional resources that must be present in the classpath. For instance I am generating test cases that test ResourceBundles, so I need the .properties files in the classpath. How can I accomplish this? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Wizyta Busha w INTERIA.PL http://link.interia.pl/f172d - 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]
