RE: Source Dir
http://mojo.codehaus.org/build-helper-maven-plugin/howto.html -Original Message- From: Arthur Rodrigues Stilben [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 4:16 PM To: Maven Users List Subject: Source Dir I wan to know if is it possible to use more than one source dir using the task sourceDirectory. Arthur Rodrigues Stilben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source Dir
I have used the build-helper-maven-plugin Maven2 plugin to achieve this. http://mojo.codehaus.org/build-helper-maven-plugin/ Arthur Rodrigues Stilben wrote: I wan to know if is it possible to use more than one source dir using the task sourceDirectory. Arthur Rodrigues Stilben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Source-Dir-tp14953985s177p14957800.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Source Dir
I wan to know if is it possible to use more than one source dir using the task sourceDirectory. Arthur Rodrigues Stilben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven2 Xdoclet Plugin - Project Source Dir
Has anyone been able to work through or dealt with using a different project source directory than src/main/java? I'm trying to get Maven2 building a legacy system. I don't have the luxury of changing the source directory. I set it in the project.build.sourceDirectory, but the xdoclet plugin doesn't pick it up. Any help would be greatly appreciated. -BA
RE: Maven2 Xdoclet Plugin - Project Source Dir
Hi Brian, I do this for one of my projects, although I am just using the jar-plugin but this should work for any plugin. In your pom.xml you sould have a build tag. At the start of the build tag, add the following: sourceDirectoryyour src path/sourceDirectory Regards, Mark From: Brian Ashburn [mailto:[EMAIL PROTECTED] Sent: Mon 12/3/2007 10:47 AM To: users@maven.apache.org Subject: Maven2 Xdoclet Plugin - Project Source Dir Has anyone been able to work through or dealt with using a different project source directory than src/main/java? I'm trying to get Maven2 building a legacy system. I don't have the luxury of changing the source directory. I set it in the project.build.sourceDirectory, but the xdoclet plugin doesn't pick it up. Any help would be greatly appreciated. -BA
Re: Update over scm-local does not delete files removed from source dir
ArneD a écrit : Emmanuel Venisse wrote: Are you sure it isn't possible to checkout sources in a specific folder with cleartool? It is possible with snapshot views. My ClearCase know-how is limited, but I am quite sure it is not possible with dynamic views. Do you think the suggested enhancement for scm-local would be useful and make sense? Not only in combination with ClearCase dynamic views but for other usage as well, e.g. testing. yes. Do you want to implement it? Regards, Arne That's true. Maybe we could enhance scm-local to keep its own metadata? In particular, scm-local could maintain a simple file, say .maven-scm-local, that contains as plain text the list of files in the source directory, as seen during the last checkout or update operation: - During checkout, the file .maven-scm-local is created in the checkout base directory. Its just a plain text file containing the list of files that have been checked out. - The update command looks for the file. If it is there, it compares the contents of that file to the current source directory contents (including subdirs). All files that are in .maven-scm-local but are no longer in the source dir, have been deleted in the source dir. The update command therefore removes them from the checkout dir. - If for whatever reason .maven-scm-local is not there, the update command won't delete any files. That way, we're backwards compatible. - After completing the update process, the update command rewrites the .maven-scm-local metadata file. - Even the changelog command can interpret .maven-scm-local - For add and checkin commands, I don't think that changes are needed. What do you think? Regards, Arne
Re: Update over scm-local does not delete files removed from source dir
my Continuum installation is accessing a file system directory using scm-local provider to get sources (BTW, the directory is on a ClearCase dynamic view). Updates are working fine as long as files are only changed or added. But when files are removed from the source directory, they still exist in the target directory. Especially after refactoring activities, this leads to build errors. Make sure you are runnning clean goal in maven. When you do a clean it should delete this info from the target directories. And that will fix your problem. BTW, you'll speed up your build if you get maven to put the target directories somewhere else, outside of the dynamic view, as dynamic views can be slow. David
Re: Update over scm-local does not delete files removed from source dir
Emmanuel Venisse wrote: Do you think the suggested enhancement for scm-local would be useful and make sense? Not only in combination with ClearCase dynamic views but for other usage as well, e.g. testing. yes. Do you want to implement it? Yes, I can try to do so and then provide a patch. Regards, Arne -- View this message in context: http://www.nabble.com/Update-over-scm-local-does-not-delete-files-removed-from-source-dir-tf2257460.html#a6303945 Sent from the Continuum - Users forum at Nabble.com.
Re: Update over scm-local does not delete files removed from source dir
ArneD a écrit : Emmanuel Venisse wrote: Do you think the suggested enhancement for scm-local would be useful and make sense? Not only in combination with ClearCase dynamic views but for other usage as well, e.g. testing. yes. Do you want to implement it? Yes, I can try to do so and then provide a patch. Cool. Thanks. Emmanuel
Re: Update over scm-local does not delete files removed from source dir
Thanks for your answer, David. continuum-3 wrote: my Continuum installation is accessing a file system directory using scm-local provider to get sources (BTW, the directory is on a ClearCase dynamic view). Updates are working fine as long as files are only changed or added. But when files are removed from the source directory, they still exist in the target directory. Especially after refactoring activities, this leads to build errors. Make sure you are runnning clean goal in maven. When you do a clean it should delete this info from the target directories. And that will fix your problem. This is what I am doing. The problem is: My project source dir resides on a dynamic view on drive Z:\VOB\some\where. My Continuum working directory is e.g. D:\continuum-work\99. What Continuum does (with help of scm-local) is to copy all files from Z:\VOB\some\where to D:\continuum-work\99 before running the build. If someone removes an outdated class from ClearCase, it won't be on Z:\VOB\some\where any longer. As scm-local currently does not delete anything from the checkout directory, the outdated class will still be there at d:\continuum-work\99. The clean goal will only delete d:\continuum-work\99\target. BTW, you'll speed up your build if you get maven to put the target directories somewhere else, outside of the dynamic view, as dynamic views can be slow. Did you manage to let Continuum operate directly on a dynamic view, in my example on Z:\VOB\some\where, without copying to a working directory? Probably you are only talking about Maven stand-alone usage. Then, I agree, it is no problem, as long as you are running the clean goal. Regards, Arne -- View this message in context: http://www.nabble.com/Update-over-scm-local-does-not-delete-files-removed-from-source-dir-tf2257460.html#a6309477 Sent from the Continuum - Users forum at Nabble.com.
Re: Update over scm-local does not delete files removed from source dir
What Continuum does (with help of scm-local) is to copy all files from Z:\VOB\some\where to D:\continuum-work\99 before running the build. If someone removes an outdated class from ClearCase, it won't be on Z:\VOB\some\where any longer. Is there a reason you can't use a snapshot view? It deals with copying the files to your C: drive for you, _and_ it deletes the old ones too. Did you manage to let Continuum operate directly on a dynamic view, in my example on Z:\VOB\some\where, without copying to a working directory? Probably you are only talking about Maven stand-alone usage. Then, I agree, it is no problem, as long as you are running the clean goal. I've not tried. I've done a manual maven build on a dynamic view and it took 43 minutes, compared to 2 minutes on my snapshot view. Bit that's mainly because my clearcase server is in another country, and behind a firewall. Don't ask! I's a latency nightnare! David
Re: Update over scm-local does not delete files removed from source dir
Emmanuel Venisse wrote: thanks a lot for your answer. A ClearCase dynamic view looks like a normal filesystem, so I think scm-local in principle is a fine solution. I think there wouldn't be much what a dedicated dynamic-view support in the Clearcase SCM provider could add. Maybe it looks like a normal filesystem, but I think the clearcase server know if files are deleted and update your local copy, right? ClearCase of course has the information. But the problem is that a ClearCase dynamic view resides on a virtual network share, e.g. \\view\some_view. You can map it to a drive letter under windows, e.g. Z:, but I don't see a way to define it in Continuum's working directory. So the files have to be copied from the dynamic view to the working directory - and that's what scm-local is doing. Couldn't the scm-local adapter consider all files that are in the checkout dir but not in the source dir as deleted? This should be easy to implement and do the job. We can't, because some users (or the build) add some files in the checkout directory like the target directory and they don't want to remove them at each build. That's true. Maybe we could enhance scm-local to keep its own metadata? In particular, scm-local could maintain a simple file, say .maven-scm-local, that contains as plain text the list of files in the source directory, as seen during the last checkout or update operation: - During checkout, the file .maven-scm-local is created in the checkout base directory. Its just a plain text file containing the list of files that have been checked out. - The update command looks for the file. If it is there, it compares the contents of that file to the current source directory contents (including subdirs). All files that are in .maven-scm-local but are no longer in the source dir, have been deleted in the source dir. The update command therefore removes them from the checkout dir. - If for whatever reason .maven-scm-local is not there, the update command won't delete any files. That way, we're backwards compatible. - After completing the update process, the update command rewrites the .maven-scm-local metadata file. - Even the changelog command can interpret .maven-scm-local - For add and checkin commands, I don't think that changes are needed. What do you think? Regards, Arne -- View this message in context: http://www.nabble.com/Update-over-scm-local-does-not-delete-files-removed-from-source-dir-tf2257460.html#a6281593 Sent from the Continuum - Users forum at Nabble.com.
Re: Update over scm-local does not delete files removed from source dir
Are you sure it isn't possible to checkout sources in a specific folder with cleartool? Emmanuel ArneD a écrit : Emmanuel Venisse wrote: thanks a lot for your answer. A ClearCase dynamic view looks like a normal filesystem, so I think scm-local in principle is a fine solution. I think there wouldn't be much what a dedicated dynamic-view support in the Clearcase SCM provider could add. Maybe it looks like a normal filesystem, but I think the clearcase server know if files are deleted and update your local copy, right? ClearCase of course has the information. But the problem is that a ClearCase dynamic view resides on a virtual network share, e.g. \\view\some_view. You can map it to a drive letter under windows, e.g. Z:, but I don't see a way to define it in Continuum's working directory. So the files have to be copied from the dynamic view to the working directory - and that's what scm-local is doing. Couldn't the scm-local adapter consider all files that are in the checkout dir but not in the source dir as deleted? This should be easy to implement and do the job. We can't, because some users (or the build) add some files in the checkout directory like the target directory and they don't want to remove them at each build. That's true. Maybe we could enhance scm-local to keep its own metadata? In particular, scm-local could maintain a simple file, say .maven-scm-local, that contains as plain text the list of files in the source directory, as seen during the last checkout or update operation: - During checkout, the file .maven-scm-local is created in the checkout base directory. Its just a plain text file containing the list of files that have been checked out. - The update command looks for the file. If it is there, it compares the contents of that file to the current source directory contents (including subdirs). All files that are in .maven-scm-local but are no longer in the source dir, have been deleted in the source dir. The update command therefore removes them from the checkout dir. - If for whatever reason .maven-scm-local is not there, the update command won't delete any files. That way, we're backwards compatible. - After completing the update process, the update command rewrites the .maven-scm-local metadata file. - Even the changelog command can interpret .maven-scm-local - For add and checkin commands, I don't think that changes are needed. What do you think? Regards, Arne
Re: Update over scm-local does not delete files removed from source dir
Emmanuel Venisse wrote: Are you sure it isn't possible to checkout sources in a specific folder with cleartool? It is possible with snapshot views. My ClearCase know-how is limited, but I am quite sure it is not possible with dynamic views. Do you think the suggested enhancement for scm-local would be useful and make sense? Not only in combination with ClearCase dynamic views but for other usage as well, e.g. testing. Regards, Arne That's true. Maybe we could enhance scm-local to keep its own metadata? In particular, scm-local could maintain a simple file, say .maven-scm-local, that contains as plain text the list of files in the source directory, as seen during the last checkout or update operation: - During checkout, the file .maven-scm-local is created in the checkout base directory. Its just a plain text file containing the list of files that have been checked out. - The update command looks for the file. If it is there, it compares the contents of that file to the current source directory contents (including subdirs). All files that are in .maven-scm-local but are no longer in the source dir, have been deleted in the source dir. The update command therefore removes them from the checkout dir. - If for whatever reason .maven-scm-local is not there, the update command won't delete any files. That way, we're backwards compatible. - After completing the update process, the update command rewrites the .maven-scm-local metadata file. - Even the changelog command can interpret .maven-scm-local - For add and checkin commands, I don't think that changes are needed. What do you think? Regards, Arne -- View this message in context: http://www.nabble.com/Update-over-scm-local-does-not-delete-files-removed-from-source-dir-tf2257460.html#a6289204 Sent from the Continuum - Users forum at Nabble.com.
Update over scm-local does not delete files removed from source dir
Hello everybody, my Continuum installation is accessing a file system directory using scm-local provider to get sources (BTW, the directory is on a ClearCase dynamic view). Updates are working fine as long as files are only changed or added. But when files are removed from the source directory, they still exist in the target directory. Especially after refactoring activities, this leads to build errors. Seems like a bug to me... Or am I missing something? Many thanks, Arne -- View this message in context: http://www.nabble.com/Update-over-scm-local-does-not-delete-files-removed-from-source-dir-tf2257460.html#a6261871 Sent from the Continuum - Users forum at Nabble.com.
Re: Update over scm-local does not delete files removed from source dir
scm-local was developped for tests and it's used in some case when a scm provider isn't available like dynamic-view support for Clearcase. It's a very simple provider that copy file from sources directory, but it can't know if some files are deleted because it doesn't have some metadata that can inform it. The only possibility you have for the moment is to remove the checkout directory and run a new build. But the best way would be to add dynamic-view support in clearcase provider. Only clearcase users will can add this features because we don't know clearcase and we don't have access to a clearcase server. Emmanuel ArneD a écrit : Hello everybody, my Continuum installation is accessing a file system directory using scm-local provider to get sources (BTW, the directory is on a ClearCase dynamic view). Updates are working fine as long as files are only changed or added. But when files are removed from the source directory, they still exist in the target directory. Especially after refactoring activities, this leads to build errors. Seems like a bug to me... Or am I missing something? Many thanks, Arne
Re: Update over scm-local does not delete files removed from source dir
Emmanuel Venisse wrote: scm-local was developped for tests and it's used in some case when a scm provider isn't available like dynamic-view support for Clearcase. It's a very simple provider that copy file from sources directory, but it can't know if some files are deleted because it doesn't have some metadata that can inform it. The only possibility you have for the moment is to remove the checkout directory and run a new build. But the best way would be to add dynamic-view support in clearcase provider. Only clearcase users will can add this features because we don't know clearcase and we don't have access to a clearcase server. Hello Emmanuel, thanks a lot for your answer. A ClearCase dynamic view looks like a normal filesystem, so I think scm-local in principle is a fine solution. I think there wouldn't be much what a dedicated dynamic-view support in the Clearcase SCM provider could add. Couldn't the scm-local adapter consider all files that are in the checkout dir but not in the source dir as deleted? This should be easy to implement and do the job. Best regards, Arne -- View this message in context: http://www.nabble.com/Update-over-scm-local-does-not-delete-files-removed-from-source-dir-tf2257460.html#a6267099 Sent from the Continuum - Users forum at Nabble.com.
Re: Update over scm-local does not delete files removed from source dir
ArneD a écrit : Emmanuel Venisse wrote: scm-local was developped for tests and it's used in some case when a scm provider isn't available like dynamic-view support for Clearcase. It's a very simple provider that copy file from sources directory, but it can't know if some files are deleted because it doesn't have some metadata that can inform it. The only possibility you have for the moment is to remove the checkout directory and run a new build. But the best way would be to add dynamic-view support in clearcase provider. Only clearcase users will can add this features because we don't know clearcase and we don't have access to a clearcase server. Hello Emmanuel, thanks a lot for your answer. A ClearCase dynamic view looks like a normal filesystem, so I think scm-local in principle is a fine solution. I think there wouldn't be much what a dedicated dynamic-view support in the Clearcase SCM provider could add. Maybe it looks like a normal filesystem, but I think the clearcase server know if files are deleted and update your local copy, right? Couldn't the scm-local adapter consider all files that are in the checkout dir but not in the source dir as deleted? This should be easy to implement and do the job. We can't, because some users (or the build) add some files in the checkout directory like the target directory and they don't want to remove them at each build. Emmanuel
Multi modules/different pom/more than one source dir
Hey everyone, as far as I know it is not possible to set the name of the pom-file when using a multi module project. The xml schema states this: xs:element name=modules minOccurs=0 xs:annotation xs:documentation source=version4.0.0/xs:documentation xs:documentation source=descriptionThe modules to build in addition to the current project/xs:documentation /xs:annotation xs:complexType xs:sequence xs:element name=module minOccurs=0 maxOccurs=unbounded type=xs:string/ /xs:sequence /xs:complexType /xs:element So my pom.xml for the project looks something like project ... modules moduleone/module moduletwo/module /modules /project I guess the default file name (i.e. pom.xml) is assumed. I can build my projects by commandline using something like mvn -f myproject.xml so why not adding an attribute to set the name of the pom file? The reason why I need this is that I have to cope with a multi source folder problem. I already know that this is regarded as being evil but I would like to introduce maven to an existing project without (much) changing the directory structure... I can solve my problem in each subproject by creating a new pom.xml and packaging this project before my real project. Any comments or suggestions? Thanks, Christopher - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi modules/different pom/more than one source dir
Hello, Well, you are right that the module / requires a directory and that the multi-module build assumes a pom.xml in every module--but it isn't what the xsd states (it only describes the elements, types and cardinality). Anyway, I would recommend that you follow the convention. It would really be easier that way since you wouldn't have to configure much. :) Cheers! Nap On 4/6/06, Christopher Cudennec [EMAIL PROTECTED] wrote: Hey everyone, as far as I know it is not possible to set the name of the pom-file when using a multi module project. The xml schema states this: xs:element name=modules minOccurs=0 xs:annotation xs:documentation source=version4.0.0/xs:documentation xs:documentation source=descriptionThe modules to build in addition to the current project/xs:documentation /xs:annotation xs:complexType xs:sequence xs:element name=module minOccurs=0 maxOccurs=unbounded type=xs:string/ /xs:sequence /xs:complexType /xs:element So my pom.xml for the project looks something like project ... modules moduleone/module moduletwo/module /modules /project I guess the default file name (i.e. pom.xml) is assumed. I can build my projects by commandline using something like mvn -f myproject.xml so why not adding an attribute to set the name of the pom file? The reason why I need this is that I have to cope with a multi source folder problem. I already know that this is regarded as being evil but I would like to introduce maven to an existing project without (much) changing the directory structure... I can solve my problem in each subproject by creating a new pom.xml and packaging this project before my real project. Any comments or suggestions? Thanks, Christopher - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2] adding source-dir within maven-antrun-plugin tasks [FIX]
http://mojo.codehaus.org/build-helper-maven-plugin/
This plugin will add additional source directories to your project.
Ruel Loehr
JBoss QA
-
512-347-7840 ext 2011
Yahoo: ruelloehr
Skype: ruelloehr
AOL: dokoruel
-Original Message-
From: Peschier J. (Jeroen) [mailto:[EMAIL PROTECTED]
Sent: Friday, January 06, 2006 7:26 AM
To: Maven Users List
Subject: RE: [M2] adding source-dir within maven-antrun-plugin tasks
One solution is to add all your directories to the maven-compile-plugin
like this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0/version
configuration
includes
include
implementation=java.lang.String../src/**/*.java/include
include
implementation=java.lang.String../generated-src/**/*.java/include
/includes
/configuration
/plugin
It's a kludge though. Other plugins won't know about the extra source
directory. I.e. the maven-eclipse-plugin will not generate multiple
source directories for you :(
There really ought to be a way to add multiple sourceDirectories in the
POM like you can with Maven 1. But the Maven developers seem dead
against it. Short of patching Maven yourself there is not real solution.
-Oorspronkelijk bericht-
Van: Jens Zastrow [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 6 januari 2006 14:04
Aan: users@maven.apache.org
Onderwerp: [M2] adding source-dir within maven-antrun-plugin tasks
Hi,
i need to use the sun-jaxb-compiler (xjc) which only seems to work
correctly with the antrun plugin.
The problem now is to put the generated .java files in a directory which
is a pom-source-folder or
one which is later added to the pom-source-folders.
Since i dont know a way to do this fromt he ant snipshet, my current -
bad - solution is to generate
them into ${basedir}/src/main/java.
Any ideas?
Thanks
jens
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasevalidate/phase
configuration
tasks
taskdef name=xjc
classname=com.sun.tools.xjc.XJCTask/
xjc
schema=src/main/xsd/de/dailab/util/jaxb/agentrole/AgentRole.xsd
package=de.dailab.util.jaxb.agentrole
target=${basedir}/src/main/java
extension=false/
copy
todir=${project.build.directory}/classes
fileset
dir=${basedir}/src/main/java excludes=**/*.java/
/copy
/tasks
/configuration
/executions
/plugin
-
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] adding source-dir within maven-antrun-plugin tasks
One solution is to add all your directories to the maven-compile-plugin
like this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0/version
configuration
includes
include
implementation=java.lang.String../src/**/*.java/include
include
implementation=java.lang.String../generated-src/**/*.java/include
/includes
/configuration
/plugin
It's a kludge though. Other plugins won't know about the extra source
directory. I.e. the maven-eclipse-plugin will not generate multiple
source directories for you :(
There really ought to be a way to add multiple sourceDirectories in the
POM like you can with Maven 1. But the Maven developers seem dead
against it. Short of patching Maven yourself there is not real solution.
-Oorspronkelijk bericht-
Van: Jens Zastrow [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 6 januari 2006 14:04
Aan: users@maven.apache.org
Onderwerp: [M2] adding source-dir within maven-antrun-plugin tasks
Hi,
i need to use the sun-jaxb-compiler (xjc) which only seems to work
correctly with the antrun plugin.
The problem now is to put the generated .java files in a directory which
is a pom-source-folder or
one which is later added to the pom-source-folders.
Since i dont know a way to do this fromt he ant snipshet, my current -
bad - solution is to generate
them into ${basedir}/src/main/java.
Any ideas?
Thanks
jens
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasevalidate/phase
configuration
tasks
taskdef name=xjc
classname=com.sun.tools.xjc.XJCTask/
xjc
schema=src/main/xsd/de/dailab/util/jaxb/agentrole/AgentRole.xsd
package=de.dailab.util.jaxb.agentrole
target=${basedir}/src/main/java
extension=false/
copy
todir=${project.build.directory}/classes
fileset
dir=${basedir}/src/main/java excludes=**/*.java/
/copy
/tasks
/configuration
/executions
/plugin
-
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] adding source-dir within maven-antrun-plugin tasks
Below is an example of how I've used Sun's XJC Ant task from Maven. The
sourceRoot tag is how I added the generated .java files to the sources
that are compiled. I also moved the generated non-java files to the
resources directory so that they would get included with the artifact
(JAR, WAR, etc.). All the dependencies were third party JARs that I had
to manually install in my repository.
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasegenerate-sources/phase
goals
goalrun/goal
/goals
/execution
/executions
configuration
tasks
taskdef name=xjc classname=com.sun.tools.xjc.XJCTask/
mkdir
dir=${project.build.directory}/generated-sources/jaxb/src/main/java/
xjc
target=${project.build.directory}/generated-sources/jaxb/src/main/java
schema=${basedir}/src/main/xsd/myschema.xsd
package=com.mypackage
produces
dir=${project.build.directory}/generated-sources/jaxb/src/main/java/com/mypackage
includes=**/* /
/xjc
mkdir
dir=${project.build.directory}/generated-sources/jaxb/src/main/resources/
move
todir=${project.build.directory}/generated-sources/jaxb/src/main/resources
preservelastmodified=true
includeEmptyDirs=false
fileset
dir=${project.build.directory}/generated-sources/jaxb/src/main/java
excludes=**/*.java /
/move
/tasks
sourceRoot${project.build.directory}/generated-sources/jaxb/src/main/java/sourceRoot
/configuration
dependencies
dependency
groupIdcom.sun.tools.xjc/groupId
artifactIdjaxb-xjc/artifactId
version1.0.5/version
/dependency
dependency
groupIdjavax.xml.bind/groupId
artifactIdjaxb-api/artifactId
version1.0.5/version
/dependency
dependency
groupIdcom.sun.xml.bind/groupId
artifactIdjaxb-impl/artifactId
version1.0.5/version
/dependency
dependency
groupIdcom.sun.xml.bind/groupId
artifactIdjaxb-libs/artifactId
version1.0.5/version
/dependency
dependency
groupIdcom.sun.xml/groupId
artifactIdxsdlib/artifactId
version20050614/version
/dependency
dependency
groupIdorg.relaxng.datatype/groupId
artifactIdrelaxngDatatype/artifactId
version1.0/version
/dependency
/dependencies
/plugin
Good luck,
Richard Allen
Jens Zastrow wrote:
Hi,
i need to use the sun-jaxb-compiler (xjc) which only seems to work
correctly with the antrun plugin.
The problem now is to put the generated .java files in a directory which
is a pom-source-folder or
one which is later added to the pom-source-folders.
Since i dont know a way to do this fromt he ant snipshet, my current -
bad - solution is to generate
them into ${basedir}/src/main/java.
Any ideas?
Thanks
jens
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasevalidate/phase
configuration
tasks
taskdef name=xjc
classname=com.sun.tools.xjc.XJCTask/
xjc
schema=src/main/xsd/de/dailab/util/jaxb/agentrole/AgentRole.xsd
package=de.dailab.util.jaxb.agentrole
target=${basedir}/src/main/java
extension=false/
copy
todir=${project.build.directory}/classes
fileset
dir=${basedir}/src/main/java excludes=**/*.java/
/copy
/tasks
/configuration
/executions
/plugin
-
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] adding source-dir within maven-antrun-plugin tasks
Antrun has two extra config options:
sourceRoot/sourceRoot
testSourceRoot/testSourceRoot
That you can use to add a directory to either the src path or test src
path. (testSourceRoot requires antrun 1.1 released on wednesday)
Dan
On Friday 06 January 2006 08:04, Jens Zastrow wrote:
Hi,
i need to use the sun-jaxb-compiler (xjc) which only seems to work
correctly with the antrun plugin.
The problem now is to put the generated .java files in a directory
which is a pom-source-folder or
one which is later added to the pom-source-folders.
Since i dont know a way to do this fromt he ant snipshet, my current -
bad - solution is to generate
them into ${basedir}/src/main/java.
Any ideas?
Thanks
jens
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasevalidate/phase
configuration
tasks
taskdef name=xjc
classname=com.sun.tools.xjc.XJCTask/
xjc
schema=src/main/xsd/de/dailab/util/jaxb/agentrole/AgentRole.xsd
package=de.dailab.util.jaxb.agentrole
target=${basedir}/src/main/java
extension=false/
copy
todir=${project.build.directory}/classes
fileset
dir=${basedir}/src/main/java excludes=**/*.java/
/copy
/tasks
/configuration
/executions
/plugin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2 - target/xmlbeans-source to be included as source dir for eclipse
Brian,
I'm not sure if this is the correct way to do things, but in the
build section of my project I have added:
build
resources
...
!-- include the generated java, so we can see it in eclipse --
resource
directory
${project.build.directory}/generated-sources/xdoclet
/directory
excludes
exclude**/*.java/exclude
/excludes
/resource
/resources
/build
This would then ensure that the java code from xDoclet showed up in
eclispe. I added the exclude *.java, so that the generated code would
not end up in the jar file at the end, only the compiled classes.
Hope that this helps?
IV
--- Brian Bonner [EMAIL PROTECTED] wrote:
I'm generating java source using xmlbeans from a schema. the
source is landing in target/xmlbeans-source. Is there an easy
way to include that source directory in the eclipse build path
when I run eclipse:eclipse? Or is there another approach i
should use?
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
m2 - target/xmlbeans-source to be included as source dir for eclipse
I'm generating java source using xmlbeans from a schema. the source is landing in target/xmlbeans-source. Is there an easy way to include that source directory in the eclipse build path when I run eclipse:eclipse? Or is there another approach i should use? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problems overriding source dir
Hi all
A small prob, wonder if I'm doing something wrong.
I'm migrating from an Ant based build system to maven.
I've define a sub projects to build all our jars (one projet, multiple
jars in the distribution).
By defining some overrides in the build.properties, I've manage to build
the jar using an ant call and by pointing to the master project target
dir so that all sub projects uses the same list of class files. Not to
mention that the coupling level is pretty high but correcting this for
another day.
Anyway, override the source dir should be done by the project.xml file
using the sourceDirectory element but for a reason, it doesn't work.
In the maven.xml, I echo the maven.src.dir and it always give me the
default... ${basedir}/src/java
Here is the project.xml snippit. Anything wrong? Or do I get something
wrong. I think that this sourceDirectory element would reflect its value
in the mavan.src.dir? Or must we override this property in the
build.properties.
...
currentVersion3.1.1/currentVersion
build
!--sourceDirectory${basedir}/../../java/sourceDirectory --
sourceDirectory${basedir}/../../sourceDirectory
/build
/project
My subprojet resides in :
[master_projet_base_dir]/src/sub-projects/jar_project_1/project.xml
thx for any advice
Eric.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
