Re: AW: How to implement a nightly build system in maven
http://gump.apache.org/ Have you looked at gump? CNI wrote: Hello, As a beginner as well I have tried to use Anthill OS, though it lacks support for calling Maven goals directly (in the Open Source version). Instead I have written a little build script that executes Maven in an Ant exec task. Has anyone else utilised Anthill with Maven before? Someone found a more elegant way perhaps? Regards, Christian Nill I am a maven beginner. We use maven to build and manage our project. Right now we want to build a nightly build system that will automatically build, deploy, run all the tests of the project at least once a day. Can anyone give me some ideas for it? Are there any examples available which I can have a look? - 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: Whitespace in filepath's when using javadoc plugin
You may have to walk through the directories doing a dir /x C:\Documents and Settings will look like: C:\DOCUME~1 I develop on a windows box now and the, I just avoid directories with spaces. It confuses the tokenizers. Bertil Karlsson wrote: Is there a way around the problem that the javadoc plugin produces, if the filepath of sources contains whitespace? I have a developer in my project that has his project under 'C:\Documents and Settings\...' and this seems to upset the javadoc tool. I have browsed the FAQ and archives for the javadoc plugin and also tried to STFW for this problem with no luck! Greatful for any leads in this matter. I have tried to change the javadoc jelly code to try to surround the files with ..., but have not been successfull yet. BRGDS /Bertil - 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: Whitespace in filepath's when using javadoc plugin
javadoc is a pain to use, I'm convinced it was written by C++ programmers ;-) I'm not sure that maven itself is too troubled by spaces, it's javadoc. Peter Bright wrote: Then the tokenizers are broken. Any tokenizer manipulating paths should split on the system separators (for directories and paths, e.g. \ and ; for Win32, / and : for *nix), not on spaces. It'd probably be a significant breaking change to maven to make it use these separators throughout (at the moment space separation is used in lots of places) but it IMNSHO needs doing. Consider in particular that one can readily have a space-containing filename with no short equivalent (short filename generation is an optional feature of NTFS and AFAIK not at all possible on any *nix). -Original Message- From: Kevin Hagel [mailto:[EMAIL PROTECTED] Sent: 01 April 2004 16:11 To: Maven Users List Subject: Re: Whitespace in filepath's when using javadoc plugin You may have to walk through the directories doing a dir /x C:\Documents and Settings will look like: C:\DOCUME~1 I develop on a windows box now and the, I just avoid directories with spaces. It confuses the tokenizers. Bertil Karlsson wrote: Is there a way around the problem that the javadoc plugin produces, if the filepath of sources contains whitespace? I have a developer in my project that has his project under 'C:\Documents and Settings\...' and this seems to upset the javadoc tool. I have browsed the FAQ and archives for the javadoc plugin and also tried to STFW for this problem with no luck! Greatful for any leads in this matter. I have tried to change the javadoc jelly code to try to surround the files with ..., but have not been successfull yet. BRGDS /Bertil - 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: Whitespace in filepath's when using javadoc plugin
Another thing wrong with javadoc: Do you use xdoclet? @xdoclet.tag-with-hyphens javadoc will scream all over about hyphens in unrecognized tags. You try to tell it to ignore them, but it won't, /as long as there are hyphens in it./ It still runs, but it fills up your vertical terminal space whining about it. xdoclet fixed this by allowing you to: @xdoclet.tag.without.hyphens Peter Bright wrote: Then the tokenizers are broken. Any tokenizer manipulating paths should split on the system separators (for directories and paths, e.g. \ and ; for Win32, / and : for *nix), not on spaces. It'd probably be a significant breaking change to maven to make it use these separators throughout (at the moment space separation is used in lots of places) but it IMNSHO needs doing. Consider in particular that one can readily have a space-containing filename with no short equivalent (short filename generation is an optional feature of NTFS and AFAIK not at all possible on any *nix). -Original Message- From: Kevin Hagel [mailto:[EMAIL PROTECTED] Sent: 01 April 2004 16:11 To: Maven Users List Subject: Re: Whitespace in filepath's when using javadoc plugin You may have to walk through the directories doing a dir /x C:\Documents and Settings will look like: C:\DOCUME~1 I develop on a windows box now and the, I just avoid directories with spaces. It confuses the tokenizers. Bertil Karlsson wrote: Is there a way around the problem that the javadoc plugin produces, if the filepath of sources contains whitespace? I have a developer in my project that has his project under 'C:\Documents and Settings\...' and this seems to upset the javadoc tool. I have browsed the FAQ and archives for the javadoc plugin and also tried to STFW for this problem with no luck! Greatful for any leads in this matter. I have tried to change the javadoc jelly code to try to surround the files with ..., but have not been successfull yet. BRGDS /Bertil - 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: Dependency - If version is not specified, should it consider '-' or not?
Assume you have yourstuff-1.1.jar, a versioned library dependency groupIdyourstuff/groupId artifactIdyoursetuff/groupId version1.2/version /dependency Now assume you have yourstuff.jar, a non-versioned library. dependency groupIdyourstuff/groupId artifactIdyoursetuff/groupId jaryourstuff.jar/jar /dependency Maczka Michal wrote: -Original Message- From: Veerasamy, Thirumalai (Cognizant) [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 2:36 PM To: Maven Users List Subject: Dependency - If version is not specified, should it consider '-' or not? Hi, I specify a dependency like given below. dependency groupIdgroup/groupid artifactIdartifact/artifactId /dependency Though I didn't specify a version for that file it still expects as group/group-artifact-.jar. Is this the expected behaviour? Yes it is expected behaviour. Shouldn't it ignore '-' if version is not specified. No! all artifacts in the repository must be versioned. Michal - 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 - If version is not specified, should it consider '-' or not?
oops, a typo dependency groupIdyourstuff/groupId artifactIdyoursetuff/artifactId version1.2/version /dependency Now assume you have yourstuff.jar, a non-versioned library. dependency groupIdyourstuff/groupId artifactIdyoursetuff/artifactId jaryourstuff.jar/jar /dependency Kevin Hagel wrote: Assume you have yourstuff-1.1.jar, a versioned library dependency groupIdyourstuff/groupId artifactIdyoursetuff/groupId version1.2/version /dependency Now assume you have yourstuff.jar, a non-versioned library. dependency groupIdyourstuff/groupId artifactIdyoursetuff/groupId jaryourstuff.jar/jar /dependency Maczka Michal wrote: -Original Message- From: Veerasamy, Thirumalai (Cognizant) [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 2:36 PM To: Maven Users List Subject: Dependency - If version is not specified, should it consider '-' or not? Hi, I specify a dependency like given below. dependency groupIdgroup/groupid artifactIdartifact/artifactId /dependency Though I didn't specify a version for that file it still expects as group/group-artifact-.jar. Is this the expected behaviour? Yes it is expected behaviour. Shouldn't it ignore '-' if version is not specified. No! all artifacts in the repository must be versioned. Michal - 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 javadoc [RC2] Problem
you might want to try reversing the '\' character. C:\Program to C:/Program Even though windoze likes the front-slash, your jvm is smart enough to resolve those. it could be something else but I've seen this problem in similar situations. Menetrieux Remy wrote: Hi, When I run maven with the javadoc I obtain this errors : maven-javadoc-plugin:report: [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] javadoc: Illegal package name: C:\Program [javadoc] javadoc: Illegal package name: Files\Apache [javadoc] javadoc: Illegal package name: Foundation\Maven [javadoc] javadoc: File not found: 1.0-rc2\project\src\com\. I miss a properties ?? Thanks RémY The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be a violation of law. If you received this transmission in error, please contact the sender by reply e-mail and delete and destroy all copies of the material, including all copies stored in the recipient's computer, printed or saved to disk. Thank you. Software virus: Europcar has taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. Europcar cannot accept liability for any loss or damage caused by software viruses. Intellectual Property: Europcar has built up a significant reputation in the name Europcar and has a number of trademark applications and registrations in many countries. No trademarks, service marks, and trade names owned or licensed by Europcar or its affiliates may be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, without the prior written consent of Europcar. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven javadoc [RC2] Problem
Spaces in the path often confuse java tokenizing, isn't there a way to make a windows path without them, C:\program~1\Apache~2\ like that? Menetrieux Remy wrote: When javadoc goals generate the file list in a javadoc file. It generate with an absolute Path. I run mave from the C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\ Have you any idea to resolve this ? Eg: My javadoc file : C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\src\xxx\\xx\\x x\\Remy.java C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\src\xxx\\xx\\x x\\RemyCheck.java C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\src\xxx\\xx\\x x\\RemyHome.java C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\src\xxx\\xx\\x x\\RemyImpl.java C:\Program Files\Apache Software Foundation\Maven-1.0-rc2\project_name\src\xxx\\xx\\x x\\RemyPk.java -Message d'origine- De : Kevin Hagel [mailto:[EMAIL PROTECTED] Envoyé : lundi 29 mars 2004 16:05 À : Maven Users List Objet : Re: maven javadoc [RC2] Problem can you just use maven.javadoc.package=* Menetrieux Remy wrote: My package Tag contain com.x.project_name I don't understand why maven get my absolute path to my project.. -Message d'origine- De : Andy Jefferson [mailto:[EMAIL PROTECTED] Envoyé : lundi 29 mars 2004 15:57 À : Maven Users List Objet : Re: maven javadoc [RC2] Problem On Monday 29 Mar 2004 14:51, Menetrieux Remy wrote: Hi, When I run maven with the javadoc I obtain this errors : maven-javadoc-plugin:report: [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] javadoc: Illegal package name: C:\Program [javadoc] javadoc: Illegal package name: Files\Apache [javadoc] javadoc: Illegal package name: Foundation\Maven [javadoc] javadoc: File not found: 1.0-rc2\project\src\com\. What did you put in project.xml for package ? HTH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be a violation of law. If you received this transmission in error, please contact the sender by reply e-mail and delete and destroy all copies of the material, including all copies stored in the recipient's computer, printed or saved to disk. Thank you. Software virus: Europcar has taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. Europcar cannot accept liability for any loss or damage caused by software viruses. Intellectual Property: Europcar has built up a significant reputation in the name Europcar and has a number of trademark applications and registrations in many countries. No trademarks, service marks, and trade names owned or licensed by Europcar or its affiliates may be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, without the prior written consent of Europcar. - 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: How to ignore xdoclets tags on javadoc
the example I posted comes from an ant build.xml file, not a maven.xml file, there's no jelly involved. Also, jelly never sees the source file, in this kind of thing jelly never sees the content of source files, it only directs them to javadoc. I've been reading about xjavadoc now being able to read @web.servlet.mapping as @web.servlet-mapping, which helps to get rid of the javadoc bitching about the xdoclet tags. I've tested it, it seems to work ... at least for xdoclet-1.2 Jörg Schaible wrote: Kevin Hagel wrote on Wednesday, March 10, 2004 8:25 AM: here's a section of my build file that javadocs: !-- Try to get JavaDoc to shut the hell up about the XDoclet tags. -- tag name=web.servlet scope=overview enabled=false/ tag name=web.listener enabled=false/ tag name=web.filter enabled=false/ tag name=hibernate.property enabled=false/ tag name=hibernate.class enabled=false/ tag name=hibernate.id enabled=false/ tag name=todo scope=all description=To do: / the problem is: while @web.servlet will be successfully ignored, @web.servlet-mapping will not, something about the hypen in servlet-mapping. Javadoc advises using something like @web.servlet.mapping, but that's not really very useful for us is it? I suspect javadoc was written by C++ programmers ;-) Well, before pointing at javadoc, you might consider Jelly g IMHO it tries to evaluate the expression servlet-mapping ;-) Regards, 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: How to ignore xdoclets tags on javadoc
http://maven.apache.org/reference/plugins/javadoc/properties.html
at the top of your maven.xml you can be sure to nclude this kind of
thing (among others)
project
xmlns:ant=jelly:ant
below is actually from an ant build.xml target. visit that link at top
and look at the maven.javadoc.customtags down in the middle of the page.
the stuff below will work in your maven.xml, there are better ways to do
it that are more maven, but this can help get you started.
Let's assume you have your local repostiory in $MAVEN_HOME_LOCAL (that's
linux, for windows it's %MAVEN_HOME_LOCAL%)
Look in $MAVEN_HOME_LOCAL/plugins/maven-javadoc-plugin-1.3 for a file
called plugin.jelly
I learned a lot from looking in the plugin.jelly files in the plugins
directory, they are in the exact same format as a maven.xml file
goal name=javadocs
ant:javadoc sourcepath=${src.dir}
destdir=${javadoc.dest.dir}
packagenames=*
defaultexcludes=yes
Private=true
verbose=no
group=true
stylesheetfile=${basedir}/docs/stylesheet.css
failonerror=false
Overview=${basedir}/docs/overview.html
ant:tag name=web.servlet scope=overview enabled=false/
ant:tag name=web.listener enabled=false/
ant:tag name=web.filter enabled=false/
ant:tag name=hibernate.property enabled=false/
ant:tag name=hibernate.class enabled=false/
ant:tag name=hibernate.id enabled=false/
ant:tag name=todo scope=all description=To do: /
ant:packageset dir=${java.src.dir}
/packageset
ant:classpath refid=compile.classpath /
ant:link
href=http://jakarta.apache.org/commons/beanutils/api//
ant:link
href=http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_2_1//
ant:link
href=http://jakarta.apache.org/commons/logging/api//
ant:link
href=http://jakarta.apache.org/commons/lang/apidocs//
ant:link
href=http://jakarta.apache.org/commons/fileupload/apidocs/; /
ant:link
href=http://jakarta.apache.org/tomcat/tomcat-4.0-doc/servletapi/; /
ant:link href=http://java.sun.com/j2se/1.4.2/docs/api//
ant:link href=http://www.hibernate.org/hib_docs/api//
ant:link href=http://www.springframework.org/docs/api//
/ant:javadoc
/goal
Miguel Griffa wrote:
Hi,
I'm sorry I'm still quite newbie here, where should I place this? in
maven.xml or project.xml?
Kevin Hagel wrote:
here's a section of my build file that javadocs:
!--
Try to get JavaDoc to shut the hell up about the XDoclet
tags.
--
tag name=web.servlet scope=overview enabled=false/
tag name=web.listener enabled=false/
tag name=web.filter enabled=false/
tag name=hibernate.property enabled=false/
tag name=hibernate.class enabled=false/
tag name=hibernate.id enabled=false/
tag name=todo scope=all description=To do: /
the problem is: while @web.servlet will be successfully ignored,
@web.servlet-mapping will not, something about the hypen in
servlet-mapping. Javadoc advises using something like
@web.servlet.mapping, but that's not really very useful for us is it?
I suspect javadoc was written by C++ programmers ;-)
Miguel Griffa wrote:
Hi all,
This is my first post to the list.
I'm becoming a fan of maven, but I find myself still climbing the
learning curve...
Could anyone tellme
How can I ignore some tags on maven javadoc report?
(I have lots of xdoclet tags)
Thanks in advance
-
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: How to ignore xdoclets tags on javadoc
here's a section of my build file that javadocs: !-- Try to get JavaDoc to shut the hell up about the XDoclet tags. -- tag name=web.servlet scope=overview enabled=false/ tag name=web.listener enabled=false/ tag name=web.filter enabled=false/ tag name=hibernate.property enabled=false/ tag name=hibernate.class enabled=false/ tag name=hibernate.id enabled=false/ tag name=todo scope=all description=To do: / the problem is: while @web.servlet will be successfully ignored, @web.servlet-mapping will not, something about the hypen in servlet-mapping. Javadoc advises using something like @web.servlet.mapping, but that's not really very useful for us is it? I suspect javadoc was written by C++ programmers ;-) Miguel Griffa wrote: Hi all, This is my first post to the list. I'm becoming a fan of maven, but I find myself still climbing the learning curve... Could anyone tellme How can I ignore some tags on maven javadoc report? (I have lots of xdoclet tags) Thanks in advance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hibernate/xdoclet output locations.
go into your repository and look in your local repository, the
$MAVEN_HOME_LOCAL/plugins/maven-xdoclet-plugin-1.2
Look at the plugin.properties, you can see all the defaults used, that
you can override.
The plugin.jelly is a monster, about 11,000 lines of code. But it is
worth the look.
Tim Chen wrote:
Okay.. I dont see anything obvious in there (someone else might).
Do you have anything in your maven.xml that would relate to this?
Or are you calling the xdoclet-hibernate task directly from the cmd line?
-Tim
Eric Merritt wrote:
--- Tim Chen [EMAIL PROTECTED] wrote:
Well.. I only ask cause I'm using xdoclet/hibernate
combo and it is working just fine. (only generates it to the
location I ask).
Just out of curiousity:
What version of XDoclet are you using?
Can you paste your project.properties and build
section from your project.xml?
-Tim
Sure, no problem. Xdoclet plugin version is 1.2
#
# Maven repository changes
#
maven.repo.remote =
http://www.ibiblio.org/maven,http://dist.codehaus.org,http://mirrors.sunsite.dk/maven
#
# Checkstyle overried
#
maven.checkstyle.properties =
${basedir}/src/conf/checkstyle.xml
#
# Site formating properties
#
maven.ui.body.background=white
maven.ui.body.foreground=black
maven.ui.banner.background=white
#--
# Hibernate properties
#--
maven.xdoclet.hibernatedoclet.destdir=${maven.build.dir}/xdoclet/hibernatedoclet
maven.xdoclet.hibernatedoclet.fileset.0=true
maven.xdoclet.hibernatedoclet.fileset.0.dir=${maven.src.dir}/java
maven.xdoclet.hibernatedoclet.fileset.0.include=**/*.java
maven.xdoclet.hibernatedoclet.hibernate.0.Version=2.0
-
Relevant portion of project.xml
build
sourceDirectorysrc/main/java/sourceDirectory
unitTestSourceDirectorysrc/test/java/unitTestSourceDirectory
!-- Unit test cases --
unitTest
resources
resource
directorysrc/test/java/directory
includes
include**/*/include
/includes
excludes
exclude**/*.java/exclude
/excludes
/resource
/resources
includes
include**/*Test.java/include
/includes
/unitTest /build
Eric Merritt wrote:
--- Tim Chen [EMAIL PROTECTED] wrote:
I am using xdoclet/hibernate and do not see that
behavior.
Location 2 and 3 might be bugs.
I also have
maven.xdoclet.hibernatedoclet.destdir=${maven.build.dir}/xdoclet/hibernatedoclet
and the generate .hbms are only in that folder.
Do you have something set up in project.xml
resources that might be causing this to occur?
-Tim
I don't really see that I do. Its a pretty
straitforward project file and I am not doing
anything
wierd. I will be happy to supply it if anyone is
interested.
__
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools
-
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]
__
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools
-
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: jakarta-taglibs
lots of licensing issues to deal with there, some folks just don't want their jars uploaded to ibiblio -- even though you can download them for free from the source! Just add the needed directories to your $MAVEN_HOME_LOCAL, for example: mkdir $MAVEN_HOME_LOCAL/repository/jstl/jars and stick it in yourself (so to speak) use dependencies as you normally would if they were on ibiblio. Daniel Draws wrote: Hi! Actually I'm developing an J2EE project. And I like the idea to test maven. And first I want to say, that I like it. Now I want to develop the web-tier and I can't find any of the jakarta-taglibs (http://jakarta.apache.org/taglibs/index.html). I can not beliefe that no developer using maven uses any of them (logging, datetime,...). I don't know, if this is the right place: But is there anybody, who can tell me, were to find a remote repository with this libs. If not: Would it be posible to add the jakarta-taglibs to the ibiblio-repository. The normal JIRA-way seems to be not the best, because it requires more then 25 requests. And all of the older requests for the upload of taglibs are opend since September 03. Is there any workaround, if there is no posibility for putting the libs in a remote repository. I think it should be posible to declare a dependency for a zip file and then in the build-pocess this file should be unzipped and included in the target. thx daniel - 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: Installing Maven %HOME%
%HOME% is your windows user account home. If you want to share your repository, do not put it in any one person's home directory, I use C:\mavenrepository and everybody on the system has access. George Hester wrote: In this article just under the warning, http://maven.apache.org/start/install.html the directions say, For Windows: %MAVEN_HOME%\bin\install_repo.bat %HOME%\.maven\repository I understand %MAVEN_HOME% but I do not understand %HOME%. Exactly what are they referring to and should I set an Environment variable called HOME and if so what should it point to? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installing Maven %HOME%
open a command window and just type set and you'll see the whole pile of environment variables. I advise against using any directories in maven that contain spaces, such as Documents And Settings. While they're convenient for we humans, some jelly scripts tokenize on white space and things can get confused. I put it in C:\mavenrepository so that I can open an explorer folder and grab it right off the top, instead of having to descend into subdirectories to get at them -- as well as being able to share it with all other users who log into the system. George Hester wrote: Alright I think you are talking about these environment variables: ALLUSERSPROFILE for All Users or for me as the Adminstrator: USERPROFILE %HOME% equals one of the above? Is that correct? I would make a repository folder under C:\Documents and Settings\%profile% and then that's that? This is the weirdest install I have ever done. All I have is \maven\bin in the path. Shouldn't I put something from maven in my classpath? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build time
http://ant.apache.org/manual/CoreTasks/uptodate.html I use ant's uptodate to see if I need to rebuild anything in particular. When our project was in its early days there wasn't so much to build and it seemed like overkill, but after a while when things really bloated it made a big difference thorsten maus wrote: hi guys .. im actually having a multiproject with 4 subproject ... for each subproject the ejbdoclet as well as the hibernatedoclet ist working .. although not needed for each ... the altogether build time is about 4-5 minutes is there any way to speed the build process up ??? - 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: external jar files ...
In your local maven repository create a directory, call it example for this example. That's $MAVEN_HOME/repository/example create a subdirectory called jars, just like all the other directories and stash example.jar in it $MAVEN_HOME/repository/example/jars/example.jar In your project.xml: dependencies ... dependency groupIdexample/groupId artifactIdexample/artifactId jarexample.jar/jar /dependency /dependencies Maven will grab it from that. If you use versions, say example-1.0.jar, use version1.0/version instead of jarexample.jar/jar If you have a project called example which produces example.jar, in your maven.xml goal name=install prereqs=prepare attainGoal name=jar:install/ /goal Gregory Joseph wrote: If you want to give it one more try, maybe we can help and eventually that would also help improve the docs? g -Original Message- From: Dave Raymer [mailto:[EMAIL PROTECTED] Sent: lundi 23 fvrier 2004 23:22 To: Maven Users List Subject: RE: external jar files ... Greg, I went through this and could not get it working ... I seem to have a mindset different than the folks that wrote the online manual I see your other response, and tried it, that works ... thanks muchly -- dave On Mon, 2004-02-23 at 11:16, Gregory Joseph wrote: Hi, This might help: http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependenc ies greg -Original Message- From: Dave Raymer [mailto:[EMAIL PROTECTED] Sent: lundi 23 fvrier 2004 18:55 To: [EMAIL PROTECTED] Subject: external jar files ... Gentlebeings, This is probably a very easy thing to do, but I can't figure it out for the life of me ... I have an external jar file, call it external.jar, that I need to be used during compilation of all my java entities in a maven build. What is the correct way to do this, vis a vis, the project.xml file. your help, and patience with a stupid question, is greatly appreciated. br, dave A man's greatest treasure is his wife, she is a gift from the Lord - Proverbs 18:22 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] A man's greatest treasure is his wife, she is a gift from the Lord- Proverbs 18:22 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: external jar files ...
Oops, rather than $MAVEN_HOME use whatever directory contains your repository, $MAVEN_HOME_LOCAL Kevin Hagel wrote: In your local maven repository create a directory, call it example for this example. That's $MAVEN_HOME/repository/example create a subdirectory called jars, just like all the other directories and stash example.jar in it $MAVEN_HOME/repository/example/jars/example.jar In your project.xml: dependencies ... dependency groupIdexample/groupId artifactIdexample/artifactId jarexample.jar/jar /dependency /dependencies Maven will grab it from that. If you use versions, say example-1.0.jar, use version1.0/version instead of jarexample.jar/jar If you have a project called example which produces example.jar, in your maven.xml goal name=install prereqs=prepare attainGoal name=jar:install/ /goal Gregory Joseph wrote: If you want to give it one more try, maybe we can help and eventually that would also help improve the docs? g -Original Message- From: Dave Raymer [mailto:[EMAIL PROTECTED] Sent: lundi 23 fvrier 2004 23:22 To: Maven Users List Subject: RE: external jar files ... Greg, I went through this and could not get it working ... I seem to have a mindset different than the folks that wrote the online manual I see your other response, and tried it, that works ... thanks muchly -- dave On Mon, 2004-02-23 at 11:16, Gregory Joseph wrote: Hi, This might help: http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependenc ies greg -Original Message- From: Dave Raymer [mailto:[EMAIL PROTECTED] Sent: lundi 23 fvrier 2004 18:55 To: [EMAIL PROTECTED] Subject: external jar files ... Gentlebeings, This is probably a very easy thing to do, but I can't figure it out for the life of me ... I have an external jar file, call it external.jar, that I need to be used during compilation of all my java entities in a maven build. What is the correct way to do this, vis a vis, the project.xml file. your help, and patience with a stupid question, is greatly appreciated. br, dave A man's greatest treasure is his wife, she is a gift from the Lord - Proverbs 18:22 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] A man's greatest treasure is his wife, she is a gift from the Lord- Proverbs 18:22 - 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: Using ANT build.xml in Maven?
Do you want to run an external ant file from within your maven project.xml, is that it? What Brett said and: http://ant.apache.org/manual/CoreTasks/ant.html ant antfile=subproject/subbuild.xml dir=subproject target=compile/ that's what I use. Some of the people around here get Ant, but not Maven, I have to do this to make their projects work sometimes. Brett Porter wrote: Maven.xml: project xmlns:ant=ant goal name=run-ant ant:ant just like your standard ant tag / /goal /project But you'll be poorer for it :) - Brett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, 24 February 2004 9:35 AM To: [EMAIL PROTECTED] Subject: Using ANT build.xml in Maven? Hi, I was wondering, is it possible to use a build.xml in Maven until you have configured the necessary pieces. If so, does anyone have any documentation on how to perform this task? Thanks in advance, -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: Using ANT build.xml in Maven?
except you wrap a goal around a target perhaps ... your command line would work the same. You can pretty much stuff all taskdefs, typedefs, and all that right inside your project.xml, Maven is an Ant wrapper in that. goal name=target1 ant:ant antfile=build.xml inheritAll=true inheritRefs=true target=target1 property name=param1 value=somevalue/ property file=config/subproject/default.properties/ /ant:ant /goal etc. [EMAIL PROTECTED] wrote: Hi, my boss just wants me to use the existing ANT build.xml until we can get a correct multiproject setup (i.e. maven.xml, project.properties, and build.properties). At this time, the project generates 14 artifacts; mostly JARs and EJB-JARs. Finally, I would simply like to reuse my build.xml to get it done for now. Thus, typing 'maven' at the command prompt: 'maven' would map to 'ant all' because I have the following: project name=project_name default=all basedir=. target name=target1 !-- some stuff for the target -- /target target name=target2 !-- some stuff for the target -- /target target name=target3 !-- some stuff for the target -- /target target name=target4 !-- some stuff for the target -- /target target name=target5 !-- some stuff for the target -- /target /project Thus, I would like to put the above inside the maven.xml and able to execute the tagets as maven goals. Is this possible? For example, maven target1 maven target2 maven all maven clean maven clobber and so on. However, I would like to do it in such a way to maintain the integrity of the same build.xml for both Maven and ANT. Thus, if I make changes to the build.xml file, I don't have to make changes to the maven.xml because the maven.xml simply references the build.xml. Is this possible? Thanks in advance, -Conrad Do you want to run an external ant file from within your maven project.xml, is that it? What Brett said and: http://ant.apache.org/manual/CoreTasks/ant.html ant antfile=subproject/subbuild.xml dir=subproject target=compile/ that's what I use. Some of the people around here get Ant, but not Maven, I have to do this to make their projects work sometimes. Brett Porter wrote: Maven.xml: project xmlns:ant=ant goal name=run-ant ant:ant just like your standard ant tag / /goal /project But you'll be poorer for it :) - Brett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, 24 February 2004 9:35 AM To: [EMAIL PROTECTED] Subject: Using ANT build.xml in Maven? Hi, I was wondering, is it possible to use a build.xml in Maven until you have configured the necessary pieces. If so, does anyone have any documentation on how to perform this task? Thanks in advance, -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: question about jboss SAR files
John Casey wrote:
Is there a plugin which will assemble JBoss .sar files (I assume these
aren't unique to JBoss, but I'm not sure they're the same as Avalon
SAR's). What I'm really after is the ability to bundle other jars within
the SAR, like the war and ear plugins. It could also be a variation of
the jar plugin, with bundling of properly marked dependencies...
Anyway, if this doesn't exist, I will probably write it. I just want to
check first.
-john
The most simple operation for me was to use the jar goal and rename the
result.
In your particular location in your mavenrepository create a
subdirectory called sars. The artifact:install goal seems smart enough
to look for it if you use the type=sar option.
goal name=sar:sar
description=Create the deliverable SAR file.
attainGoal name=jar/
!-- Rename the .jar to .sar --
j:set var=maven.sar.final.name
value=${maven.build.dir}/${maven.final.name}.sar/
move file=${maven.build.dir}/${maven.final.name}.jar
tofile=${maven.build.dir}/${maven.final.name}.sar
overwrite=true
verbose=true
/
/goal
goal name=sar:install prereqs=sar:sar
description=Install the SAR in the local repository
j:set var=maven.sar.final.name
value=${maven.build.dir}/${maven.final.name}.sar/
artifact:install
artifact=${maven.sar.final.name}
type=sar
project=${pom}
/
/goal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jdom 0.7.jar with META-INF/info.xml displays a uncomplete deployment when put in the deploy directory
I always see this happening too, especially as the EAR gets larger, contains
WARs etc.
It starts to fill up your server.log with a bunch of junk. If you use JMX
to deploy your EAR from a directory not under JBoss, the next time you
restart JBoss it isn't deployed anymore!
We tried having our maven scripts copy the EAR into server/default,
undeploying and deploying, this helped a little.
Finally we just did this: open your server/default/conf/server.xml and save
it, or just touch it somehow. JBoss sees this and clears the server.log in
a few moments.
this is a real kludge, but it clears up the server.log
- Original Message -
From: Stephane Nicoll [EMAIL PROTECTED]
To: Maven user list (E-mail) [EMAIL PROTECTED]
Sent: Friday, January 09, 2004 2:00 AM
Subject: Jdom 0.7.jar with META-INF/info.xml displays a uncomplete
deployment when put in the deploy directory
Hello list,
I think the problem is related to JBoss deployers so I am gonna ask this
here.
BTW, we use JBoss 3.2.1 - Redhat Linux
We have an ear that contains some libraries we use only in our application
(ear). That way we have only file to deploy and we are sure everything is
there. We use jdom (version 0.7) wich contains a META-INF/info.xml file.
When we deploy our ear, everything is ok but this log entry at the end of
the
deployment:
2004-01-09 10:55:39,482 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner] MBeanException:
Exception
in MBean operation 'checkIncompleteDeployments()'
Cause: Incomplete Deployment listing:
Packages waiting for a deployer:
[EMAIL PROTECTED] {
url=file:/var/jboss-3.2.1-kpserver2/server/default/tmp/deploy/server/default
/
deploy/kserver-mr-1.10.0-RC1.ear/38.kserver-mr-1.10.0-RC1.ear-contents/jdom-
0
.7.jar }
deployer: null
status: Starting
state: START_SUBDEPLOYMENTS
watch:
file:/var/jboss-3.2.1-kpserver2/server/default/tmp/deploy/server/default/depl
oy/kserver-mr-1.10.0-RC1.ear/38.kserver-mr-1.10.0-RC1.ear-contents/jdom-0.7.
j
ar
lastDeployed: 1073642108245
lastModified: 1073642106000
mbeans:
]Incompletely deployed packages:
none
MBeans waiting for classes:
none
MBeans waiting for other MBeans:
none
This is not really annoying because everything works ok but if you could
give
me a trick to avoid that message.
Regards,
Stephane
-
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: Jdom 0.7.jar with META-INF/info.xml displays a uncomplete deployment when put in the deploy directory
oops, I meant touch server/conf/log4j.xml
- Original Message -
From: Kevin Hagel [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Friday, January 09, 2004 2:28 AM
Subject: Re: Jdom 0.7.jar with META-INF/info.xml displays a uncomplete
deployment when put in the deploy directory
I always see this happening too, especially as the EAR gets larger,
contains
WARs etc.
It starts to fill up your server.log with a bunch of junk. If you use JMX
to deploy your EAR from a directory not under JBoss, the next time you
restart JBoss it isn't deployed anymore!
We tried having our maven scripts copy the EAR into server/default,
undeploying and deploying, this helped a little.
Finally we just did this: open your server/default/conf/server.xml and
save
it, or just touch it somehow. JBoss sees this and clears the server.log
in
a few moments.
this is a real kludge, but it clears up the server.log
- Original Message -
From: Stephane Nicoll [EMAIL PROTECTED]
To: Maven user list (E-mail) [EMAIL PROTECTED]
Sent: Friday, January 09, 2004 2:00 AM
Subject: Jdom 0.7.jar with META-INF/info.xml displays a uncomplete
deployment when put in the deploy directory
Hello list,
I think the problem is related to JBoss deployers so I am gonna ask this
here.
BTW, we use JBoss 3.2.1 - Redhat Linux
We have an ear that contains some libraries we use only in our application
(ear). That way we have only file to deploy and we are sure everything is
there. We use jdom (version 0.7) wich contains a META-INF/info.xml file.
When we deploy our ear, everything is ok but this log entry at the end of
the
deployment:
2004-01-09 10:55:39,482 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner] MBeanException:
Exception
in MBean operation 'checkIncompleteDeployments()'
Cause: Incomplete Deployment listing:
Packages waiting for a deployer:
[EMAIL PROTECTED] {
url=file:/var/jboss-3.2.1-kpserver2/server/default/tmp/deploy/server/default
/
deploy/kserver-mr-1.10.0-RC1.ear/38.kserver-mr-1.10.0-RC1.ear-contents/jdom-
0
.7.jar }
deployer: null
status: Starting
state: START_SUBDEPLOYMENTS
watch:
file:/var/jboss-3.2.1-kpserver2/server/default/tmp/deploy/server/default/depl
oy/kserver-mr-1.10.0-RC1.ear/38.kserver-mr-1.10.0-RC1.ear-contents/jdom-0.7.
j
ar
lastDeployed: 1073642108245
lastModified: 1073642106000
mbeans:
]Incompletely deployed packages:
none
MBeans waiting for classes:
none
MBeans waiting for other MBeans:
none
This is not really annoying because everything works ok but if you could
give
me a trick to avoid that message.
Regards,
Stephane
-
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: XDoclet plugin strange behavior
http://opensource.atlassian.com/projects/xdoclet/secure/ViewIssue.jspa?key=XDT-673
I filed this back in october, still unresolved.
Are you building from source? The maven plugin source still uses the old
style, which has NEVER worked since I first started building XDoclet about 6
months ago. I changed the /blah/XDocletsource/maven/project.xml file to
contain the following
dependency
idxdoclet+xdoclet-module/id
version@XDOCLET_VERSION@/version
/dependency
dependency
groupIdxdoclet/groupId
artifactIdxjavadoc/artifactId
version@XJAVADOC_VERSION@/version
/dependency
Without this fix XDoclet's maven plugin will not load.
- Original Message -
From: __matthewHawthorne [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Sunday, January 04, 2004 10:55 AM
Subject: Re: XDoclet plugin strange behavior
A week or so ago, I filed this as a bug with the Xdoclet team. The
plugin looks for the xjavadoc plugin with the groupId xjavadoc instead
of xdoclet. I haven't heard anything back.
The frustrating part is that the only way I was able to figure out the
error was by looking at the plugin's project.xml.
To fix it, you must either put the jar into repo/xjavadoc/jars or use
the jar override feature and put it wherever you want. I requested that
the xjavadoc jar be put into its own directory (not the xdoclet dir) on
ibiblio, but the request was denied.
Aleksandr Shneyderman wrote:
Konstantin Priblouda wrote:
Well, if yoyu use gourpid, you have to call your
xjavadoc xdoclet-xjavadoc.whatever.jar
According to the documentation the files are located according to the
following pattern:
${repo}/${groupId}/${type}s/${artifactId}-${version}.${type}
So if my dependency looks something like the following:
dependency
artifactIdxjavadoc/artifactId
groupIdxdoclet/groupId
version1.0.2/version
typejar/type
/dependency
Should not I expcet maven to find the jar if the file at location
${repo}/xdoclet/jars/xjavadoc-1.0.2.jar does exists?
Thanks,
Alex.
-
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: FTP
be sure to include commons-net in your dependencies. - Original Message - From: Michael Dunn [EMAIL PROTECTED] To: Maven Users List [EMAIL PROTECTED] Sent: Wednesday, December 10, 2003 9:51 AM Subject: FTP I have been trying to use Maven to do an FTP and it says the following in my maven.log Any suggestions? Thanks, Mike 2003-12-10 12:49:51,505 WARN org.apache.commons.jelly.tags.ant.AntTag - Could not convert tag: ftp into an Ant task, data type or property 2003-12-10 12:49:51,521 WARN org.apache.commons.jelly.tags.ant.AntTag - Could not convert tag: telnet into an Ant task, data type or property 2003-12-10 12:49:51,521 WARN org.apache.commons.jelly.tags.ant.AntTag - Could not convert tag: read into an Ant task, data type or property 2003-12-10 12:49:51,521 WARN org.apache.commons.jelly.tags.ant.AntTag - Could not convert tag: write into an Ant task, data type or property 2003-12-10 12:49:51,521 WARN org.apache.commons.jelly.tags.ant.AntTag - Could not convert tag: read into an Ant task, data type or property 2003-12-10 12:49:51,521 INFO org.apache.maven.cli.App - Total time: 22 seconds 2003-12-10 12:49:51,521 INFO org.apache.maven.cli.App - Finished at: Wed Dec 10 12:49:51 EST 2003 2003-12-10 12:49:51,521 INFO org.apache.maven.cli.App - - 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: Leading slash gets removed from navigation.xml hrefs during site generation
I'm using the root context for one thing, and the site project page uses a
different context. I'm also putting it all in a WAR and dumping it into my
JBoss deploy directory.
To enable this, for example with image paths,
img src=@contextRoot@/images/something.jpg/
and then do an ant replace:
goal name=site-war prereqs=site, site-init
description=Create a WAR File from the generated site
mkdir dir=${docsDest}/WEB-INF /
filter token=ContextRoot value=${site.contextroot} /
replace dir=${docsDest}
include name=**/*.css/
include name=**/*.html/
include name=**/*.fml/
replacefilter token=@contextRoot@ value=${site.contextroot} /
/replace
war destfile=${maven.build.dir}/hagelnx-site.war
webxml=${basedir}/src/conf/web.xml
fileset dir=${docsDest} /
/war
/goal
Maven uses site, site:site, site:init kind of thing, I sort of stole that
nomenclature for site-init kind of thing.
This way I don't have to worry about what the site generation is doing or
not, at least I'm not having the same problem that you are having.
- Original Message -
From: Ben Walding [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 12:56 PM
Subject: Re: Leading slash gets removed from navigation.xml hrefs during
site generation
You probably want something like
/absolute/multiproject/${reactorProject.name}
Jefferson K. French wrote:
I've read through several postings about multiproject site navigation
in the archives, and downloaded the WebShop example, but I'm still
unable to get absolute paths to work in my subprojects.
My multiproject/navigation.xml contains:
menu name=Projects
#foreach ($reactorProject in $reactorProjects)
item name=$reactorProject.name
href=/multiproject/${reactorProject.name}
#end
/menu
But the leading slash is always missing from the resulting index.html
file:
a href=multiproject/mdb-util/index.html.../a
In fact, the same thing happens with the hrefs in the parent's
xdocs/navigation.xml file.
Any ideas what I could be doing wrong?
I'm using RC2 built from CVS on 11/25/03. My xdoc plugin is
1.5-SNAPSHOT. Looks like its files have not been updated since my
11/25/03 install.
Jeff
-
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: 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 of generated source
Where do most maven developers place generated files (ex: xdoclet)?
I've been developing a maven project for the past 6 months and have been
dumping all generated files into 'target' to avoid saving into CVS. Now,
with over 200 generated classes, and little change, I'd like to avoid
having
xdoclet run EACH java:compile. So, here are my two options as I see them:
1. create a separate subproject, and have the generated interfaces saved
in
src/java to appease maven. Add a task into maven.xml to regenerate the
classes only when needed.
2. save the files in src/java-gen (or something like that), and modify
maven.xml to add that location to the maven.src.path (is that the right
property?).
what do others do out there?
Ryan
-
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: 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 of generated source
Where do most maven developers place generated files (ex: xdoclet)?
I've been developing a maven project for the past 6 months and have been
dumping all generated files into 'target' to avoid saving into CVS.
Now,
with over 200 generated classes, and little change, I'd like to avoid
having
xdoclet run EACH java:compile. So, here are my two options as I see
them:
1. create a separate subproject, and have the generated interfaces
saved
in
src/java to appease maven. Add a task into maven.xml to regenerate
the
classes only when needed.
2. save the files in src/java-gen (or something like that), and modify
maven.xml to add that location to the maven.src.path (is that the right
property?).
what do others do out there?
Ryan
-
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: location of generated source
One other thing
http://ant.apache.org/manual/CoreTasks/uptodate.html
maybe you can do the uptodate test yourself to see if it's necessary to run
xdoclet.
- Original Message -
From: Kevin Hagel [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 1:28 PM
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 of generated source
Where do most maven developers place generated files (ex: xdoclet)?
I've been developing a maven project for the past 6 months and have
been
dumping all generated files into 'target' to avoid saving into CVS.
Now,
with over 200 generated classes, and little change, I'd like to avoid
having
xdoclet run EACH java:compile. So, here are my two options as I see
them:
1. create a separate subproject, and have the generated interfaces
saved
in
src/java to appease maven. Add a task into maven.xml to regenerate
the
classes only when needed.
2. save the files in src/java-gen (or something like that), and
modify
maven.xml to add that location to the maven.src.path (is that the
right
property?).
what do others do out there?
Ryan
-
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: 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 of generated source
Where do most maven developers place generated files (ex: xdoclet)?
I've been developing a maven project for the past 6 months and have
been
dumping all generated files into 'target' to avoid saving into CVS.
Now,
with over 200 generated classes, and little change, I'd like to avoid
having
xdoclet run EACH java:compile. So, here are my two options as I see
them:
1. create a separate subproject, and have the generated interfaces
saved
in
src/java to appease maven. Add a task into maven.xml to regenerate
the
classes only when needed.
2. save the files in src/java-gen (or something like that), and
modify
maven.xml to add that location to the maven.src.path (is that the
right
property?).
what do others do out there?
Ryan
-
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
