Re: Problem dynamically excluding some tests
Thank everyone for the suggestions, they are all great ideas. Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem dynamically excluding some tests
That didnt work either, I think I will just stick with the build.props.
Thanks away,
-CS
On Fri, 3 Dec 2004 10:55:15 +0100, Jörg Schaible
<[EMAIL PROTECTED]> wrote:
> Corey Scott wrote on Friday, December 03, 2004 8:25 AM:
> [snip]
>
>
> > Extract from my maven.xml:
> >
> >
> > > test="${systemScope['os.name'].startsWith('Windows')}">
> > Including MsAccess(ODBC) Tests > name="test.extra.excludes" value="**/*MsAccess*.java"/>
> >
> >
> > Excluding MsAccess(ODBC) Tests
> >> value="FaKecLaSs.java"/>
> >
> >
> >
>
> These are not ant properties. Set them for the JellyContext. Use j:set
> (assuming you have bound J to jelly:core).
>
> - Jörg
>
> -
>
>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem dynamically excluding some tests
Yeah, that is what I had expected.
I was trying not to use build.props to make it auto-detect but it
looks like I will have to.
Thanks,
Corey
On Fri, 3 Dec 2004 09:38:18 +0200, Florin Vancea <[EMAIL PROTECTED]> wrote:
> I'm no expert but I believe project.xml is already parsed when you get to
> maven.xml. Therefore it's useless to change that property within maven.xml.
> Maybe you can use build.properties to specify test.extra.excludes and
> configure different build.properties on different machines.
>
> Florin
>
>
>
> ----- Original Message -
> From: "Corey Scott" <[EMAIL PROTECTED]>
> To: "Maven Dev List" <[EMAIL PROTECTED]>
> Sent: Friday, December 03, 2004 9:24 AM
> Subject: Problem dynamically excluding some tests
>
> > Currently I am trying to exclude a certain set of tests from running
> > on different machines based on their operation system. Basically I
> > have some DB code which has ODBC tests that I dont want to run on my
> > Redhat server but I want to run them on my XP desktop.
> >
> > I currently have the following settings:
> >
> > Extract from my POM:
> >
> >
> >
> > **/*Test.java
> >
> >
> > **/*Mock*.java
> >
> >
> > ${test.extra.excludes}
> >
> >
> >
> >
> > Extract from my maven.xml:
> >
> >
> >
> >
> > Including MsAccess(ODBC) Tests
> >
> >
> >
> > Excluding MsAccess(ODBC) Tests
> >
> >
> >
> >
> >
> >
> > Many thanks,
> > Corey
> >
> > -
> > 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]
Problem dynamically excluding some tests
Currently I am trying to exclude a certain set of tests from running
on different machines based on their operation system. Basically I
have some DB code which has ODBC tests that I dont want to run on my
Redhat server but I want to run them on my XP desktop.
I currently have the following settings:
Extract from my POM:
**/*Test.java
**/*Mock*.java
${test.extra.excludes}
Extract from my maven.xml:
Including MsAccess(ODBC) Tests
Excluding MsAccess(ODBC) Tests
Many thanks,
Corey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ading a new tag to ?
Actually I was going to have a shot at creating a patch for this, but when I checked the CVS, I got lost with the fact that the code appears to be generated and I havent found time yet to figure out exactly how :-) -Corey On Tue, 23 Nov 2004 23:09:06 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > This has been discussed several times in the past. I must say, scope is > probably the best name I've seen for it so far. > > It will get resolved in some way in the near future. > > - Brett > > > > Corey Scott wrote: > > >While we are on the subject of adding tags to has a scope > >tag been considered? This would allow users to generate dep reports > >and so on that lead to a better understanding of where and why the > >dependancy exists. > > > >Examples: > >Runtime (default) runtime > >Test Only test > >Build Only build > >Dependancy of a Dependancy ?? > > > >I believe that this has been hinted at during previous discussions and > >bug reports and i think it is has merit. > > > >Comments? > > > >-Corey > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven site work
I love the new menu, I think it will be great for first time users as it requires less interpretation. I am happy to help out with the docs (although I am by no means a Maven expert yet), just let me know what you would like done and if I can I will help out. -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ading a new tag to ?
While we are on the subject of adding tags to has a scope tag been considered? This would allow users to generate dep reports and so on that lead to a better understanding of where and why the dependancy exists. Examples: Runtime (default) runtime Test Only test Build Only build Dependancy of a Dependancy ?? I believe that this has been hinted at during previous discussions and bug reports and i think it is has merit. Comments? -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] RFC on Maven vs. Struts vs. Xdoclet
Eric, I don't mind where it goes, but i do agree with you that the xdoclet seems more appropriate. This had been my original intention. The reason I posted it here was to get some feedback, to make sure that it was correct, and useable, as I didnt want to waste peoples time reading something that did them no good. Actually, I intend to improve the formatting a little and add a footnote in regard to hacking the struts xdt file, cause I cant seem to get the version attriburte apply (bug already raised). I believed that Maven people would be better at checking the article than xdoclet people because most of the difficult stuff from a new users perspective (well mine before i started) was how to get Maven to do what the Ant examples said it could do :-) -Corey On Thu, 18 Nov 2004 11:39:43 -, Eric Pugh <[EMAIL PROTECTED]> wrote: > Corey, have you thought about submitting this to the xdoclet site instead? > If the maven project is really going to have the plugins typically supported > by the individual project, then we should redirect questions to those site's > mailing list. And same for content. > > If you would like, send it to the xdoclet-dev site and open a JIRA issue and > I can commit it. > > I do think we should be redirecting the various xdoclet questions towards > the xdoclet mailing lists. I'll do my part on redirecting folks! > > Eric > > > > > -Original Message- > > From: Corey Scott [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, November 17, 2004 7:51 PM > > To: Maven Developers List > > Subject: Re: [OT] RFC on Maven vs. Struts vs. Xdoclet > > > > > > Brett, > > > > If it is considered useful, then I am happy to maintain it and donate > > to Maven site. I am happy to check again for articles, I have to > > admit I googled for a while and couldnt find anything that told me the > > whole story, but this may have been an experience thing as I was > > coming in fresh to xdoclet. > > > > -Corey > > > > On Thu, 18 Nov 2004 06:48:01 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > > > Hi Corey, > > > > > > I haven't read through this just yet, but do you have any intentions for > > > publishing it anywhere in particular? > > > > > > We could add it to the Maven site, but you'd have to maintain it by > > > submitting patches later on. Unfortunately the wiki is dead, at least > > > for now. > > > We're always on the lookout for good quality documentation and > > tutorials. > > > > > > I'm sure that there is a tutorial out there (maybe in the articles > > > section, one of the J2EE ones?), it would be worth checking for any > > > overlap there. > > > > > > Cheers, > > > Brett > > > > > > > > > > > > Corey Scott wrote: > > > > > > >Hi, > > > > > > > >I recently tried to get xdoclet to generate my struts-config.xml, > > > >web.xml, and validation.xml files and thanks to Erik Hatcher, my > > > >JSP's, etc. > > > > > > > >After a lot of searching I couldnt find a Maven article for this, only > > > >Ant ones. Because of this, I tried to keep a record of way I did and > > > >so on. > > > > > > > >I have tried to turn this into an article/roadmap of sorts (attached). > > > > > > > >I have decided to post it to list for two reasons. > > > > > > > >First, to get comments from those (and I am sure there are lots of > > > >you) that know infinately more than me about this kind of thing and > > > >secondly to add it to the archive and pass it on to maven-users for > > > >anyone (like me) that might find it useful. > > > > > > > >I happy to take comments, suggestion and even critisizm regarding > > > >this, as am sure that it can only make the end result better. I am > > > >also more than happy for anyone to use/abuse or publish this at their > > > >will (peril :-D). > > > > > > > >Regards, > > > >Corey > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > 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: [OT] RFC on Maven vs. Struts vs. Xdoclet
Brett, If it is considered useful, then I am happy to maintain it and donate to Maven site. I am happy to check again for articles, I have to admit I googled for a while and couldnt find anything that told me the whole story, but this may have been an experience thing as I was coming in fresh to xdoclet. -Corey On Thu, 18 Nov 2004 06:48:01 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > Hi Corey, > > I haven't read through this just yet, but do you have any intentions for > publishing it anywhere in particular? > > We could add it to the Maven site, but you'd have to maintain it by > submitting patches later on. Unfortunately the wiki is dead, at least > for now. > We're always on the lookout for good quality documentation and tutorials. > > I'm sure that there is a tutorial out there (maybe in the articles > section, one of the J2EE ones?), it would be worth checking for any > overlap there. > > Cheers, > Brett > > > > Corey Scott wrote: > > >Hi, > > > >I recently tried to get xdoclet to generate my struts-config.xml, > >web.xml, and validation.xml files and thanks to Erik Hatcher, my > >JSP's, etc. > > > >After a lot of searching I couldnt find a Maven article for this, only > >Ant ones. Because of this, I tried to keep a record of way I did and > >so on. > > > >I have tried to turn this into an article/roadmap of sorts (attached). > > > >I have decided to post it to list for two reasons. > > > >First, to get comments from those (and I am sure there are lots of > >you) that know infinately more than me about this kind of thing and > >secondly to add it to the archive and pass it on to maven-users for > >anyone (like me) that might find it useful. > > > >I happy to take comments, suggestion and even critisizm regarding > >this, as am sure that it can only make the end result better. I am > >also more than happy for anyone to use/abuse or publish this at their > >will (peril :-D). > > > >Regards, > >Corey > > > > > > > > > > > > > > - > 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]
[OT] RFC on Maven vs. Struts vs. Xdoclet
359-1376 you should find the definition of the xdoclet:xdoclet goal
and the classpath for this goal (see below)
<goal
description="xdoclet"
name="xdoclet:xdoclet">
<taskdef name="xdoclet"
classname="xdoclet.DocletTask">
<classpath>
<path
refid="maven.dependency.classpath"/>
<pathelement
path="${plugin.getDependencyPath('xdoclet:xdoclet')}"/>
<pathelement
path="${plugin.getDependencyPath('xdoclet:xjavadoc')}"/>
<pathelement
path="${plugin.getDependencyPath('xdoclet:xdoclet-xdoclet-module')}"/>
<pathelement
path="${plugin.getDependencyPath('commons-collections:commons-collections')}"/>
<pathelement
path="${plugin.getDependencyPath('commons-logging:commons-logging')}"/>
<pathelement
path="${plugin.getDependencyPath('log4j:log4j')}"/>
</classpath>
</taskdef>
Now to add the classes from our current project and therefore the class from
Erik's example we need to add another pathelement statement. So your code
should look like (below) when completed, changes in bold.
<goal
description="xdoclet"
name="xdoclet:xdoclet">
<taskdef name="xdoclet"
classname="xdoclet.DocletTask">
<classpath>
<path
refid="maven.dependency.classpath"/>
<pathelement
path="${plugin.getDependencyPath('xdoclet:xdoclet')}"/>
<pathelement
path="${plugin.getDependencyPath('xdoclet:xjavadoc')}"/>
<pathelement
path="${plugin.getDependencyPath('xdoclet:xdoclet-xdoclet-module')}"/>
<pathelement
path="${plugin.getDependencyPath('commons-collections:commons-collections')}"/>
<pathelement
path="${plugin.getDependencyPath('commons-logging:commons-logging')}"/>
<pathelement
path="${plugin.getDependencyPath('log4j:log4j')}"/>
<pathelement
location="${maven.xdoclet.xdoclet.additionalClasspath}"/>
</classpath>
</taskdef>
You may have notices a property that we added to our project.properties
file earlier that you couldn't find in the xdoclet documentation,
maven.xdoclet.xdoclet.additionalClasspath, this
is because we just finished adding it.
Now if you run the xdoclet:xdoclet goal, your JSP's and corresponding
properties files have been generated and placed in the directory we specified
in a line similar to this (see above).
maven.xdoclet.xdoclet.destDir=${maven.build.dir}/generated-jsps/
If you take a look at the generated files, you will see the brilliance
of Erik's example, all text has been externalized into property files and these
display names have been 'humanized' so you are automatically ready for both
translation and possibly shipping the pages of to the design team (if you are
lucky enough to have one). You may want to experiment/modify Erik's class for
passing the comments depending on your coding style and naming convention, I
had to do this, but this because I started life as a C++ programmer and haven't
lost the habit of hungarian notation.
As always, I hope this has helped you and if you have any questions,
suggestions or corrections, please feel free to email me.
Corey Scott
mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
model source
Does anyone know where the maven-model-1.1-SNAPSHOT source is? It looks like it is supposed to be in maven-components/maven-model but there are not source files there? Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Strange exceptions during struts-config generation with xdoclet
This may be [OT] if it is please forgive me, and please tell me where I should be posting this, but... I am getting strange exception thrown when generating my struts config (web.xml/struts-config.xml/validation.xml) on something that previously worked, albeit on a different computer. Below is the stack trace, does anyone know what I can do to fix this? Thanks, Corey java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(ZipFile.java:112) at java.util.zip.ZipFile.(ZipFile.java:128) at org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:870) at org.apache.tools.ant.AntClassLoader.getResource(AntClassLoader.java:799) at java.lang.Class.getResource(Class.java:1352) at xdoclet.tagshandler.MergeTagsHandler.getMergeFileContents(MergeTagsHandler.java:207) at xdoclet.tagshandler.MergeTagsHandler.merge(MergeTagsHandler.java:67) at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at xdoclet.template.TemplateEngine.invoke(TemplateEngine.java:635) at xdoclet.template.TemplateEngine.invokeMethod(TemplateEngine.java:534) at xdoclet.template.TemplateEngine.invokeBlockMethod(TemplateEngine.java:959) at xdoclet.template.TemplateEngine.handleBlockTag(TemplateEngine.java:926) at xdoclet.template.TemplateEngine.handleTag(TemplateEngine.java:466) at xdoclet.template.TemplateEngine.generate(TemplateEngine.java:347) at xdoclet.XDocletTagSupport.generate(XDocletTagSupport.java:738) at xdoclet.tagshandler.ClassTagsHandler.forAllClasses(ClassTagsHandler.java:331) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at xdoclet.template.TemplateEngine.invoke(TemplateEngine.java:635) at xdoclet.template.TemplateEngine.invokeMethod(TemplateEngine.java:561) at xdoclet.template.TemplateEngine.invokeBlockMethod(TemplateEngine.java:959) at xdoclet.template.TemplateEngine.handleBlockTag(TemplateEngine.java:926) at xdoclet.template.TemplateEngine.handleTag(TemplateEngine.java:466) at xdoclet.template.TemplateEngine.generate(TemplateEngine.java:347) at xdoclet.template.TemplateEngine.start(TemplateEngine.java:414) at xdoclet.TemplateSubTask.startEngine(TemplateSubTask.java:560) at xdoclet.TemplateSubTask.startProcessForAll(TemplateSubTask.java:616) at xdoclet.TemplateSubTask.startProcess(TemplateSubTask.java:597) at xdoclet.XmlSubTask.startProcess(XmlSubTask.java:198) at xdoclet.modules.web.WebXmlSubTask.execute(WebXmlSubTask.java:366) at xdoclet.XDocletMain.start(XDocletMain.java:48) at xdoclet.DocletTask.start(DocletTask.java:464) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:110) at org.apache.tools.ant.Task.perform(Task.java:341) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) 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.PreGoalTag$1.firePreGoal(PreGoalTag.java:87) at com.werken.werkz.Goal.firePreGoalCallbacks(Goal.java:691) at com.werken.werkz.Goal.fire(Goal.java:616) 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 com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:634) at org.apache.maven.MavenSession.
Extension to Jdiff plugin (sort of)
To whom might be interested,
I have developed an extension (sort of) to the JDiff maven plugin that
checks-out a version (defined by property ${maven.jdiff.javadoc.tag},
defaults to CURRENT) and then generates the javadoc.
The docs are generated in:
${docsDest}/apidocs/${maven.jdiff.javadoc.tag}
There is probably more to be done, eg. adding links to the menu, but
this is my first attempt with jelly (so the code is likely to be a
little sloppy also)
Questions:
1) Is anyone is interested?
2) As its strictly not related to the JDiff plugin, where should I submit it?
Many thanks,
Corey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
