RES: Re: Maven-Geotools
You can find a bunch of geotools artifacts at http://maven.geotools.fr/repository and use them as dependencies of your Maven project. Hope it helps. Dário -Mensagem original- De: news [mailto:[EMAIL PROTECTED] Em nome de Jan Torben Heuer Enviada em: quarta-feira, 5 de março de 2008 07:32 Para: users@maven.apache.org Assunto: Re: Maven-Geotools Hi, Is it a must that we need to use maven to create a geotools project? Or is there anyway in which we can use the geotools library directly? Its basically to read a shapefile. You should ask this question on a geotools list rather than here. Who knows geotools? Ok, me ;-), so once upon a time when maven was still alpha I wanted to do exactly the same as you. Geotools is not just a jarfile, no it is a bunch of jarfiles and I finally gave up because there were always a dependency missing. So what I want to tell you is, that you CAN do it without maven, but It is even more complicated. Jan P.S can you configure your client to create a mail without a broken indentation? Looks wired... -- quote well - get answers - 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]
RES: Referencing uniqe SNAPSHOT versions in POM
In the same way as it were non-unique: just use x.y-SNAPSHOT for instance. If do not want unique snasphot version in your repo, you'll have to add the following to distributionManagement section: distributionManagement snapshotRepository ... uniqueVersionfalse/uniqueVersion /snapshotRepository ... Dário -Mensagem original- De: Marco Bakera [mailto:[EMAIL PROTECTED] Enviada em: sexta-feira, 8 de fevereiro de 2008 09:41 Para: Maven Users Assunto: Referencing uniqe SNAPSHOT versions in POM Hey everybody! Sometime I find SNAPSHOT versions in the repository like groupid/artifactid/SNAPSHOT/artifactid-20071218.1329060-1.jar. It seems that this are SNAPSHOTS uniquely identifiable via some identifier. But how can I refer to such a version from my dependency section in my pom? Thanks for help and greetings, Marco. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: Referencing uniqe SNAPSHOT versions in POM
Please attach your pom file so I can take a look at it. Dário -Mensagem original- De: Marco Bakera [mailto:[EMAIL PROTECTED] Enviada em: sexta-feira, 8 de fevereiro de 2008 11:01 Para: users@maven.apache.org Assunto: Re: Referencing uniqe SNAPSHOT versions in POM Sorry neither your nor Dario's solution solves the problem. :( However thanks for your help so far. On Friday 08 February 2008 13:50:17 nicolas de loof wrote: Simply use version20071218.1329060-1/version Maven will automatically detect this is a SNAPSHOT (using metadatas.xml in repo AFAIK) The latest (snapshot) release plugin accepts them as valid. You just have to ensure there will be available in future for your build to be reproductible (make a repo backup or use a corporate repo/proxy) Nico. 2008/2/8, Marco Bakera [EMAIL PROTECTED]: Hey everybody! Sometime I find SNAPSHOT versions in the repository like groupid/artifactid/SNAPSHOT/artifactid-20071218.1329060-1.jar. It seems that this are SNAPSHOTS uniquely identifiable via some identifier. But how can I refer to such a version from my dependency section in my pom? Thanks for help and greetings, Marco. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RES: release:perform failing due to missing project artifact
Try to add the following argument to 'mvn release:prepare' command: -DpreparationGoals=clean install The default is clean verify. Hope it helps. Dário -Mensagem original- De: Reuben Firmin [mailto:[EMAIL PROTECTED] Enviada em: quarta-feira, 17 de outubro de 2007 15:19 Para: users@maven.apache.org Assunto: release:perform failing due to missing project artifact Hello, I'm confused by a release:perform failure. I ran mvn deploy ; mvn release:prepare ; mvn release:peform. The perform failed with the error: [INFO] Failed to resolve artifact. Missing: -- 1) benetech:benetech-core:jar:1.1.1 benetech-core is a sub-module; from my super pom: modules modulebenetech-core/module modulebookshare-core/module modulebookshare-core-web/module modulebookshare-web/module /modules When I ran the deploy, the project was on version 1.1.1-SNAPSHOT , and that version is fully built out in both my local repository and my org-local repository: -rw-r--r-- 1 reuben reuben 225423 2007-10-17 07:29 benetech-core-1.1.1-20071017.142840-1.jar ... [many files] -rw-r--r-- 1 reuben reuben309 2007-10-17 09:00 maven-metadata-local.xml However, my local repository only contains a pom.xml for version 1.1.1 (created, presumably, by the release:prepare step), and the org-local repository doesn't contain 1.1.1 at all (as would be expected, because, as above, the version when the deploy was run was 1.1.1-SNAPSHOT). So, am I missing a step in the deploy / release process? Thanks Reuben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven archiva] weird behaviour when running archiva on different operating systems
Hi, I've been trying to use Archiva, but I've noticed some weird stuff when setting it up and running it on different OS, such as Windows 2000 and Linux (Fedora Core 5). FYI I am using Archiva 1.0-Alpha-2, Java 5 Update 12 and Maven 2.0.7. For example, if I edit my settings.xml to point to a Windows 2000 Archiva Repo and execute 'mvn clean' in a simple maven project, everything works fine, i.e., Maven looks up for artifacts in the internal repo and if it does not find them, they are downloaded and added to internal repo. Now if I change my settings to point to a Linux Archiva Repo, none artifact will be downloaded to internal repo and the Archiva logs a message, as shown below, informing that they are not part of defined whitelist (skipping transfer). +++ source:ArchivaRepository[internal,file://l/disk0/repository/m2/internal/public/releases] target:ArchivaRepository[central,http://repo1.maven.org/maven2] proxyId:null policy[releases]:once policy[checksum]:fix policy[snapshots]:disabled policy[cache-failures]:cached ] 562923 [SocketListener0-3] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Using target repository: central - layout: default - targetPath: org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.pom 562923 [SocketListener0-3] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [releases] policy with [once] 562923 [SocketListener0-3] DEBUG org.apache.maven.archiva.policies.PreDownloadPolicy:releases - OK to update releases, local file does not exist. 562923 [SocketListener0-3] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [snapshots] policy with [disabled] 562923 [SocketListener0-3] DEBUG org.apache.maven.archiva.policies.PreDownloadPolicy:snapshots - OK to update, snapshot policy does not apply for non-snapshot versions. 562923 [SocketListener0-3] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [cache-failures] policy with [cached] 562924 [SocketListener0-3] DEBUG org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to fetch, check-failures detected no issues. 562924 [SocketListener0-3] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Path [org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.pom] is not part of defined whitelist (skipping transfer). +++ However the proxy connector configuration for central repo is the same on both of them. If I remove the whitelist from the archiva.xml, then it will work. I could not understand why it worked on Windows 2000 and not Linux since the code is the same. Has anyone had any similar problem with Archiva on Linux ? Thanks, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] MOJO: project.getArtifacts() question
Hi all, I've created a MOJO recently for generating all dependencies (including transitives) of a project into a .properties file and in order to do that I've used the getArtifacts() method and added '@requiresDependencyResolution runtime' into it. It works fine in most cases, except when one of my project dependencies is of EAR type as it does not bring its transitive dependencies. Please see my project dependency tree below. project-a - commons-logging.jar - project-b.jar - log4j.jar - project-c.ear - project-d.war If add my plugin to package phase of 'project-a' and execute 'mvn package', the getArtifacts() method will get all dependencies, but 'project-d.war'. I noticed that transitive dependencies work well when dealing with JAR artifacts, but not with EAR. Is that an expected behaviour ? If so what would the best way to get all of them. FYI I've created a workaround by identifying which artifact is of EAR type (as a result of getArtifacts()), retrieving its MavenProject instance using MavenProjectBuilder and invoking getDependencies() on it. However, I feel like that's not the right way to do it. Could anyone please give me any pointers ? Thanks, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] best way to have an offline internal repository
Thanks for the reply. As a matter of fact packaging is not really my problem. Assembly plug-in would definitely do that work. What I am trying to do is to create an offline environment where a user could compile a maven project without having to search for artifacts on either internet or intranet. So I was thinking of packaging a repo together with my maven project and as far as I know I would have to convert a local repo to a remote one if I wanted to use this repo as if it were a mirror of central (please see thread [M2] Howto Set Up Quickly an Offline Internal Repository? for more info). Any thoughts ? Dário -Original Message- From: Henry Isidro [mailto:[EMAIL PROTECTED] Sent: terça-feira, 29 de maio de 2007 22:10 To: Maven Users List Subject: Re: [m2] best way to have an offline internal repository Dário Luís Coneglian Oliveros wrote: Hi there, I've been reading several threads about having an offline internal repository and I wonder if there's any maven plugin or tool that can help on this matter as of now. I've heard of a repository builder, but could not find much information about it.FYI I use Proximity as my proxy/proactive mirror. Basically I want to create a package that encompasses a maven project and its repo so any user who uses it can build this project offline. Any suggestions ? Any help is appreciated. Dário Oliveros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm not sure if this would help but the assembly plugin could package a repository into a zip. You could try checking it out. HTH, Henry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] best way to have an offline internal repository
Hi Tamás, That would definitely be an option. But still you have to ask a final user to fire up the proximity server in order to build a simple project, unless proximixity does not need to be up and running. Basically I'd expect to have something similiar with ant where you could package an ant project and its dependencies and let a final user unpacks and builds the project without doing anything else. So I thought that creating a remote repo from a local one would help solve this issue since the target repo could be used and accessed via file protocol and be sitting on the client side. I will most likely follow your suggestions unless there's any plugin or tool that does the repo conversion. Dário -Original Message- From: Tamás Cservenák [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 30 de maio de 2007 09:15 To: Maven Users List Subject: Re: [m2] best way to have an offline internal repository Ha Dario, Proximity is able to work in offline mode, and offer only it's cache content. So: 0. prepare remote repo content for proximity (collect artifacts you need for your build) 1. place proximity into offline mode and give it the prepared remote repo content 2. fire it up locally 3. redirect all reposes from m2 to local proximity (m2 settings.xml) These steps could be handled by your local package... The step 0. is easily implemted: erase local repo and erase proximity content and build agains proximity ONLINE. At the end of the build, you will end up with remote repo with the needed content, ready to package and redistribute. ~t~ On 5/29/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Hi there, I've been reading several threads about having an offline internal repository and I wonder if there's any maven plugin or tool that can help on this matter as of now. I've heard of a repository builder, but could not find much information about it.FYI I use Proximity as my proxy/proactive mirror. Basically I want to create a package that encompasses a maven project and its repo so any user who uses it can build this project offline. Any suggestions ? Any help is appreciated. Dário Oliveros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] best way to have an offline internal repository
Hi Tamás, Thanks for the info. That's most likely the best solution so far. I think I'll go with this one. Regards, Dário -Original Message- From: Tamás Cservenák [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 30 de maio de 2007 10:38 To: Maven Users List Subject: Re: [m2] best way to have an offline internal repository Hi, proximity holds it's cache in UNMODIFIED M2 remote repository format. So, you can use proximity to grab remote reposes with needed artifacts and metadatas (as I described before) and M2 can use it's cache directly. Simply redirect M2 to use local FS with proximity cache content as remote repo. Proximity is needed for preparation only (made by you), a good settings.xml is needed for this to work on client side (others doing offline compile). Altough, i'm not sure is this the right way to go from M2 aspect, but it could solve the problem :) ~t~ On 5/30/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Hi Tamás, That would definitely be an option. But still you have to ask a final user to fire up the proximity server in order to build a simple project, unless proximixity does not need to be up and running. Basically I'd expect to have something similiar with ant where you could package an ant project and its dependencies and let a final user unpacks and builds the project without doing anything else. So I thought that creating a remote repo from a local one would help solve this issue since the target repo could be used and accessed via file protocol and be sitting on the client side. I will most likely follow your suggestions unless there's any plugin or tool that does the repo conversion. Dário -Original Message- From: Tamás Cservenák [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 30 de maio de 2007 09:15 To: Maven Users List Subject: Re: [m2] best way to have an offline internal repository Ha Dario, Proximity is able to work in offline mode, and offer only it's cache content. So: 0. prepare remote repo content for proximity (collect artifacts you need for your build) 1. place proximity into offline mode and give it the prepared remote repo content 2. fire it up locally 3. redirect all reposes from m2 to local proximity (m2 settings.xml) These steps could be handled by your local package... The step 0. is easily implemted: erase local repo and erase proximity content and build agains proximity ONLINE. At the end of the build, you will end up with remote repo with the needed content, ready to package and redistribute. ~t~ On 5/29/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Hi there, I've been reading several threads about having an offline internal repository and I wonder if there's any maven plugin or tool that can help on this matter as of now. I've heard of a repository builder, but could not find much information about it.FYI I use Proximity as my proxy/proactive mirror. Basically I want to create a package that encompasses a maven project and its repo so any user who uses it can build this project offline. Any suggestions ? Any help is appreciated. Dário Oliveros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] best way to have an offline internal repository
Hi there, I've been reading several threads about having an offline internal repository and I wonder if there's any maven plugin or tool that can help on this matter as of now. I've heard of a repository builder, but could not find much information about it.FYI I use Proximity as my proxy/proactive mirror. Basically I want to create a package that encompasses a maven project and its repo so any user who uses it can build this project offline. Any suggestions ? Any help is appreciated. Dário Oliveros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] any estimate for the next maven-ejb-plugin release (2.1) ?
I would suggest to create an alpha or beta release for maven-ejb-plugin since the 2.1-SNAPSHOT has some important fixes, such as the clientExcludes. It's been a long time since the last release came up. How does it sound ? -Original Message- From: Dário Luís Coneglian Oliveros Sent: segunda-feira, 15 de janeiro de 2007 10:14 To: Maven Users List Subject: RE: [m2] any estimate for the next maven-ejb-plugin release (2.1) ? Hi Wayne, There's a bug with clientExcludes that is already fixed in the SNAPSHOT. Before I start making local changes, I'd like to know whether there's any plan to release it soon. Dário -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 12 de janeiro de 2007 18:00 To: Maven Users List Subject: Re: [m2] any estimate for the next maven-ejb-plugin release (2.1) ? I know the Maven Dev team is working on M2.0.5 along with some new plugin releases right now, so perhaps they can look at m-ejb-p once those releases are all done. Unsure when the next release will be available; you'd need to check with the developer(s) responsible for m-ejb-p to be sure. I'm curious why you want to know when it will be released -- are there specific JIRA bugs with patches available that you would like to be applied to have another release cut? In the meantime, you can pull the m-ejb-p code down from SVN, apply the patches, and release it under your own version number or groupId if you require some specific bug fixes until they make a formal release. Wayne On 1/12/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Does anyone know when maven-ejb-plugin 2.1 will be released ? Thanks, Dário - 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: Maven 2 and xdoclet 1.2 and sample
Here it goes.
...
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdxdoclet-maven-plugin/artifactId
executions
execution
phasegenerate-sources/phase
goals
goalxdoclet/goal
/goals
configuration
tasks
ejbdoclet
ejbspec = 2.0
ejbClassNameSuffix = Bean
destdir = ${project.build.directory}/generated-sources/xdoclet
verbose = true
fileset dir = ${project.build.sourceDirectory} includes =
**/**Bean.java/
deploymentdescriptor destdir =
${project.build.outputDirectory}/META-INF/
jboss destdir = ${project.build.outputDirectory}/META-INF/
homeinterface/
remoteinterface/
localinterface/
localhomeinterface/
utilobject/
entitypk/
/ejbdoclet
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
...
Hope it helps.
Dário
-Original Message-
From: Vidya Mahavadi [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 24 de janeiro de 2007 10:27
To: users@maven.apache.org
Subject: Maven 2 and xdoclet 1.2 and sample
Hi everyone,
I am starting to work on Maven, xdoclet now. I am looking a for a plugin
to work with Maven 2 and xdoclet 1.2 and sample to get me started. Can
anyone please help me?
Thanks,
This e-mail is subject to a disclaimer, available at
http://www.rmb.co.za/web/elements.nsf/online/disclaimer-communications.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] any estimate for the next maven-ejb-plugin release (2.1) ?
Hi Wayne, I just sent an email to the developers list and hopefully we will get a feedback soon. BTW, I've downloaded the 2.0 plugin from svn, made some local changes in order to fix the clientExcludes bug, replaced the artifact version with 2.0.x and install it locally. Now I want to make it available in my corporate repo so any project can use my customized ejb-plugin. Even though this plugin was deployed successfully and my settings were updated to add the new plugin repository, my project is not able to use my customized plugin for some reason. I get the following error: [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-ejb-plugin:2.0.1:ejb': Unable to find the mojo 'org.apache.maven.plugins:maven-ejb-plugin:2.0.x:ejb' in the plugin 'org.apache.maven.plugins:maven-ejb-plugin' Any idea ? Dário -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 24 de janeiro de 2007 13:17 To: Maven Users List Subject: Re: [m2] any estimate for the next maven-ejb-plugin release (2.1) ? It sounds fine. But you'll need to get the ear of the person responsible for m-e-p as neither of us (in this conversation) have any ability to push a build (alpha, beta, or final) out. Wayne On 1/24/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: I would suggest to create an alpha or beta release for maven-ejb-plugin since the 2.1-SNAPSHOT has some important fixes, such as the clientExcludes. It's been a long time since the last release came up. How does it sound ? -Original Message- From: Dário Luís Coneglian Oliveros Sent: segunda-feira, 15 de janeiro de 2007 10:14 To: Maven Users List Subject: RE: [m2] any estimate for the next maven-ejb-plugin release (2.1) ? Hi Wayne, There's a bug with clientExcludes that is already fixed in the SNAPSHOT. Before I start making local changes, I'd like to know whether there's any plan to release it soon. Dário -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 12 de janeiro de 2007 18:00 To: Maven Users List Subject: Re: [m2] any estimate for the next maven-ejb-plugin release (2.1) ? I know the Maven Dev team is working on M2.0.5 along with some new plugin releases right now, so perhaps they can look at m-ejb-p once those releases are all done. Unsure when the next release will be available; you'd need to check with the developer(s) responsible for m-ejb-p to be sure. I'm curious why you want to know when it will be released -- are there specific JIRA bugs with patches available that you would like to be applied to have another release cut? In the meantime, you can pull the m-ejb-p code down from SVN, apply the patches, and release it under your own version number or groupId if you require some specific bug fixes until they make a formal release. Wayne On 1/12/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Does anyone know when maven-ejb-plugin 2.1 will be released ? Thanks, Dário - 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 2 and xdoclet 1.2 and sample
I haven´t tried that before, but I guess you have to use wseedoclet in your
configuration in the same way as ejbdoclet.
Dário
-Original Message-
From: Vidya Mahavadi [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 24 de janeiro de 2007 12:20
To: Maven Users List
Subject: RE: Maven 2 and xdoclet 1.2 and sample
Hi,
Thanks for your response,
That really works. I am trying to create a webservice with an ejb. I am
using the following configuraion and xdoclet in the ejb. What plugin do I
need to put pom.xml to generate wsdl file from the xdoclet..
Cofiguration:
Maven2, Xdoclet1.2, JBoss3.2.5, Axis1.1, Jboss.net
Xdoclet:
/**
* @ejb:beanname=AmendmentsService
* jndi-name=AmendmentsService
* type=Stateless
* view-type=both
*
* @ejb:ejb-ref ejb-name=AmendmentsService
* view-type=remote
* ref-name=ejb/AmendmentsService
*
* @ejb:util generate=physical
*
*
* @jboss.ejb-ref-jndi ref-name=AmendmentsService
* jndi-name=AmendmentsService
*
* @jboss-net:web-service urn=AmendmentsService
*
**/
Thanks,
Dário Luís Coneglian Oliveros [EMAIL PROTECTED]
24/01/2007 15:35
Please respond to
Maven Users List users@maven.apache.org
To
Maven Users List users@maven.apache.org
cc
Subject
RE: Maven 2 and xdoclet 1.2 and sample
Here it goes.
...
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdxdoclet-maven-plugin/artifactId
executions
execution
phasegenerate-sources/phase
goals
goalxdoclet/goal
/goals
configuration
tasks
ejbdoclet
ejbspec = 2.0
ejbClassNameSuffix = Bean
destdir =
${project.build.directory}/generated-sources/xdoclet
verbose = true
fileset dir = ${project.build.sourceDirectory} includes
= **/**Bean.java/
deploymentdescriptor destdir =
${project.build.outputDirectory}/META-INF/
jboss destdir =
${project.build.outputDirectory}/META-INF/
homeinterface/
remoteinterface/
localinterface/
localhomeinterface/
utilobject/
entitypk/
/ejbdoclet
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
...
Hope it helps.
Dário
-Original Message-
From: Vidya Mahavadi [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 24 de janeiro de 2007 10:27
To: users@maven.apache.org
Subject: Maven 2 and xdoclet 1.2 and sample
Hi everyone,
I am starting to work on Maven, xdoclet now. I am looking a for a plugin
to work with Maven 2 and xdoclet 1.2 and sample to get me started. Can
anyone please help me?
Thanks,
This e-mail is subject to a disclaimer, available at
http://www.rmb.co.za/web/elements.nsf/online/disclaimer-communications.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail is subject to a disclaimer, available at
http://www.rmb.co.za/web/elements.nsf/online/disclaimer-communications.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Out of memory error
Hi Jeff, Not really. You can either create an artifact that contains your checkstyle config file and add it to your project as a dependency or you could specify its URL. Personally I would recommend the second one. Here's a snippet of my pom.xml. ... configuration configLocationhttp://your.domain.goes.here/jeff_checks.xml/configLocation /configuration ... You could also use file:// if you want to. Dário -Original Message- From: Jeff Mutonho [mailto:[EMAIL PROTECTED] Sent: terça-feira, 23 de janeiro de 2007 05:32 To: Maven Users List Subject: Re: Out of memory error On 1/22/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: I've faced the same problem. It seems to be a bug in the checkstyle plugin. I've noticed it happens only if there are too many checkstyle errors. My suggestion is to decrease this number to about 1 (hopefully most of them are tab related). It should work. Do not ask me why :-) Dário I'm looking at the maven-checkstyle-plugin in my pom and it says , configLocationconfig/sun_checks.xml/configLocation I understand that sun_checks.xml is located in the config directory , in the plugin jar.If I wish to specify my own as : configLocationjeffs-checks.xml/configLocation The plugin documentation says that when one specifies a custom check-style file as above it causes the Maven 2 Checkstyle plugin to check for a File named checkstyle.xml or a resource named checkstyle.xml within the compile scope of the dependencies or build extensions classpath. From this , does that mean jeffs-checks.xml above should be located in the same directory as the pom.xml? Jeff Mutonho Cape Town South Africa GoogleTalk : ejbengine Skype: ejbengine Registered Linux user number 366042 - 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: Out of memory error
I've faced the same problem. It seems to be a bug in the checkstyle plugin. I've noticed it happens only if there are too many checkstyle errors. My suggestion is to decrease this number to about 1 (hopefully most of them are tab related). It should work. Do not ask me why :-) Dário -Original Message- From: Jeff Mutonho [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 22 de janeiro de 2007 11:00 To: Maven Users List Subject: Out of memory error I'm experiencing a java.lang.OutOfMemoryError during my build ,when it get to generating a checkstyle report as shown below: [INFO] Working directory: /app/maven/MAVEN-WORK/continuum/working-directory/86/eportal-webservices/src [INFO] Generate Developer Activity report. [INFO] Using existing changelog.xml... [INFO] Generate File Activity report. [INFO] Using existing changelog.xml... [INFO] Generate Checkstyle report. [INFO] There are 35293 checkstyle errors. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.OutOfMemoryError [INFO] [INFO] Total time: 1 minute 31 seconds [INFO] Finished at: Mon Jan 22 14:01:43 SAST 2007 [INFO] Final Memory: 31M/63M [INFO] My build machine is a Solaris box and the build is invoked by Continuum.I've edited my .profile file and added the following to it: MAVEN_OPTS=-Xmx1024m -Xms1024m -XX:MaxPermSize=512m; export MAVEN_OPTS I'm still getting the error message even with the MAVEN_OPTS environment variable set.Do I need to set it in a different file? -- Jeff Mutonho Cape Town South Africa GoogleTalk : ejbengine Skype: ejbengine Registered Linux user number 366042 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven2 and unknown protocol: e
That's an expected behaviour. You must provide at least one goal when running 'mvn'. If you already have a maven 2 project, change to its directory and run 'mvn clean' or 'mvn install'. -Original Message- From: Khabot, Zakaria [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 19 de janeiro de 2007 07:29 To: Maven Users List Subject: RE: Maven2 and unknown protocol: e Hi, Thanks for your contribution. When I tape mvn --version I receive : Maven version 2.0.4. In my classpath of Eclipse I defined a variable : M2_REPO = C:/Documents and Settings/user/.m2/repository When I run mvn -X + Error stacktraces are turned on. Maven version: 2.0.4 [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settin gs\user\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'E:\Softs\maven-2.0.4\ bin\..\conf\plugin-registry.xml' [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] You must specify at least one goal. Try 'install' [INFO] [DEBUG] Trace org.apache.maven.BuildFailureException: You must specify at least one goal. Try 'install' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:132) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) I still have the same exception Thanks for help. -Message d'origine- De : Dário Luís Coneglian Oliveros [mailto:[EMAIL PROTECTED] Envoyé : jeudi 18 janvier 2007 20:24 À : Maven Users List Objet : RE: Maven2 and unknown protocol: e It seems like your maven installation at E:\Softs\maven-2.0.4 is not 2.0.4, but 1.0.2. The reason why is Maven 2 uses classworlds to load some classes instead of Forehead, which is not the case as shown in the stack trace below. Besides Maven 2 does not come with endorsed dir under lib. Also the default local repository for Maven 2 is located by default at user home/.m2/repository. Hope it helps. Dário -Original Message- From: Khabot, Zakaria [mailto:[EMAIL PROTECTED] Sent: quinta-feira, 18 de janeiro de 2007 16:53 To: Maven Users List Subject: Maven2 and unknown protocol: e Hi all, I was using Maven 1.0.2 and it works fine. I migrated to maven 2.0.4 but when I try to execute a goal I have this exception: File or url 'E:\Softs\maven-2.0.4/lib/endorsed/xml-apis-1.0.b2.jar' could not be found java.net.MalformedURLException: unknown protocol: e at java.net.URL.init(URL.java:574) at java.net.URL.init(URL.java:464) at java.net.URL.init(URL.java:413) at com.werken.forehead.Forehead.loadFileOrUrl(Forehead.java:403) at com.werken.forehead.Forehead.load(Forehead.java:322) at com.werken.forehead.Forehead.config(Forehead.java:245) at com.werken.forehead.Forehead.config(Forehead.java:131) at com.werken.forehead.Forehead.main(Forehead.java:579) I specified that my repo is user\.maven\repository The jar exists in this repo but why is he searching in 'E:\Softs\maven-2.0.4/lib Thanks in advance. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] could not locate maven-surefire-plugin in svn repo
Thanks a lot. -Original Message- From: Lasse Koskela [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 17 de janeiro de 2007 19:44 To: Maven Users List Subject: Re: [m2] could not locate maven-surefire-plugin in svn repo Hi Dario, On 1/17/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Could anoyne please tell me what happened to maven-surefire-plugin ? I couldn't find it at http://svn.apache.org/repos/asf/maven/plugins/trunk as stated in its site - http://maven.apache.org/plugins/maven-surefire-plugin/index.html. Thanks, Dário It's under http://svn.apache.org/repos/asf/maven/surefire/trunk/ Lasse - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] maven-surefire-plugin 2.1.3 vs 2.2
I noticed maven-surefire-plugin 2.1.3 uses forkMode='none' and childDelegation='true' as default. However If I add the same configuration to maven-surefire-plugin 2.2, my tests don't work. Since I use javolution.jar as a test dependency and it overrides some classes from java.lang.reflect, I get a 'prohibited package name' error. The same problem does not happen to 2.1.3. Any thoughts ? Any idea where to look at ? Dário -Original Message- From: Dário Luís Coneglian Oliveros Sent: quarta-feira, 17 de janeiro de 2007 16:13 To: Maven Users List (E-mail) Subject: [m2] maven-surefire-plugin 2.1.3 vs 2.2 I have some test cases that used to work with maven-surefire-plugin 2.1.3, but not with 2.2. Does anybody know what kind of configuration should be in 2.2 to get the same behaviour as of 2.1.3 ? I've tried a couple of them (forkMode=never, childDelegation=true), but could not get anything working. Any help is appreciated. Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] maven-surefire-plugin 2.1.3 vs 2.2 [solved]
I just figured out my test cases were failing because the geotools map transformation used by them does not work when assertions are enabled. Since maven-surefire-plugin enables them by default, I had to add the following configuration to the plugin. ... plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.2/version configuration argLine-disableassertions:org.geotools.../argLine /configuration /plugin ... Hope someone find this info useful. Dário -Original Message- From: Dário Luís Coneglian Oliveros Sent: quinta-feira, 18 de janeiro de 2007 09:35 To: Maven Users List Subject: RE: [m2] maven-surefire-plugin 2.1.3 vs 2.2 I noticed maven-surefire-plugin 2.1.3 uses forkMode='none' and childDelegation='true' as default. However If I add the same configuration to maven-surefire-plugin 2.2, my tests don't work. Since I use javolution.jar as a test dependency and it overrides some classes from java.lang.reflect, I get a 'prohibited package name' error. The same problem does not happen to 2.1.3. Any thoughts ? Any idea where to look at ? Dário -Original Message- From: Dário Luís Coneglian Oliveros Sent: quarta-feira, 17 de janeiro de 2007 16:13 To: Maven Users List (E-mail) Subject: [m2] maven-surefire-plugin 2.1.3 vs 2.2 I have some test cases that used to work with maven-surefire-plugin 2.1.3, but not with 2.2. Does anybody know what kind of configuration should be in 2.2 to get the same behaviour as of 2.1.3 ? I've tried a couple of them (forkMode=never, childDelegation=true), but could not get anything working. Any help is appreciated. Dário - 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: Maven2 and unknown protocol: e
It seems like your maven installation at E:\Softs\maven-2.0.4 is not 2.0.4, but 1.0.2. The reason why is Maven 2 uses classworlds to load some classes instead of Forehead, which is not the case as shown in the stack trace below. Besides Maven 2 does not come with endorsed dir under lib. Also the default local repository for Maven 2 is located by default at user home/.m2/repository. Hope it helps. Dário -Original Message- From: Khabot, Zakaria [mailto:[EMAIL PROTECTED] Sent: quinta-feira, 18 de janeiro de 2007 16:53 To: Maven Users List Subject: Maven2 and unknown protocol: e Hi all, I was using Maven 1.0.2 and it works fine. I migrated to maven 2.0.4 but when I try to execute a goal I have this exception: File or url 'E:\Softs\maven-2.0.4/lib/endorsed/xml-apis-1.0.b2.jar' could not be found java.net.MalformedURLException: unknown protocol: e at java.net.URL.init(URL.java:574) at java.net.URL.init(URL.java:464) at java.net.URL.init(URL.java:413) at com.werken.forehead.Forehead.loadFileOrUrl(Forehead.java:403) at com.werken.forehead.Forehead.load(Forehead.java:322) at com.werken.forehead.Forehead.config(Forehead.java:245) at com.werken.forehead.Forehead.config(Forehead.java:131) at com.werken.forehead.Forehead.main(Forehead.java:579) I specified that my repo is user\.maven\repository The jar exists in this repo but why is he searching in 'E:\Softs\maven-2.0.4/lib Thanks in advance. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] maven-surefire-plugin 2.1.3 vs 2.2
I have some test cases that used to work with maven-surefire-plugin 2.1.3, but not with 2.2. Does anybody know what kind of configuration should be in 2.2 to get the same behaviour as of 2.1.3 ? I've tried a couple of them (forkMode=never, childDelegation=true), but could not get anything working. Any help is appreciated. Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] could not locate maven-surefire-plugin in svn repo
Could anoyne please tell me what happened to maven-surefire-plugin ? I couldn't find it at http://svn.apache.org/repos/asf/maven/plugins/trunk as stated in its site - http://maven.apache.org/plugins/maven-surefire-plugin/index.html. Thanks, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] any estimate for the next maven-ejb-plugin release (2.1) ?
Hi Wayne, There's a bug with clientExcludes that is already fixed in the SNAPSHOT. Before I start making local changes, I'd like to know whether there's any plan to release it soon. Dário -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 12 de janeiro de 2007 18:00 To: Maven Users List Subject: Re: [m2] any estimate for the next maven-ejb-plugin release (2.1) ? I know the Maven Dev team is working on M2.0.5 along with some new plugin releases right now, so perhaps they can look at m-ejb-p once those releases are all done. Unsure when the next release will be available; you'd need to check with the developer(s) responsible for m-ejb-p to be sure. I'm curious why you want to know when it will be released -- are there specific JIRA bugs with patches available that you would like to be applied to have another release cut? In the meantime, you can pull the m-ejb-p code down from SVN, apply the patches, and release it under your own version number or groupId if you require some specific bug fixes until they make a formal release. Wayne On 1/12/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Does anyone know when maven-ejb-plugin 2.1 will be released ? Thanks, Dário - 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]
[m2] any estimate for the next maven-ejb-plugin release (2.1) ?
Does anyone know when maven-ejb-plugin 2.1 will be released ? Thanks, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] maven-changes-plugin - icons are not being displayed
I did see the sample changes report and even though my changes.xml was pretty
much the same as maven-changes-plugin's
(http://svn.apache.org/viewvc/maven/plugins/trunk/maven-changes-plugin/src/site/changes/sample-changes.xml?view=markup),
it did not work for me.
Here's an excerpt of my pom.xml:
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
configuration
xmlPath${basedir}/src/site/changes/changes.xml/xmlPath
/configuration
reportSets
reportSet
reports
reportchanges-report/report
/reports
/reportSet
/reportSets
/plugin
...
Any help is appreciated.
Dário
-Original Message-
From: Dennis Lundberg [mailto:[EMAIL PROTECTED]
Sent: terça-feira, 2 de janeiro de 2007 19:54
To: Maven Users List
Subject: Re: [m2] maven-changes-plugin - icons are not being displayed
Dário Luís Coneglian Oliveros wrote:
Hi there,
The changes report generated by running 'mvn site' does not display any icon
of add, update or fix (from changes.xml).
Any clues ? Is this a known bug ?
Thanks,
Dário
It's working for me.
See also the Sample Changes Report that is generated for the plugin site
for a working example:
http://maven.apache.org/plugins/maven-changes-plugin/changes-report.html
--
Dennis Lundberg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] any tips for site internationalization ?
Hi Wayne, I am still not sure if a JIRA issue could be opened in this case. According to the instructions for translators at maven site plugin (http://maven.apache.org/plugins/maven-site-plugin/i18n.html), any translation (for instance, site-plugin_pt_BR.properties) should be saved with UTF-8 encoding. And the way I made it work was to save it with ISO-8859-1 encoding instead. Moreover there's another open issue (http://jira.codehaus.org/browse/MSITE-19) that is supposed to fix these encoding problems. Unfortunately it's taking too long to get them fixed. So until MSITE-19 is not closed I may stick with the workaround unless I get a thumbs up to add these new properties files for pt_BR (ISO-8859-1 encoding) in the maven-site-plugin trunk. Any thoughts ? Dário -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: terça-feira, 2 de janeiro de 2007 18:46 To: Maven Users List Subject: Re: [m2] any tips for site internationalization ? Hi Dario, If you're reasonably convinced these encodings are invalid, please open a JIRA bug so someone can resolve them. Wayne On 1/2/07, Dário Oliveros [EMAIL PROTECTED] wrote: Happy New Year to everyone ! Dennis, Thanks for the info. In fact I was aware of this issue already, but since it was taking too long to get it fixed, I decided to check whether anyone had a workaround. Anyway it turned out that I found why site internationalization was not working for brazilian portuguese (pt_BR) and most likely german too. That was because their properties files from maven-site-plugin and maven-project-info-reports-plugin were using UTF-8 as default encoding instead of ISO-8859-1. After updating them manually in my local repository, I could get my site internationalized. I've decided to make that change because Velocity uses ISO-8859-1 as input and output encoding. Besides if you take a look at the french and spanish properties files, you'll see their enconding are ISO-8859-1 as well. I hope this encoding issue gets fixed in the next site plugin release. Dário dennisl-2 wrote: Dário Oliveros wrote: Hi there, I've been struggling to generate a fully internationalized website and I was wondering if anyone was able to get it working. Any tips ? FYI, my site source files (located at site/xdoc directory) have ISO-8859-1 encoding and my site.xml, UTF-8. And my maven-site-plugin settings are localespt_br/locales and outputEncodingUTF-8/outputEncoding. However, every time the site is generated, the left side menu (site.xml) and the project info characters are messed up. It has something to do with encoding, but I am not able to figure it out. Any help is welcome. Dário You might find something helpful in this issue: http://jira.codehaus.org/browse/MSITE-19 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--any-tips-for-site-internationalization---tf2898463s177.html#a8127461 Sent from the Maven - Users mailing list archive at Nabble.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] any tips for site internationalization ?
That's correct, however the internationalization instructions at maven site plugin say that any translation should be saved with UTF-8 encoding. Dário -Original Message- From: Heinrich Nirschl [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 3 de janeiro de 2007 14:03 To: Maven Users List Subject: Re: [m2] any tips for site internationalization ? On 1/3/07, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Hi Wayne, I am still not sure if a JIRA issue could be opened in this case. According to the instructions for translators at maven site plugin (http://maven.apache.org/plugins/maven-site-plugin/i18n.html), any translation (for instance, site-plugin_pt_BR.properties) should be saved with UTF-8 encoding. And the way I made it work was to save it with ISO-8859-1 encoding instead. Moreover there's another open issue (http://jira.codehaus.org/browse/MSITE-19) that is supposed to fix these encoding problems. Unfortunately it's taking too long to get them fixed. So until MSITE-19 is not closed I may stick with the workaround unless I get a thumbs up to add these new properties files for pt_BR (ISO-8859-1 encoding) in the maven-site-plugin trunk. Any thoughts ? My understanding of http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html is that property files have to be encoded in ISO-8859-1 Henry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] any tips for site internationalization ?
Happy New Year to everyone ! Dennis, Thanks for the info. In fact I was aware of this issue already, but since it was taking too long to get it fixed, I decided to check whether anyone had a workaround. Anyway it turned out that I found why site internationalization was not working for brazilian portuguese (pt_BR) and most likely german too. That was because their properties files from maven-site-plugin and maven-project-info-reports-plugin were using UTF-8 as default encoding instead of ISO-8859-1. After updating them manually in my local repository, I could get my site internationalized. I've decided to make that change because Velocity uses ISO-8859-1 as input and output encoding. Besides if you take a look at the french and spanish properties files, you'll see their enconding are ISO-8859-1 as well. I hope this encoding issue gets fixed in the next site plugin release. Dário -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: sábado, 30 de dezembro de 2006 12:05 To: Maven Users List Subject: Re: [m2] any tips for site internationalization ? Dário Oliveros wrote: Hi there, I've been struggling to generate a fully internationalized website and I was wondering if anyone was able to get it working. Any tips ? FYI, my site source files (located at site/xdoc directory) have ISO-8859-1 encoding and my site.xml, UTF-8. And my maven-site-plugin settings are localespt_br/locales and outputEncodingUTF-8/outputEncoding. However, every time the site is generated, the left side menu (site.xml) and the project info characters are messed up. It has something to do with encoding, but I am not able to figure it out. Any help is welcome. Dário You might find something helpful in this issue: http://jira.codehaus.org/browse/MSITE-19 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] maven-changes-plugin - icons are not being displayed
Hi there, The changes report generated by running 'mvn site' does not display any icon of add, update or fix (from changes.xml). Any clues ? Is this a known bug ? Thanks, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ear file doesnt contain war and jar
Hi Karthik,
I have an EAR project using M2 that does something similar, but it works for me
though. All the artifacts as added into the final EAR.
I can´t think of a reason why yours is not working, since it´s quite similar to
mine.
You may check if the super pom already define some of the dependencies and that
may be causing the problem. It´s just a guess.
my pom.xml
--
project
parent
groupIdwhatever/groupId
artifactIdroot-project/artifactId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
groupIdwhatever/groupId
artifactIdear-project/artifactId
version1.0-SNAPSHOT/version
packagingear/packaging
dependencies
dependency
groupIdwhatever/groupId
artifactIdjava-project/artifactId
version1.0-SNAPSHOT/version
typejar/type
/dependency
dependency
groupIdwhatever/groupId
artifactIdejb-project/artifactId
version1.0-SNAPSHOT/version
typeejb/type
/dependency
dependency
groupIdwhatever/groupId
artifactIdweb-project/artifactId
version1.0-SNAPSHOT/version
typewar/type
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
/plugin
/plugins
/build
/project
Regards,
Dário
-Original Message-
From: Karthik V [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 18 de janeiro de 2006 14:09
To: Maven Users List
Subject: Re: Ear file doesnt contain war and jar
Hi Henry,
Below is my ear projects pom ... I've *** ed the proprietary stuff ... I'm
trying to include abc-bean.jar, abc-war.war and commons-collection.jar into
the ear file (in the directory i need) ... Note that, I tried the
javamodule section (now commented) but it didnt work ...
project
modelVersion4.0.0/modelVersion
groupId***/groupId
version1.0/version
artifactIdabc-ear/artifactId
nameABC Ear/name
packagingear/packaging
parent
groupId***/groupId
version1.0/version
artifactId***/artifactId
/parent
dependencyManagement
dependencies
dependency
groupId***/groupId
version1.0/version
artifactIdabc-bean/artifactId
typejar/type
/dependency
dependency
groupId***/groupId
version1.0/version
artifactIdabc-war/artifactId
typewar/type
/dependency
dependency
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
version2.1.1/version
typejar/type
/dependency
/dependencies
/dependencyManagement
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
modules
!-- javaModule
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
includeInApplicationXmltrue/includeInApplicationXml
/javaModule --
/modules
applicationXml${basedir}/src/main/resources/META-INF/application.xml/applicationXml
/configuration
/plugin
/plugins
resources
resource
directory${basedir}/src/main/resources/directory
/resource
/resources
/build
/project
On 1/17/06, Henry Isidro [EMAIL PROTECTED] wrote:
Hi Karthik V,
The properties tag for dependencies are no longer suppported. Can you
post your pom so that we can see what you are actually doing?
Regards,
Henry
Karthik V wrote:
looks like things have changed :( ... the properties tag is not being
recognized.
On 1/17/06, Max Cooper [EMAIL PROTECTED] wrote:
Note: this is for Maven 1 (1.0.2, 1.1-beta-2, I don't know if anything
has changed for Maven 2)
In the ear project where you specify the dependencies, you specify
properties to tell the ear plugin what to do with your jars and wars.
Here's an example:
!-- ejb jar --
dependency
groupIdmyproject/groupId
artifactIdejb/artifactId
version${pom.currentVersion}/version
typeejb/type
properties
ear.bundletrue/ear.bundle
/properties
/dependency
!-- war --
dependency
groupIdmyproject/groupId
artifactIdweb/artifactId
version${pom.currentVersion}/version
typewar/type
properties
ear.bundletrue/ear.bundle
ear.appxml.war.context-root//ear.appxml.war.context-root
/properties
/dependency
!-- utility jar --
dependency
groupIdmyproject/groupId
artifactIdutil/artifactId
version${pom.currentVersion}/version
typejar/type
properties
ear.moduletrue/ear.module
/properties
/dependency
This is all described at the bottom of this page:
http://maven.apache.org/maven-1.x/reference/plugins/ear/properties.html
Note that the ear.bundle.dir property will allow you to control the
directory (inside the ear file) where the dependency ends up.
-Max
On Tue, 2006-01-17 at 13:18 -0500, Karthik V wrote:
when someone answers this question, please give a
RE: [m2] maven-ear-plugin: why is the includeInApplicationXml set to false by default ?
Thanks a lot. Regards, Dário -Original Message- From: Stephane Nicoll [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 16 de dezembro de 2005 10:57 To: Maven Users List Subject: Re: [m2] maven-ear-plugin: why is the includeInApplicationXml set to false by default ? Hello, This is the expected behavior. Java modules should not be set in the application.xml (see the spec). Instead you should refer them in the Class-Path entry of the manifest file. However, if you want to include it in the application.xml anyway, you can set this property to true. Hope it helps, Stéphane On 12/15/05, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Hi there, I´ve been looking at the maven-ear-plugin and noticed the 'includeInApplicationXml' instance variable of JavaModule class is set to false by default. However, when using this plugin the jar artifacts are never placed as entries in the application.xml unless you specify them in the configuration section as java modules, which could be hard to do because of the transitive dependencies (please refer to thread '[m2] ear plugin: jar does not get added to application xml ...') Is this a bug or an expected behaviour ? Thanks in advance, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which variables are available, e.g. for thexdoclet-maven-plugin?
Hi,
AFAIK this variable (project.build.outputDirectory) comes from pom.xml as
follows:
project
...
build
outputDirectorytarget/classes/outputDirectory
/build
...
/project
Hope this helps.
Dário
-Original Message-
From: Stefan Rademacher [mailto:[EMAIL PROTECTED]
Sent: segunda-feira, 19 de dezembro de 2005 13:35
To: Maven Users List
Subject: Which variables are available, e.g. for
thexdoclet-maven-plugin?
Hello,
on the page for the xdoclet-maven-plugin there is an example, which
contains a variable ${project.build.outputDirectory}.
Where can I find out generally, which variables are available in a
pom.xml? And another question is: Can I define my own variables
somwhere?
Would be great, if anyone can tell me.
Bye,
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] ear plugin: jar does not get added to application xml (as java module)
Hi Edwin, I´ve read this guide before, however it focus on customization only. According to the ear plugin, the descriptor deployment (application.xml) is generated automatically and by doing so the plugin should add into it all the dependencies as java, ejb and/or web modules. That´s not happening for jar artifacts though. Besides it´s not viable to manually add all jars (transitive dependencies) in the customization section as java modules. Regards, Dário -Original Message- From: Edwin Punzalan [mailto:[EMAIL PROTECTED] Sent: quinta-feira, 15 de dezembro de 2005 01:14 To: Maven Users List Subject: Re: [m2] ear plugin: jar does not get added to application xml (as java module) The ejb plugin has configuration elements for the application.xml. Please see: http://maven.apache.org/plugins/maven-ear-plugin/howto.html Dário Luís Coneglian Oliveros wrote: Hi, I´ve been trying to create an EAR that contains a JAR, an EJB JAR (depends on JAR) and a WAR, however only EJB JAR and WAR gets added to the application.xml as ejb and web modules respectively. The JAR is not added at all. This used to work in Maven 1. How can I have an entry of JAR in the application.xml as a java module ? Do I need to add it manually ? I´ve noticed that all dependency jars are added to the EAR (depending on the scope), but they are not present in the application.xml as java modules. Should I report a bug or this is an expected behaviour ? Please find below my POM: project modelVersion4.0.0/modelVersion groupIdcom.mycompany.sample/groupId artifactIdsample-ear/artifactId packagingear/packaging version1.0-SNAPSHOT/version dependencies dependency groupIdcom.mycompany.sample/groupId artifactIdsample-java/artifactId version1.0-SNAPSHOT/version /dependency dependency groupIdcom.mycompany.sample/groupId artifactIdsample-ejb/artifactId version1.0-SNAPSHOT/version typeejb/type /dependency dependency groupIdcom.mycompany.sample/groupId artifactIdsample-web/artifactId version1.0-SNAPSHOT/version typewar/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId /plugin /plugins /build /project application.xml -- application display-namesample-ear/display-name module ejbsample-ejb-1.0-SNAPSHOT.jar/ejb /module module web web-urisample-web-1.0-SNAPSHOT.war/web-uri context-root/sample-web/context-root /web /module /application Any clues ? I am not sure if that´s the right way to create an EAR. I would appreciate any help. Thanks in advance, Dário - 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: [m2.0.1] ambiguous subtask definition
Thanks for the information. After sending the email, I realized the problem was happening to 2.0 as well. So please ignore that comment :-) Regards, Dário -Original Message- From: Peschier J. (Jeroen) [mailto:[EMAIL PROTECTED] Sent: quinta-feira, 15 de dezembro de 2005 14:16 To: Maven Users List Subject: RE: [m2.0.1] ambiguous subtask definition It's a XDoclet bug, not Maven's, see http://opensource2.atlassian.com/projects/xdoclet/browse/XDT-1435 http://opensource2.atlassian.com/projects/xdoclet/browse/XDT-86 I am curious though, how it would work on 2.0 and not on 2.0.1? I find the same behaviour for 2.0 and 2.0.1 on this issue. -Oorspronkelijk bericht- Van: Dário Luís Coneglian Oliveros [mailto:[EMAIL PROTECTED] Verzonden: woensdag 14 december 2005 18:55 Aan: Maven Users List Onderwerp: [m2.0.1] ambiguous subtask definition Hi all, After upgrading to 2.0.1, I started getting an error when compiling a multi-module project that contains modules using ejbdoclet and webdoclet respectively. It says Embedded error: Ambiguous subtask definition for logical name service-endpoint: xdoclet.modules.ejb.intf.ServiceEndpointSubTask and xdoclet.modules.web.ServiceEndpointSubTask. If I compile each module separatedly, then it works fine. Any clues ? Regards, Dário - 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]
[m2] maven-ear-plugin: why is the includeInApplicationXml set to false by default ?
Hi there, I´ve been looking at the maven-ear-plugin and noticed the 'includeInApplicationXml' instance variable of JavaModule class is set to false by default. However, when using this plugin the jar artifacts are never placed as entries in the application.xml unless you specify them in the configuration section as java modules, which could be hard to do because of the transitive dependencies (please refer to thread '[m2] ear plugin: jar does not get added to application xml ...') Is this a bug or an expected behaviour ? Thanks in advance, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2 xdoclet Null Pointer Exception
Hi Uli, Please try to use the xdoclet maven plugin from codehaus. I am not sure if it´s gonna work. Just give a shot and let me know the results. plugin groupIdorg.codehaus.mojo/groupId artifactIdxdoclet-maven-plugin/artifactId version1.0-alpha-2/version ... Regards, Dário -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: sábado, 10 de dezembro de 2005 12:05 To: users@maven.apache.org Subject: Maven 2 xdoclet Null Pointer Exception Hello, i'm new to m2 and i want to move a little project with xdoclet for hibernate mapping from ant to maven 2. I'm not sure if i'm on the right way.. I've added to the generated pom following : build plugins plugin groupIdxdoclet/groupId artifactIdmaven-xdoclet-plugin/artifactId version1.2/version executions execution phasegenerate-sources/phase goals goalxdoclet/goal /goals configuration tasks !-- here i think must be the hibernatedoclet : -- /tasks /configuration /execution /executions /plugin /plugins /build Question 1: With this i get following error in a mvn compile: [DEBUG] maven-resources-plugin: resolved to version 2.0 from repository central [DEBUG] Retrieving parent-POM from the repository for project: null:maven-resour ces-plugin:maven-plugin:2.0 [DEBUG] maven-compiler-plugin: resolved to version 2.0 from repository central [DEBUG] Retrieving parent-POM from the repository for project: null:maven-compil er-plugin:maven-plugin:2.0 [INFO] - --- [ERROR] FATAL ERROR [INFO] - --- [INFO] null [INFO] - --- [DEBUG] Trace java.lang.NullPointerException at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginM anager.java:292) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(De faultPluginManager.java:198) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPlug inManager.java:163) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Defa ultLifecycleExecutor.java:1095) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifec ycle(DefaultLifecycleExecutor.java:1060) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycl eMappings(DefaultLifecycleExecutor.java:869) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:301) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:137) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] - Question 2: Are the paramters for hibernatedoclet like the hibernatedoclet -ant-task? Hope that sounds not too stupid, but in my web researches i got nothing what this explain.. Uli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Standard directory layout for generated sources
Hi there, When looking at the standard layout directory, I thought it would be great to have a common directory for the generated sources also since Maven already has a generate-sources lifecycle phase. This way we don´t need to tell the compiler where to find the generated sources. Please let me know any comments on this. Thanks, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Standard directory layout for generated sources
Hi Jochen, One way to avoid the problem you mentioned is to have something like: - target - generated - src - main - java - resources - test - java ... This way we would keep a similar Maven directory layout for the generated files. [Jochen] Why do you need to tell the compiler that there is a new source directory? This is the plugins task and it should do so automatically? [Dário] In case we use plugins such as ejbdoclet, hibernatedoclet and so on. When using any of these, you end up having your files generated somewhere. Thus you need to tell Maven where to find them in order to compile them. Having a standard layout for generated files, this setting could be defined implicitly. Do you know how a plugin could tell Maven on the fly about the existence of a new source directory ? If this is possible, then a plugin could have its own generated directory and inform it to Maven. Despite I still think it would be great to have a standard directory layout for generated files. Regards, Dário -Original Message- From: Jochen Wiedmann [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 14 de dezembro de 2005 09:32 To: Maven Users List Subject: Re: [m2] Standard directory layout for generated sources On 12/14/05, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: When looking at the standard layout directory, I thought it would be great to have a common directory for the generated sources also since Maven already has a generate-sources lifecycle phase. This way we don´t need to tell the compiler where to find the generated sources. I disagree. First of all, a single directory woudn't be sufficient: For example, you generate not only sources, but also resources. Both may be generated for tests as well. So we end up with four. Besides, it is not unusual to process one generators files with another generator. In other words, the formers output directory becomes the latters input directory. But, what makes me wonder the most: Why do you need to tell the compiler that there is a new source directory? This is the plugins task and it should do so automatically? Jochen -- Often it does seem a pity that Noah and his party did not miss the boat. (Mark Twain) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] ear plugin: jar does not get added to application xml (as java module)
Hi, I´ve been trying to create an EAR that contains a JAR, an EJB JAR (depends on JAR) and a WAR, however only EJB JAR and WAR gets added to the application.xml as ejb and web modules respectively. The JAR is not added at all. This used to work in Maven 1. How can I have an entry of JAR in the application.xml as a java module ? Do I need to add it manually ? I´ve noticed that all dependency jars are added to the EAR (depending on the scope), but they are not present in the application.xml as java modules. Should I report a bug or this is an expected behaviour ? Please find below my POM: project modelVersion4.0.0/modelVersion groupIdcom.mycompany.sample/groupId artifactIdsample-ear/artifactId packagingear/packaging version1.0-SNAPSHOT/version dependencies dependency groupIdcom.mycompany.sample/groupId artifactIdsample-java/artifactId version1.0-SNAPSHOT/version /dependency dependency groupIdcom.mycompany.sample/groupId artifactIdsample-ejb/artifactId version1.0-SNAPSHOT/version typeejb/type /dependency dependency groupIdcom.mycompany.sample/groupId artifactIdsample-web/artifactId version1.0-SNAPSHOT/version typewar/type /dependency /dependencies build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId /plugin /plugins /build /project application.xml -- application display-namesample-ear/display-name module ejbsample-ejb-1.0-SNAPSHOT.jar/ejb /module module web web-urisample-web-1.0-SNAPSHOT.war/web-uri context-root/sample-web/context-root /web /module /application Any clues ? I am not sure if that´s the right way to create an EAR. I would appreciate any help. Thanks in advance, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2.0.1] ambiguous subtask definition
Hi all, After upgrading to 2.0.1, I started getting an error when compiling a multi-module project that contains modules using ejbdoclet and webdoclet respectively. It says Embedded error: Ambiguous subtask definition for logical name service-endpoint: xdoclet.modules.ejb.intf.ServiceEndpointSubTask and xdoclet.modules.web.ServiceEndpointSubTask. If I compile each module separatedly, then it works fine. Any clues ? Regards, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Standard directory layout for generated sources
Hi John,
Thanks a lot. I appreciated it.
I was wondering if this could be documented in the Introduction to the
Standard Directory Layout and/or Plug-in Development Guide sections. This
way plugin developers would have an idea of the standard layout for generated
code before going towards implementation.
Regards,
Dário
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 14 de dezembro de 2005 16:47
To: Maven Users List
Subject: Re: [m2] Standard directory layout for generated sources
We already have some default standards for generation of code. First,
code should be generated into:
${project.build.directory}/generated-sources/${plugin-prefix}
Correspondingly, generated resources would go in:
${project.build.directory}/generated-resources/${plugin-prefix}
This accommodates multiple code generators within the same build
process, with no pollution of one by another. Tracking these new
source/resource locations is easy; in your plugin, simply call:
project.addCompileSourceRoot(..);
project.addResource(..);
Of course, we also define analogous structures for test sources/resources.
We've found in the past that this offers a pretty good compromise
between a clean structure per generating plugin, and simplicity of
directory layouts. The full-scale src/(main|test)/(java|resources)
directory structure isn't that useful in this case, since the generated
sources/resources will not have to be maintained.
HTH,
John
Dário Luís Coneglian Oliveros wrote:
Hi Jochen,
One way to avoid the problem you mentioned is to have something like:
- target
- generated
- src
- main
- java
- resources
- test
- java
...
This way we would keep a similar Maven directory layout for the generated
files.
[Jochen] Why do you need to tell the compiler that there is a new source
directory? This is the plugins task and it should do so automatically?
[Dário] In case we use plugins such as ejbdoclet, hibernatedoclet and so on.
When using any of these, you end up having your files generated somewhere.
Thus you need to tell Maven where to find them in order to compile them.
Having a standard layout for generated files, this setting could be defined
implicitly.
Do you know how a plugin could tell Maven on the fly about the existence of a
new source directory ? If this is possible, then a plugin could have its own
generated directory and inform it to Maven. Despite I still think it would be
great to have a standard directory layout for generated files.
Regards,
Dário
-Original Message-
From: Jochen Wiedmann [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 14 de dezembro de 2005 09:32
To: Maven Users List
Subject: Re: [m2] Standard directory layout for generated sources
On 12/14/05, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote:
When looking at the standard layout directory, I thought it would be great
to have a common directory for the generated sources also since Maven
already has a generate-sources lifecycle phase. This way we don´t need to
tell the compiler where to find the generated sources.
I disagree. First of all, a single directory woudn't be sufficient:
For example, you generate not only sources, but also resources. Both
may be generated for tests as well. So we end up with four. Besides,
it is not unusual to process one generators files with another
generator. In other words, the formers output directory becomes the
latters input directory.
But, what makes me wonder the most: Why do you need to tell the
compiler that there is a new source directory? This is the plugins
task and it should do so automatically?
Jochen
--
Often it does seem a pity that Noah and his party did not miss the
boat. (Mark Twain)
-
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: [m2] new ejbdoclet+webdoclet plugin announcement
Hi there,
After a couple of attempts I got the webdoclet working. I´ve used the xdoclet
plugin with a webdoclet task. Please see POM below:
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdxdoclet-maven-plugin/artifactId
version1.0-alpha-2/version
executions
execution
phasegenerate-sources/phase
goals
goalxdoclet/goal
/goals
configuration
tasks
webdoclet
destdir=${project.build.directory}/generated-sources/xdoclet
fileset dir=${basedir}/src/main/java
includes=**/*Servlet.java/
deploymentdescriptor
destdir=${project.build.directory}/generated-sources/xdoclet/META-INF/
/webdoclet
/tasks
/configuration
/execution
/executions
/plugin
/plugins
Note that I had to provide the 'destdir' attribute. Hope this can be default in
the future.
Regards,
Dário
-Original Message-
From: Dário Luís Coneglian Oliveros
Sent: terça-feira, 6 de dezembro de 2005 15:59
To: Maven Users List
Subject: RE: [m2] new ejbdoclet+webdoclet plugin announcement
Hi Ashley,
I´ve been having problem with the webdoclet plugin and can´t figure out how to
get it working.
Still not sure which plugin to use (xdoclet or webdoclet) nor its respective
repository.
Here´s a snippet of my POM:
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdxdoclet-maven-plugin/artifactId
version1.0-alpha-2/version
executions
execution
phasegenerate-sources/phase
goals
goalxdoclet/goal
/goals
configuration
task![CDATA[
webdoclet
fileset includes=**/*Servlet.java/
deploymentdescriptor/
/webdoclet
]]/task
/configuration
/execution
/executions
/plugin
/plugins
It seems that no action is taken when running 'mvn compile' even though it
displays that task was executed. See output below:
[INFO] [xdoclet:xdoclet {execution: default}]
[INFO] Initializing DocletTasks!!!
[INFO] Executing tasks
[INFO] Executed tasks
Then I tried to change the POM by replacing the plugins section according to
https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/webdoclet-maven-plugin/sample-ear-proj/trading-web/pom.xml.
No success at all. This time the webdoclet-maven-plugin couldn´t be found.
Output
--
Reason: Unable to download the artifact from any repository
org.codehaus.mojo:webdoclet-maven-plugin:1.0-beta-1:pom
--
Any tips ?
Thanks,
Dário
-Original Message-
From: Ashley Williams [mailto:[EMAIL PROTECTED]
Sent: sexta-feira, 25 de novembro de 2005 09:03
To: Maven Users List
Subject: Re: [m2] new ejbdoclet+webdoclet plugin announcement
Hi Marcel,
Reading between the lines I think you are asking if you need to have
an ant
installation on your machine - the answer is no, since the plugin
brings in
ant as one of its dependencies.
Some background: everybody has their own theory but mine is that
maven intends
to replace all of the functionality of the ant tasks out there - and
as a long term
goal I see no problem with that. However in the short term I see the
following problems:
1. I need stuff that works well right now and can't wait for months
and years. Even
when we do get maven replacements they won't have had the advantage
of being
extensively user tested for quite some time.
2. Everybody knows ant syntax so familiarity is a big plus for
somebody coming to maven
for the first time. I do wish that even when pure maven replacements
come along they would
retain syntax compatibility with a reasonable subset of ant.
3. With the other ant integration stuff we already have in maven we
don't have the
ability to easily map maven properties to ant attributes (correct me
if I'm wrong). For me this
seemingly small point ends up being a real killer as I personally
find it very troublesome
to supply values such as destDir={project.output}/generated-sources/
main/java (see I've
probably got that wrong and I'd have to look it up!!!) by hand and
keep them all synchronized.
4. I create a temporary build file because I really can't get to
grips with the slippery
ant api. Many methods are be private so I'd have to use reflection,
also seeing problems
such as running tasks individually would work but run them as part of
the same build
would fail. Glad to abandon that approach.
---
On balance I do look forward to the ant-maven integration plugins
being retired
but can't see it happening any time soon.
- Ashley
On 25 Nov 2005, at 08:11, Marcel Dullaart wrote:
Hi Ashley,
sounds good, I'll try-out the webdoclet ASAP.
Since you create an ant script on the fly, does that mean that
using
RE: [m2] new ejbdoclet+webdoclet plugin announcement
Hi Ashley,
I´ve been having problem with the webdoclet plugin and can´t figure out how to
get it working.
Still not sure which plugin to use (xdoclet or webdoclet) nor its respective
repository.
Here´s a snippet of my POM:
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdxdoclet-maven-plugin/artifactId
version1.0-alpha-2/version
executions
execution
phasegenerate-sources/phase
goals
goalxdoclet/goal
/goals
configuration
task![CDATA[
webdoclet
fileset includes=**/*Servlet.java/
deploymentdescriptor/
/webdoclet
]]/task
/configuration
/execution
/executions
/plugin
/plugins
It seems that no action is taken when running 'mvn compile' even though it
displays that task was executed. See output below:
[INFO] [xdoclet:xdoclet {execution: default}]
[INFO] Initializing DocletTasks!!!
[INFO] Executing tasks
[INFO] Executed tasks
Then I tried to change the POM by replacing the plugins section according to
https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/webdoclet-maven-plugin/sample-ear-proj/trading-web/pom.xml.
No success at all. This time the webdoclet-maven-plugin couldn´t be found.
Output
--
Reason: Unable to download the artifact from any repository
org.codehaus.mojo:webdoclet-maven-plugin:1.0-beta-1:pom
--
Any tips ?
Thanks,
Dário
-Original Message-
From: Ashley Williams [mailto:[EMAIL PROTECTED]
Sent: sexta-feira, 25 de novembro de 2005 09:03
To: Maven Users List
Subject: Re: [m2] new ejbdoclet+webdoclet plugin announcement
Hi Marcel,
Reading between the lines I think you are asking if you need to have
an ant
installation on your machine - the answer is no, since the plugin
brings in
ant as one of its dependencies.
Some background: everybody has their own theory but mine is that
maven intends
to replace all of the functionality of the ant tasks out there - and
as a long term
goal I see no problem with that. However in the short term I see the
following problems:
1. I need stuff that works well right now and can't wait for months
and years. Even
when we do get maven replacements they won't have had the advantage
of being
extensively user tested for quite some time.
2. Everybody knows ant syntax so familiarity is a big plus for
somebody coming to maven
for the first time. I do wish that even when pure maven replacements
come along they would
retain syntax compatibility with a reasonable subset of ant.
3. With the other ant integration stuff we already have in maven we
don't have the
ability to easily map maven properties to ant attributes (correct me
if I'm wrong). For me this
seemingly small point ends up being a real killer as I personally
find it very troublesome
to supply values such as destDir={project.output}/generated-sources/
main/java (see I've
probably got that wrong and I'd have to look it up!!!) by hand and
keep them all synchronized.
4. I create a temporary build file because I really can't get to
grips with the slippery
ant api. Many methods are be private so I'd have to use reflection,
also seeing problems
such as running tasks individually would work but run them as part of
the same build
would fail. Glad to abandon that approach.
---
On balance I do look forward to the ant-maven integration plugins
being retired
but can't see it happening any time soon.
- Ashley
On 25 Nov 2005, at 08:11, Marcel Dullaart wrote:
Hi Ashley,
sounds good, I'll try-out the webdoclet ASAP.
Since you create an ant script on the fly, does that mean that
using your
xdoclet plugin requires ant?
Is that a good idea?
Cheers,
Marcel
Ashley Williams [EMAIL PROTECTED] wrote on 25-11-2005 01:08:04:
I have placed new ejbdoclet and webdoclet plugins in the sandbox here
https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/
And to see their use in a sample ear project try the following link:
https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/sample-ear-
proj/
---
Briefly they provide the following features:
1. Familiar ant xdoclet syntax can be used in configuration
2. Maven properties are automatically applied to the ant task - for
example
you don't have to specify attributes such as destDir=target/
generated-sources,
because the plugin applies a list of known mappings!
3. Can execute plugins in the same mvn session - eg a pom.xml that
kicks off
an ejb and then web build won't bomb out.
4. Works by creating an actual build.xml file on the fly.
- Ashley
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Maven 2 and Jelly
Hi there, Does anybody happen to know what Jelly future will be since Maven 2 does not depend on it anymore ? I couldn´t find a Jelly roadmap. As far as I know most of people who have learned Jelly in the past did it because they needed to develop Maven 1.x plugins. Any comments will be appreciated. Thanks, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2 and Jelly
Glad to hear that ! Thanks Dion ! -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 26 de outubro de 2005 09:57 To: Maven Users List Subject: Re: Maven 2 and Jelly Dario, none of us working on Jelly have stopped. Some of us will continue to use Jelly with Maven 1.x, as the move to m2 is costly. Many use Jelly as a standalone templating engine like velocity. On 10/26/05, Dário Luís Coneglian Oliveros [EMAIL PROTECTED] wrote: Thanks Vincent. I know Jelly is a different project and has nothing to do with Maven. However it seems to me most of Jelly enhacements were driven by needs that arose from Maven 1.x. Most of Jelly code that is available on internet are Maven 1.x plugins, which let me think most of people who learned Jelly did it in order to develop Maven plugins. I´ve been trying to get information about Jelly roadmap, but haven´t found anything so far. I am quite concerned with Jelly future because I think it´s a really powerful scripting language. It´s independent of platform, easy to use and pluggable, not to mention all the other features. Thanks, Dário -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 26 de outubro de 2005 08:28 To: 'Maven Users List' Subject: RE: Maven 2 and Jelly -Original Message- From: Dário Luís Coneglian Oliveros [mailto:[EMAIL PROTECTED] Sent: mercredi 26 octobre 2005 12:12 To: Maven Users List Subject: Maven 2 and Jelly Hi there, Does anybody happen to know what Jelly future will be since Maven 2 does not depend on it anymore ? I couldn´t find a Jelly roadmap. As far as I know most of people who have learned Jelly in the past did it because they needed to develop Maven 1.x plugins. Any comments will be appreciated. Jelly is a separate project. It doesn't belong to the Maven project. The Maven project just used it. You should probably ask this question on the jakarta commons mailing list. My view: * I don't think we'll see much development of jelly in the future. It'll probably continue to be slowly maintained waiting for someone to be interested in it and move the development forward. * Jelly is a project without a leader and is thus in maintenance mode. Thanks -Vincent - 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] -- http://www.multitask.com.au/people/dion/ You are going to let the fear of poverty govern your life and your reward will be that you will eat, but you will not live. - George Bernard Shaw - 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: [ANN] Maven 2.0 Release Now Available
Wow ! Great job and congrats to all !!! Looking forward to starting using it. Regards, Dário Oliveros -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 19 de outubro de 2005 20:25 To: users@maven.apache.org Cc: dev@maven.apache.org Subject: [ANN] Maven 2.0 Release Now Available We are pleased to announce that Maven 2.0 has been released, and is available for download from http://maven.apache.org/maven2/download.html Maven is a build system that provides software project management and dependancy comprehension. Based on the concept of a project object model (POM), Maven manages a project's build, reporting and documentation from a central place. Maven 2.0 is a rewrite of the popular Maven application, designed to both address previous functional requirements and provide a stable platform for extending and enhancing its build management framework. This release is significantly faster and smaller than Maven 1.0 and includes the following usability and performance improvements: * Enhanced Dependency Management - includes dependency closures (transitive dependencies), version ranges, automatic build numbering, and automatic updating on a configurable interval * Defined Build Lifecycle - developers can build any type of project using standard commands such as compile, test and install * Unified Project Definition - manages all required build information in a single POM now, including project information, dependencies and plugin configuration * Extended Plugin Architecture - supports Java and scripting languages such as Beanshell for plugin development * Better Repository Support - includes separated snapshot repositories, a new more managable layout and per-project definitions of new repositories * Expanded Reactor Operation - offers built-in support for multiple projects (without the need to perform a full install cycle to compile all projects) and support for project aggregation * New Site Management Tools - supports multiple input and output formats, with input formats including wiki-like APT format and docbook, while continuing to support traditional Maven XDoc and FAQ format. * New Reporting API - offers a standardised method for producing project information and reports * And much more... The Maven 2.0 release is considered stable and includes a Maven 1.0 complete feature set, with additional functionality. The most popular Maven 1.0 plugins have been converted for Maven 2.0, and many more are available in beta. See http://docs.codehaus.org/pages/MAVEN/Maven+Plugin+Matrix for more information on particular plugins. Maven's advanced dependency management features rely on project metadata. If you are interested in improving support for the users of your project, see http://maven.apache.org/maven2/project-faq.html The Maven team would like to express thanks to the user and developer community for their beta testing, feedback and contributions that helped make the release possible! To get started with Maven now, see the getting started guide: http://maven.apache.org/maven2/guides/getting-started/index.html - 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: hello. (Maven generate reports )
Hi Sreenivas, You will be able to find these reports in XML format in the 'generated-xdocs' directory. Maven actually creates the xml documents first and then convert them to html. Hope it helps. Dário -Original Message- From: Sreenivas Mangasandra [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 4 de julho de 2005 07:18 To: users@maven.apache.org Subject: hello. (Maven generate reports ) Hello !!! The reports such as CheckStyle, Javadocs etc generated by the Maven is in the html format. Does any body know if we can we generate reports using maven into xml format, So that I can store them onto a database and later use them for some processing. Thanks. With Best regards / Mit freundlichen Grüßen Sreenivas Mangasandra, Intland Software GmbH, Wankel Str. 3, D-70563 Stuttgart, Germany. Tel.: +49 711 722 1834 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: hello. (Maven generate reports )
Hi Sreenivas, Unfortunately I don´t know the answer for your first question. Regarding the second one, you can disable the download from internet by setting the property 'maven.mode.online' to false. Another option is to create a mirror of ibiblio in your intranet and then donwload the artifacts from the new remote repository by pointing the 'maven.repo.remote' to your web server, e.g., http://www.intland.com/repository/ibiblio. Dário -Original Message- From: Sreenivas Mangasandra [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 4 de julho de 2005 09:43 To: 'Maven Users List' Subject: AW: hello. (Maven generate reports ) Hi Dário, I would like to know a few more things. Please let me know about it. How can maven be started from Java? Are there examples how to integrate maven into java applications? i.e, do we have any APIs so that we call Maven from a java program etc. Can we stop maven from not downloading the plugins during a goal completion. Since we need to integrate into a product, where it can be a local Installation without an internet connection. Shall be thankful for any ideas / suggestions.Thanks. Sreenivas. -Ursprüngliche Nachricht- Von: Dário Luís Coneglian Oliveros [mailto:[EMAIL PROTECTED] Gesendet: Montag, 4. Juli 2005 14:31 An: Maven Users List Betreff: RE: hello. (Maven generate reports ) Hi Sreenivas, You will be able to find these reports in XML format in the 'generated-xdocs' directory. Maven actually creates the xml documents first and then convert them to html. Hope it helps. Dário -Original Message- From: Sreenivas Mangasandra [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 4 de julho de 2005 07:18 To: users@maven.apache.org Subject: hello. (Maven generate reports ) Hello !!! The reports such as CheckStyle, Javadocs etc generated by the Maven is in the html format. Does any body know if we can we generate reports using maven into xml format, So that I can store them onto a database and later use them for some processing. Thanks. With Best regards / Mit freundlichen Grüßen Sreenivas Mangasandra (mksreenivas), Intland Software GmbH, Wankel Str. 3, D-70563 Stuttgart, Germany. Tel.: +49 711 722 1834 - 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: hello. (Maven generate reports )
Hi,
You sure can do that. If I am not mistaken, you should set the
maven.repo.remote to something like file://c:\\maven/repository.
Remember that there is a difference between remote and local repository. By
default all the artifacts used by maven and your project are downloaded from a
remote repository (ibiblio site) and placed under ${user.home}, which is
default local repository. That´s why you found a .maven directory under your
user home.
You can find more information on
http://maven.apache.org/reference/internal-repositories.html
Hope it helps.
Dário
-Original Message-
From: Sreenivas Mangasandra [mailto:[EMAIL PROTECTED]
Sent: segunda-feira, 4 de julho de 2005 11:20
To: 'Maven Users List'
Subject: AW: hello. (Maven generate reports )
Hi Dário,
Thanks for the answer. So it means that by using the 'maven.mode.online' we
can stop downloading of the plugins during a maven run. Could we not have a
Local folder of a PC to be pointed as the repository. I mean copy / download
the plugins from the web n then later copy them into a folder for the
repository. I shall be trying this option.
I have found a folder called .maven in the documents directory of the
user, but how does one manually copy the plugins into this directory is
Not known by me. Could let me know anything on this...
Thanks
Sreenivas.
-Ursprüngliche Nachricht-
Von: Dário Luís Coneglian Oliveros [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 4. Juli 2005 15:45
An: Maven Users List
Betreff: RE: hello. (Maven generate reports )
Hi Sreenivas,
Unfortunately I don´t know the answer for your first question.
Regarding the second one, you can disable the download from internet by
setting the property 'maven.mode.online' to false. Another option is to
create a mirror of ibiblio in your intranet and then donwload the artifacts
from the new remote repository by pointing the 'maven.repo.remote' to your
web server, e.g., http://www.intland.com/repository/ibiblio.
Dário
-Original Message-
From: Sreenivas Mangasandra [mailto:[EMAIL PROTECTED]
Sent: segunda-feira, 4 de julho de 2005 09:43
To: 'Maven Users List'
Subject: AW: hello. (Maven generate reports )
Hi Dário,
I would like to know a few more things. Please let me know about it.
How can maven be started from Java? Are there examples how to integrate
maven into java applications? i.e, do we have any APIs so that we call
Maven from a java program etc.
Can we stop maven from not downloading the plugins during a goal completion.
Since we need to integrate into a product, where it can be a local
Installation without an internet connection.
Shall be thankful for any ideas / suggestions.Thanks.
Sreenivas.
-Ursprüngliche Nachricht-
Von: Dário Luís Coneglian Oliveros [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 4. Juli 2005 14:31
An: Maven Users List
Betreff: RE: hello. (Maven generate reports )
Hi Sreenivas,
You will be able to find these reports in XML format in the
'generated-xdocs' directory.
Maven actually creates the xml documents first and then convert them to
html.
Hope it helps.
Dário
-Original Message-
From: Sreenivas Mangasandra [mailto:[EMAIL PROTECTED]
Sent: segunda-feira, 4 de julho de 2005 07:18
To: users@maven.apache.org
Subject: hello. (Maven generate reports )
Hello !!!
The reports such as CheckStyle, Javadocs etc generated by the Maven is in
the html format.
Does any body know if we can we generate reports using maven into xml
format,
So that I can store them onto a database and later use them for some
processing.
Thanks.
With Best regards / Mit freundlichen Grüßen
Sreenivas Mangasandra (mksreenivas),
Intland Software GmbH, Wankel Str. 3,
D-70563 Stuttgart, Germany.
Tel.: +49 711 722 1834
-
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]
Error when running maven-jdepend-report
Hi there. I just installed maven 1.1 beta 1, but I am having a problem when running the jdepend report. I have no clue what could be the cause, since it was working on 1.0.2. Please find below the exception I am getting: Caught exception evaluating: [EMAIL PROTECTED] Reason: java.lang.Exception: size() : null arg java.lang.Exception: size() : null arg at org.apache.commons.jexl.parser.ASTSizeFunction.value(ASTSizeFunction.java:64) at org.apache.commons.jexl.parser.ASTEQNode.value(ASTEQNode.java:48) at org.apache.commons.jexl.parser.ASTExpression.value(ASTExpression.java:47) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:86) at org.apache.commons.jelly.expression.jexl.JexlExpression.evaluate(JexlExpression.java:69) at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) at org.apache.commons.jelly.expression.ExpressionSupport.evaluateAsBoolean(ExpressionSupport.java:71) at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:44) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:288) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:288) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:288) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:247) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) . ... . I would appreciate any help. Thanks, Dário - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
