RE: Cannot find lifecycle mapping for packaging: 'sar'
I think you need to define the sar package type as an extension in components.xml. Since there's already a sar plugin which also makes available sar as a package type you could check the sources of the jboss-sar-maven-plugin at codehaus.org. -Oorspronkelijk bericht- Van: Stefan Arentz [mailto:[EMAIL PROTECTED] Verzonden: Sunday, May 14, 2006 7:07 PM Aan: Maven Users List Onderwerp: Cannot find lifecycle mapping for packaging: 'sar' I created a simple plugin to create SAR archives (JBoss Service Archive). It is basically a jar file with a META-INF/jboss-service.xml. The maven-ejb-plugin looked like a good candidate for a template so I used that and modified it. My maven-sar-plugin succesfully builds and installs in the local repository. However, when I try to actually use it to package a SAR, I get the following error: [ERROR] BUILD ERROR [INFO] [INFO] Cannot find lifecycle mapping for packaging: 'sar'. Component descriptor cannot be found in the component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingsar. Is there anything I need to do before maven will 'see' my new plugin? Also, the last error message is a bit odd or does it simply miss a : in between ...LifecycleMapping and sar ? S. - 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]
Overriding ${user.home} from profile
I need to set ${user.home} to a different location based on profile. In
the profile below ${username} and ${password} propagate to the POM.
However, ${user.home} is not propagated with the value specified in the
profile. It keeps resolving to the home directory of the user running M2
instead of C:\some\path.
Relevant fragment from my settings.xml:
profiles
profile
iddefault/id
properties
usernamefoo/username
passwordbar/password
user.homeC:\some\path/user.home
/properties
/profile
/profiles
activeProfiles
activeProfiledefault/activeProfile
/activeProfiles
Should it work this way?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overriding ${user.home} from profile
I fixed it by doing it indirectly like this. I just replaced all
references to ${user.home} to ${repoRoot}. Now I can swap out the
${user.home} with this. I'll admit it's not too pretty. I rather wanted
to use ${localRepository} but could not use it because it has a prefix
of [local] - file://.
profiles
profile
iddefault/id
properties
usernamefoo/username
passwordbar/password
repoRoot${user.home}\.m2\repository/repoRoot
!-- repoRootC:\some\path/repoRoot --
/properties
/profile
/profiles
activeProfiles
activeProfiledefault/activeProfile
/activeProfiles
-Oorspronkelijk bericht-
Van: Arik Kfir [mailto:[EMAIL PROTECTED]
Verzonden: donderdag 13 april 2006 14:45
Aan: Maven Users List
Onderwerp: Re: Overriding ${user.home} from profile
Hi Peschier,
I believe ${user.home} is a property propagated from the JRE, rather
than
from maven. More than that - something looks fishy in such a use-case,
where you want to override the user's home dirperhaps if you could
elaborate on your use case we can think of a better solution?
On 4/13/06, Peschier J. (Jeroen) [EMAIL PROTECTED] wrote:
I need to set ${user.home} to a different location based on profile.
In
the profile below ${username} and ${password} propagate to the POM.
However, ${user.home} is not propagated with the value specified in
the
profile. It keeps resolving to the home directory of the user running
M2
instead of C:\some\path.
Relevant fragment from my settings.xml:
profiles
profile
iddefault/id
properties
usernamefoo/username
passwordbar/password
user.homeC:\some\path/user.home
/properties
/profile
/profiles
activeProfiles
activeProfiledefault/activeProfile
/activeProfiles
Should it work this way?
-
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.plugin.classpath works different in reactor build?
I am observing weird behaviour when using maven-antrun-plugin 1.1 with
Maven 2.0.3. Given the following POM fragment:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phaseinstall/phase
goals
goalrun/goal
/goals
configuration
tasks
taskdef resource=net/sf/antcontrib/antcontrib.properties
classpath refid=maven.plugin.classpath/
/taskdef
property name=ant.regexp.regexpimpl
value=org.apache.tools.ant.util.regexp.JakartaRegexpRegexp /
propertyregex property=strippedLocalRepository
input=${localRepository} regexp=^\[local\] - file:\/\/ replace=
/
copy
file=${project.build.directory}/${project.build.finalName}.sar
tofile=${strippedLocalRepository}\com\logibar\framework\${artifactId}\$
{version}\${project.build.finalName}.jar /
/tasks
/configuration
/execution
/executions
dependencies
dependency
groupIdant-contrib/groupId
artifactIdant-contrib/artifactId
version1.0b2/version
/dependency
dependency
groupIdant/groupId
artifactIdant-apache-regexp/artifactId
version1.6.5/version
/dependency
dependency
groupIdjakarta-regexp/groupId
artifactIdjakarta-regexp/artifactId
version1.4/version
/dependency
/dependencies
/plugin
Observed behaviour:
- The above fragment works when building the child POM standalone.
- The above fragment does not work when invoked from a reactor build.
The message given is:
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[taskdef] Could not load definitions from resource
net/sf/antcontrib/antcontrib.properties. It could not be found.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
- I checked the ant-conrib-1.0b2 jar in my repository and
net/sf/antcontrib/antcontrib.properties is in there.
What causes this? Is the maven.plugin.classpath somehow resolved
differently in a reactor build?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Eclipse plugin does not seem to make references for packaging sar
In addition to project references not being made for sar projects, I also observed that building projects that depend on sar artifacts doesn't work. It seems that sar artifacts are not added to the build classpath. I have tried setting the sar dependency scoped to compile and provided. Neither seem to add the sar in the build classpath. As a workaround I can add the sar project reference manually in Eclipse (boo). However the Maven reactor build remains broken preventing me to compile/install/deploy an ear with sar components. -Original Message - From: Peschier J. (Jeroen) Sent: vrijdag 7 april 2006 17:07 To: Maven Users List Subject: [m2] Eclipse plugin does not seem to make references for packaging sar I have some projects that depend on projects with packaging sar. I observe the following behaviour: - Running eclipse:eclipse from the parent POM, project references to dependencies with packaging jar and ejb are made. However the project references for sar projects seem to be omitted. - Running eclipse:eclipse from a child POM, classpath references to jars and ejbs in the local repository are made. Here, references to sars seem to be omitted as well. The docs for the maven-eclipse-plugin don't list which package-type are actually supported. Does the package type matter when making project references? Short of declaring a dependency in the POM, is there another way to force a project reference to be added when the eclipse plugin runs? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Eclipse plugin does not seem to make references for packaging sar
I updated components.xml to addedToClasspathtrue/addedToClasspath. It did not make any difference. Sar dependecies were not on the build classpath. Would I need to do anything else to get addedToClasspath to work? -Oorspronkelijk bericht- Van: Tom Huybrechts [mailto:[EMAIL PROTECTED] Verzonden: maandag 10 april 2006 10:20 Aan: Maven Users List Onderwerp: Re: [m2] Eclipse plugin does not seem to make references for packaging sar That's because addedToClasspath = false in the components.xml for jboss-sar see https://svn.mojo.codehaus.org/mojo/trunk/mojo/mojo-sandbox/jboss-sar-mav en-plugin/src/main/resources/META-INF/plexus/components.xml Maybe that is also an explanation for why the dependency isn't added to the Eclipse project. Tom On 4/10/06, Peschier J. (Jeroen) [EMAIL PROTECTED] wrote: In addition to project references not being made for sar projects, I also observed that building projects that depend on sar artifacts doesn't work. It seems that sar artifacts are not added to the build classpath. I have tried setting the sar dependency scoped to compile and provided. Neither seem to add the sar in the build classpath. As a workaround I can add the sar project reference manually in Eclipse (boo). However the Maven reactor build remains broken preventing me to compile/install/deploy an ear with sar components. -Original Message - From: Peschier J. (Jeroen) Sent: vrijdag 7 april 2006 17:07 To: Maven Users List Subject: [m2] Eclipse plugin does not seem to make references for packaging sar I have some projects that depend on projects with packaging sar. I observe the following behaviour: - Running eclipse:eclipse from the parent POM, project references to dependencies with packaging jar and ejb are made. However the project references for sar projects seem to be omitted. - Running eclipse:eclipse from a child POM, classpath references to jars and ejbs in the local repository are made. Here, references to sars seem to be omitted as well. The docs for the maven-eclipse-plugin don't list which package-type are actually supported. Does the package type matter when making project references? Short of declaring a dependency in the POM, is there another way to force a project reference to be added when the eclipse plugin runs? - 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] localRepository in settings.xml gets mangled
It seems when I set the local repository in settings.xml like this:
localRepositoryC:\Documents and Settings\maven/localRepository
then I get the output below when I echo${localRepository}/echo from
the antrun-plugin:
[local] - file://C:\Documents and Settings\maven2
Is this normal? It's preventing ${localRepository} being useable in the
antrun-plugin. I know there are tasks like propertyRegexp in ant-contrib
that could possiblty filter the unwanted part but would rather not add
yet another dependency. Is the file:// prefix the intended behaviour or
a bug?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: jboss-sar-maven-plugin and packaging sar
I have it configured exactly like you. Except it keeps asking for org.apache.maven.plugins:maven-sar-plugin to be present when I set the packaging to sar. Could you perhaps verify you have that plugin in your repository? -Oorspronkelijk bericht- Van: Tom Huybrechts [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 7 april 2006 11:22 Aan: Maven Users List Onderwerp: Re: jboss-sar-maven-plugin and packaging sar This is the pom for my sar project, which is working for me: project modelVersion4.0.0/modelVersion groupIdxxx/groupId artifactIdxxx/artifactId packagingsar/packaging version1.0.0-SNAPSHOT/version description/description build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-sar-maven-plugin/artifactId version2.0-SNAPSHOT/version extensionstrue/extensions /plugin /plugins /build /project On 4/6/06, Peschier J. (Jeroen) [EMAIL PROTECTED] wrote: I got this when trying your suggestion. [INFO] -- [INFO] The plugin 'org.apache.maven.plugins:maven-sar-plugin' does not exist or no valid version could be found [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-sar-plugin' does not exist or no valid version could be found Why is it looking for org.apache.maven.plugins:maven-sar-plugin? The plugin I built is org.codehaus.mojo:jboss-sar-maven-plugin. Am I correct in assuming there are different plugins for the same task? Or perhaps one plugin for the SAR-packaging-type and one for building a SAR archive? The org.apache.maven.plugins:maven-sar-plugin is not available at ibiblio. I found loom:maven-sar-plugin, but it's just an empty stub on ibiblio. Any ideas where it can be found? Add: extensionstrue/extensions to the plugin element for the jboss-sar-maven-plugin. Tom - 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] ejb-client includes deployment descriptors...
I am experiencing problems with the ejb-client jar generated with Maven 2.0.3. It appears the deployement descriptors (ejb-jar.xml, jboss.xml) are being included in the client jar. Our war reference the client-ejb jar with a classpath reference in its manifest. This causes problems when deploying on JBoss 4.0.3sp1: 2006-04-07 12:10:46,430 WARN ScannerThread [org.jboss.deployment.MainDeployer] Found non-jar deployer for lib/xxx-1.0-client.jar: MBeanProxyExt[jboss.ejb:service=EJBDeployer] I did a test where I manually removed the deployment descriptors from the ejb-client.jar and then the above warning does not appear. I think there are two sides to this issue: (1) Maven should not include deployment descriptors in the ejb-client jar. (2) JBoss should not try to deploy jar files as ejbs. Should I file a Jira issue for this?
RE: jboss-sar-maven-plugin and packaging sar
Thanks for the link! I have it working now. The snapshot I built was probably faulty. Now packaging sar works I noticed that the eclipse plugin does not make project references for sar-projects... I'll start a new thread on that one... -Oorspronkelijk bericht- Van: Tom Huybrechts [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 7 april 2006 15:28 Aan: Maven Users List Onderwerp: Re: jboss-sar-maven-plugin and packaging sar On 4/7/06, Peschier J. (Jeroen) [EMAIL PROTECTED] wrote: I have it configured exactly like you. Except it keeps asking for org.apache.maven.plugins:maven-sar-plugin to be present when I set the packaging to sar. Could you perhaps verify you have that plugin in your repository? No, I only have the org.codehaus.mojo version in my repository. But this plugin is deployed on http://snapshots.maven.codehaus.org/maven2/org/codehaus/mojo/jboss-sar-m aven-plugin/2.0-SNAPSHOT/ Did you try adding that repository ? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Eclipse plugin does not seem to make references for packaging sar
I have some projects that depend on projects with packaging sar. I observe the following behaviour: - Running eclipse:eclipse from the parent POM, project references to dependencies with packaging jar and ejb are made. However the project references for sar projects seem to be omitted. - Running eclipse:eclipse from a child POM, classpath references to jars and ejbs in the local repository are made. Here, references to sars seem to be omitted as well. The docs for the maven-eclipse-plugin don't list which package-type are actually supported. Does the package type matter when making project references? Short of declaring a dependency in the POM, is there another way to force a project reference to be added when the eclipse plugin runs? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jboss-sar-maven-plugin and packaging sar
I built jboss-sar-maven-plugin-2.0-SNAPSHOT from source since it is not yet released. If I set packagingsar/packaging I get this error: [ERROR] BUILD ERROR [INFO] --- [INFO] Cannot find lifecycle mapping for packaging: 'sar'. Component descriptor cannot be found in the component repository: org.apache.maven.lifecycle.mapping.LifecycleMappingsar. The plugin itself seems to work because if I set packagingjarpackaging both a JAR and a SAR are build. However only the JAR is installed in the repository. I would like to install the SAR with the extension .sar in the repository. Am I missing something here? Using maven 2.0.3 with the following plugin config: resources resource directoryconf/directory includes includejboss-service.xml/include /includes targetPathMETA-INF/targetPath /resource /resources plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-sar-maven-plugin/artifactId executions execution phasepackage/phase goals goalsar/goal /goals /execution /executions /plugin /plugins - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jboss-sar-maven-plugin and packaging sar
I got this when trying your suggestion. [INFO] -- [INFO] The plugin 'org.apache.maven.plugins:maven-sar-plugin' does not exist or no valid version could be found [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-sar-plugin' does not exist or no valid version could be found Why is it looking for org.apache.maven.plugins:maven-sar-plugin? The plugin I built is org.codehaus.mojo:jboss-sar-maven-plugin. Am I correct in assuming there are different plugins for the same task? Or perhaps one plugin for the SAR-packaging-type and one for building a SAR archive? The org.apache.maven.plugins:maven-sar-plugin is not available at ibiblio. I found loom:maven-sar-plugin, but it's just an empty stub on ibiblio. Any ideas where it can be found? Add: extensionstrue/extensions to the plugin element for the jboss-sar-maven-plugin. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: M2 - Best practice for common jars between EJB,WAR modules in EAR
Yes, classloader issues arise. Duplicate JARs in the EAR and WAR are treacherous! Consider this scenario: - JAR dependency contains common class with static fields - WAR depends on said common class - SAR depends on said common class If the JAR is packaged in both the EAR and the WAR, the static fields cannot be shared since the WAR has its own classloader. This makes the WAR indeed deployable outside the EAR but in many cases it is not what you want. -Oorspronkelijk bericht- Van: Richard Sladek [mailto:[EMAIL PROTECTED] Verzonden: donderdag 23 maart 2006 13:43 Aan: users@maven.apache.org Onderwerp: Re: M2 - Best practice for common jars between EJB,WAR modules in EAR I have just one more question: might such duplicates in ear modules cause some classloader issues (or anything) or is it completely safe to have them? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2.0: accents and entities with xdoc
- Make sure your DTD matches the root element name of your docbook file. If memory serves me, it should be 'document' for xdoc. So it should read !DOCTYPE document [ !ENTITY mytest SYSTEM relative/path/to/MyTest.java ] - You say your XML file is encoded ISO-8859-1. Did you also specify the encoding like ?xml encoding=ISO-8859-1? on the first line in your XML file? If not, the XML parser will assume UTF-8 like the XML spec mandates. -Oorspronkelijk bericht- Van: Herve Quiroz [mailto:[EMAIL PROTECTED] Verzonden: maandag 6 februari 2006 15:55 Aan: users@maven.apache.org Onderwerp: Maven 2.0: accents and entities with xdoc Hi, I am trying to migrate to Maven 2.0. So far, I've been doing fine with everything that is Java build-cycle related. However, I can't get XML entites to be resolved when building the site using xdoc, which means I can't include files. This feature is quite mandatory for many projects so I am assuming there is a new way of doing that in Maven 2.0. Could anyone tell me how? Here is the typical use case in my projects: !DOCTYPE whatever [ !ENTITY mytest SYSTEM relative/path/to/MyTest.java ] section name=Sample code sourcemytest;/source /section Which gives me a nice error message: Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: could not resolve entity named 'mytest' (position: START_TAG seen ...section name=Sample code\n\n sourcemytest;... @45:23) I am not really used to XML entities and I only know this trick to import files into some xdoc source file so there has to be a workaround here. Next, I have some trouble when using accents. The xdoc source file is effectively set to ISO-8859-1, and I did not change the outputEncoding setting in the site plugin configuration (which defaults to ISO 8859-1). Then the resulting page contains weird characters (often 2 characters in the output for each single accent character in the xdoc file). I would be glad if someone could tell me how to use accents with Maven 2.0 (needless to say it was working fine with Maven 1.0). BTW, I really enjoy using Maven 2.0. Developing plugins is so much easier now. Herve - 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 manual Release steps ?
Excellent question. +1 for a plugin to facilitate making a release. -Oorspronkelijk bericht- Van: Pete [mailto:[EMAIL PROTECTED] Verzonden: woensdag 25 januari 2006 18:58 Aan: Maven Users List Onderwerp: Maven manual Release steps ? Given that the mvn release:prepare / perform still has known major issues. Does anyone out there have a reliable method for doing a manual release. e.g . 1) Can you just do a search and replace version1.0-SNAPSHOT/version replace with version1.0/version I guess you have to look at each dependency first ? 2) Then check into SCM 3) Then do you do a CVS label / tag 4) Then do you do a second search and replace for version1.0 version1.0/version replace with version1.1-SNAPSHOT/version Again I guess you have to look at all dependencies first ? 5) Then check into SCM again ? Any thoughts on how to semi automate the replace steps ? or at least document how to do a manual mvn release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Yet another Eclipse issue...
I have tried to get workspace dependencies working by executing eclipse:eclipse from the root of the parent project but it does not seem to get the project reference right. When I view the Projects tab in Java Build Path properties in Eclipse, I see M2 has added generated a project reference to myproject. The corresponding entry in the .classpath file is thus: classpathentry kind=src path=/myproject/ Manually adding the project dependency does indeed work. In that case the entry in .classpath is thus: classpathentry combineaccessrules=false kind=src path=/MyProject/ Notice the differences: (1) /myproject vs. /MyProject, and (2) There's an combineaccessrules attribute The referenced project folder is named MyProject on disk. I experimented by renaming the folder to myproject but found the M2 generated .classpath still doesn't work. I should probably note the artifactId of the referenced project is myproject. M2 generates this entry in .project reflecting this: projects projectmyproject/project /projects Any ideas on why project references are not working for me? -Oorspronkelijk bericht- Van: Ralph Pöllath [mailto:[EMAIL PROTECTED] Verzonden: donderdag 26 januari 2006 14:58 Aan: Maven Users List Onderwerp: Re: Yet another Eclipse issue... If you run the eclipse plugin from the root of a multi-module project, it will create workspace dependencies between the modules instead of binary dependencies. Cheers, -Ralph. - 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] Is generating an application.xml with connector module possible?
Ah, there's a jboss-sar-maven-plugin. I completely missed that. It appears I
need to build it myself as it's not on ibiblio. I'll give it a try.
-Oorspronkelijk bericht-
Van: Stephane Nicoll [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 24 januari 2006 14:27
Aan: Maven Users List
Onderwerp: Re: [M2] Is generating an application.xml with connector module
possible?
Yes, you need to install the sar mojo :)
It should be available from the mojo project
(http://mojo.codehaus.org/). If not, ping me and I will implement it.
Cheers,
Stéphane
On 1/23/06, Peschier J. (Jeroen) [EMAIL PROTECTED] wrote:
You are right about the the connector module being for RAR modules only. I
read up on it and it seems SARs are not deployed from application.xml, but
jboss-app.xml instead. My bad.
I currently build my SAR module as a jar since sar is not working for me as a
packaging type. I noticed sarModule is expecting
groupId:artifactId:sar:version in the repository. I rename the .jar to .sar
in my local repository, so Maven can find it. The SAR module is now correctly
included in the EAR.
I noticed the needed jboss-app.xml is not generated for the sar. So I wrote
wrote my own and configured the earSourceDirectory:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.1/version
configuration
generateApplicationXmltrue/generateApplicationXml
earSourceDirectory${basedir}/include/earSourceDirectory !-- place
jboss-app.xml in this directory --
modules
sarModule
groupIdmyGroup/groupId
artifactIdmyArtifact/artifactId
/sarModule
...
After some fiddling I got it working but it's not clean yet. I still need to
manually rename the .jar to .sar in the repository for each build.
How do I create an artifact of the type sar? Within my SAR project I tried
setting the packaging type to sar in the POM but it gives me this exception:
org.apache.maven.lifecycle.LifecycleExecutionException: Cannot find
lifecycle mapping for packaging: 'sar'.
This seems odd as the maven-ear-module seems to know the sar package type
just fine. Am I missing something here?
-Oorspronkelijk bericht-
Van: Stephane Nicoll [mailto:[EMAIL PROTECTED]
Verzonden: donderdag 19 januari 2006 20:22
Aan: Maven Users List
Onderwerp: Re: [M2] Is generating an application.xml with connector module
possible?
On 1/19/06, Peschier J. (Jeroen) [EMAIL PROTECTED] wrote:
My use-case:
- Using the maven-ear-plugin to generate the application.xml deployment
descriptor.
- Want to include a SAR module in the deployment descriptor.
- Found out about ejbModule, warModule and javaModule but could not find
any info on how to generate a connector module. So I tried the obvious:
A connector is a rar file as per spec. JBoss has its own sar format
which is supported in the EAR plugin. If you have a dependency of type
'sar' it should work out of the box.
You don't need to configure it in the modules section (regarding
includeInApplicationXml which is javaModule specific)
I read the plugin
configuration doc and found that modules is of type EarModule. Where
can I find info on the definition of EarModule?
FYI, the supported implementations of EarModule are:
* jar
* ejb
* ejb-client
* ejb3
* par
* rar
* war
* sar
This is a good idea, I will update the doc for the next plugin's release.
Cheers,
Stéphane
--
.::You're welcome ::.
-
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]
--
.::You're welcome ::.
-
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] Is generating an application.xml with connector module possible?
You are right about the the connector module being for RAR modules only. I read
up on it and it seems SARs are not deployed from application.xml, but
jboss-app.xml instead. My bad.
I currently build my SAR module as a jar since sar is not working for me as a
packaging type. I noticed sarModule is expecting groupId:artifactId:sar:version
in the repository. I rename the .jar to .sar in my local repository, so Maven
can find it. The SAR module is now correctly included in the EAR.
I noticed the needed jboss-app.xml is not generated for the sar. So I wrote
wrote my own and configured the earSourceDirectory:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.1/version
configuration
generateApplicationXmltrue/generateApplicationXml
earSourceDirectory${basedir}/include/earSourceDirectory !-- place
jboss-app.xml in this directory --
modules
sarModule
groupIdmyGroup/groupId
artifactIdmyArtifact/artifactId
/sarModule
...
After some fiddling I got it working but it's not clean yet. I still need to
manually rename the .jar to .sar in the repository for each build.
How do I create an artifact of the type sar? Within my SAR project I tried
setting the packaging type to sar in the POM but it gives me this exception:
org.apache.maven.lifecycle.LifecycleExecutionException: Cannot find lifecycle
mapping for packaging: 'sar'.
This seems odd as the maven-ear-module seems to know the sar package type
just fine. Am I missing something here?
-Oorspronkelijk bericht-
Van: Stephane Nicoll [mailto:[EMAIL PROTECTED]
Verzonden: donderdag 19 januari 2006 20:22
Aan: Maven Users List
Onderwerp: Re: [M2] Is generating an application.xml with connector module
possible?
On 1/19/06, Peschier J. (Jeroen) [EMAIL PROTECTED] wrote:
My use-case:
- Using the maven-ear-plugin to generate the application.xml deployment
descriptor.
- Want to include a SAR module in the deployment descriptor.
- Found out about ejbModule, warModule and javaModule but could not find
any info on how to generate a connector module. So I tried the obvious:
A connector is a rar file as per spec. JBoss has its own sar format
which is supported in the EAR plugin. If you have a dependency of type
'sar' it should work out of the box.
You don't need to configure it in the modules section (regarding
includeInApplicationXml which is javaModule specific)
I read the plugin
configuration doc and found that modules is of type EarModule. Where
can I find info on the definition of EarModule?
FYI, the supported implementations of EarModule are:
* jar
* ejb
* ejb-client
* ejb3
* par
* rar
* war
* sar
This is a good idea, I will update the doc for the next plugin's release.
Cheers,
Stéphane
--
.::You're welcome ::.
-
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-ejb-plugin] Files ending with Session.class are not being included in ejb-client jar
I am seeing odd behaviour with the generation of ejb-client jars. It seems all files that end in Session.class are not being included in the ejb-client. They show up fine in the ejb-jar. When I rename the file to SessionX.class they become available in the ejb-client. This is reproduceable for several of our EJB projects using Maven 2.0.2 and maven-ejb-plugin 2.0. I suspect a bug but thought I'd ask here before submitting to Jira.
[M2] Is generating an application.xml with connector module possible?
My use-case: - Using the maven-ear-plugin to generate the application.xml deployment descriptor. - Want to include a SAR module in the deployment descriptor. - Found out about ejbModule, warModule and javaModule but could not find any info on how to generate a connector module. So I tried the obvious: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.1/version configuration generateApplicationXmltrue/generateApplicationXml modules connectorModule groupIdmyGroup/groupId artifactIdmyArtifact/artifactId includeInApplicationXmltrue/includeInApplicationXml /connectorModule ... Didn't work though :( How is generating a connector module done? I read the plugin configuration doc and found that modules is of type EarModule. Where can I find info on the definition of EarModule? PS. I realize a SAR is JBoss-specific, but the connector module is not. It's been part of the J2EE spec since 1.3, see http://java.sun.com/dtd/application_1_3.dtd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Continuum import multimodule project [M2]
I experienced the same problem as you when importing a multimodule project into Continuum. When you add the parent POM it looks for the modules' POM relative to the group/artificat/version directory in the repository. This awful scheme prevents all M2 multimodule projects from working in Continuum. Inherently the problem is with the modules definition in the POM as they are relative to the parent POM. Each module should have a groupId and artifactId as well so continuum would be able to find the modules in the repository. Sorry I cannot offer you a solution. I tried in vain too... -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Verzonden: donderdag 19 januari 2006 14:40 Aan: users@maven.apache.org Onderwerp: Continuum import multimodule project [M2] Hi, I tried to import a multimodule project into continuum and failed. the structure of my projects projects | +-- xyz_proj_distributon | +-- xyz_proj_backend | +-- xyz_proj_frontend | im my pom.xml of xyz_proj_distribution I have the following modules definition: modules module../xyz_proj_backend/module module../xyz_proj_frontend/module /modules When I'm locally everything works fine. Could anybody give me a hint how to add such a multimodule project to continuum. TIA Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using multiple source directories to produce on artefact
I agree that a mavenized build probably does not need multiple source dirs. However, for most of us Maven is not the only tool we use. My use-case for multiple source dirs is to separate XDoclet-generated code. The Maven build will indeed perform fine with the generated source in the same directory as the main sources, but consider what happens outside Maven: (1) In Eclipse you get everything in a single source dir creating a huge tree in the Package Explorer. I know it's possible to filter out the generated source packages but it's not practical unless the maven-eclipse-plugin facilitates this by excluding them from the view for me. (2) When using SCM within Eclipse: because everything is in a single source dir you need to tell Eclipse (for ALL AND EVERY generated package) you want the generated sources excluded from SCM. Again, very impractical. Unless the maven-eclipse-plugin can exclude generated sources from SCM I want it in a separate directory. This separate directory can conveniently be excluded from SCM with a single ignore entry. Although I have things working like I want using the build-helper-maven-plugin I'd still like to be able to set multiple source dirs in the POM as it is much cleaner. I really don't see the argument against multiple source dirs in the POM either. True best-practices evangelists can still continue to use (and preach :) single source directory projects. Nothing is lost with multiple source dirs, it's just convenience that is gained. -Oorspronkelijk bericht- Van: dan tran [mailto:[EMAIL PROTECTED] Verzonden: donderdag 12 januari 2006 17:23 Aan: Maven Users List; [EMAIL PROTECTED] Onderwerp: Re: Using multiple source directories to produce on artefact Yes, build-helper is there for legacy build. However, if a build is completely mavenized, I see no need to have more than one primary source trees and adding a generated source tree the project , shoud be done by the generated source plugin itself. For now, i dont see a way out until at least 2.1, if it supports multiple main source trees ;-) -D - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using multiple source directories to produce on artefact
I tried your suggestion and it seems indeed to add
${project.build.directory}/generated-sources/xdoclet to the source
directory list. The maven-eclipse-plugin also adds this directory as a
source directory in Eclipse's build classpath. Works conveniently since
target is excluded from SCM anyway.
In case anyone else wants to try it, I should mention that it will only
work if you set the destDir attribute of the doclet to
${project.build.directory}/generated-sources/xdoclet as well. It would
make sense to have the destDir attribute default to the
generatedSourcesDirectory plugin parameter but I experienced the destDir
is mandatory and cannot be omitted. Perhaps the usage example on the
xdoclet-maven-plugin site could be updated to use a destDir of
${project.build.directory}/generated-sources/xdoclet as I don't see
this quirk documented elsewhere.
By quirk I mean that
${project.build.directory}/generated-sources/xdoclet needs to be set
in two places making the POM a bit harder to maintain. Apart from that
it is working fine now and I can thankfully remove the
build-helper-maven-plugin dependency from my projects.
-Oorspronkelijk bericht-
Van: Allison, Bob [mailto:[EMAIL PROTECTED]
Verzonden: maandag 16 januari 2006 14:13
Aan: Maven Users List
Onderwerp: RE: Using multiple source directories to produce on artefact
By default (or maybe it is by design) the XDoclet plugin wants it
generated output to go in target/generated-sources/xdoclet and it
AUTOMATICALLY adds this path to the source directory list. It is bad
practice to have XDoclet (or any other code generator) place its output
under src. In NetBeans, the NetBeans plugin creates a separate source
tree entry for the generated sources; I would think that the Eclipse
plugin does the same (or it should if it doesn't).
If you put the generated output where it belongs (in target, not in
src), the problems you detailed will disappear, I believe.
-Original Message-
From: Peschier J. (Jeroen) [mailto:[EMAIL PROTECTED]
Sent: Monday, January 16, 2006 07:25
To: Maven Users List
Subject: RE: Using multiple source directories to produce on artefact
I agree that a mavenized build probably does not need multiple source
dirs. However, for most of us Maven is not the only tool we use. My
use-case for multiple source dirs is to separate XDoclet-generated code.
The Maven build will indeed perform fine with the generated source in
the same directory as the main sources, but consider what happens
outside Maven:
(1) In Eclipse you get everything in a single source dir creating a huge
tree in the Package Explorer. I know it's possible to filter out the
generated source packages but it's not practical unless the
maven-eclipse-plugin facilitates this by excluding them from the view
for me.
(2) When using SCM within Eclipse: because everything is in a single
source dir you need to tell Eclipse (for ALL AND EVERY generated
package) you want the generated sources excluded from SCM. Again, very
impractical. Unless the maven-eclipse-plugin can exclude generated
sources from SCM I want it in a separate directory. This separate
directory can conveniently be excluded from SCM with a single ignore
entry.
Although I have things working like I want using the
build-helper-maven-plugin I'd still like to be able to set multiple
source dirs in the POM as it is much cleaner. I really don't see the
argument against multiple source dirs in the POM either. True
best-practices evangelists can still continue to use (and preach :)
single source directory projects. Nothing is lost with multiple source
dirs, it's just convenience that is gained.
-Oorspronkelijk bericht-
Van: dan tran [mailto:[EMAIL PROTECTED]
Verzonden: donderdag 12 januari 2006 17:23
Aan: Maven Users List; [EMAIL PROTECTED]
Onderwerp: Re: Using multiple source directories to produce on artefact
Yes, build-helper is there for legacy build. However, if a build is
completely
mavenized, I see no need to have more than one primary source trees
and
adding a generated source tree the project , shoud be done by the
generated
source plugin
itself.
For now, i dont see a way out until at least 2.1, if it supports
multiple
main source trees ;-)
-D
-
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-compiler-plugin
Hi Pablo,
I believe you can resolve this by added an extra source directory using
the build-helper-maven-plugin. In your use-case you would add the main
source directory like this:
sourceDirectorysrc/webapp/WEB-INF/src/sourceDirectory
Add any additional source directories using the
build-helper-maven-plugin:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idadd-source/id
phasegenerate-sources/phase
goals
goaladd-source/goal
/goals
configuration
sources
sourcesrc/integration-tests/source
/sources
/configuration
/execution
/executions
/plugin
If you use this plugin you don't need any configuration of the
maven-compiler-plugin. Your additional sources will be compiled
automatically.
-Oorspronkelijk bericht-
Van: Pablo [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 10 januari 2006 13:55
Aan: Maven Users List
Onderwerp: maven-compiler-plugin
Hello everyone
I have the following project structure:
/src/webapp/WEB-INF/src etc.
/src/tests
/src/integration-tests
Junit tests are compiled automatically by setting the value below:
testSourceDirectorysrc/tests/java/testSourceDirectory
Now I want to use the same plugin to compile integration-tests. The
compiled tests should be placed in target/integration-tests.
Since fields:
private List compileSourceRoots;
private File outputDirectory;
are readonly it's not possible to set them in plugin's configuration.
I removed @readonly attribute and installed the plugin just to see if it
would work.
This is the part of my pom.xml which defines compiler plugin:
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
encodingiso-8859-2/encoding
/configuration
executions
execution
idtesty/id
phasetest-compile/phase
goals
goaltestCompile/goal
/goals
configuration
compileSourceRoots
compileSourceRootsrc/integration-tests/compileSourceRoot
/compileSourceRoots
outputDirectory${project.build}/integration-tests/outputDirectory
/configuration
/execution
/executions
/plugin
I thought that I could change compilesourceRoot and outputDirectory and
all integration tests would be compiled.
But it isn't so:
[EMAIL PROTECTED]:~/cvsroot/webapp$ mvn clean test-compile
[INFO] Scanning for projects...
[INFO]
[INFO] Building WebApp
[INFO]task-segment: [clean, test-compile]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/pablo/cvsroot/webapp/target
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 225 source files to /home/pablo/cvsroot/webapp/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 19 source files to
/home/pablo/cvsroot/webapp/target/test-classes
[INFO] [compiler:testCompile {execution: testy}]
Compiling 19 source files to
/home/pablo/cvsroot/webapp/target/integration-tests
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 59 seconds
[INFO] Finished at: Tue Jan 10 13:50:51 CET 2006
[INFO] Final Memory: 7M/33M
[INFO]
The compiler plugin is run twice. As you can see
outputDirectory${project.build}/integration-tests/outputDirectory
is used but tests sources' directory is not. What am I doing wrong? How
can I use this plugin to compile additional things? And will it be ever
possible to do it? I had to remove @readonly attributes.
Thanks for reading
Pablo
-
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] How to declare dependency to ejb-client jar in POM
We have a project with an EJB module. With the maven-ejb-plugin we build both the myEjb-0.1.jar and the myEjb-0.1-client.jar. It builds fine, but I noticed the client-jar gets installed/deployed in the same location as the ejb-jar. This seems to be problematic when we want to reference the client-jar in our parent POM. We are stuck on how this is done. In the parent POM we have: dependency groupIdx.y/groupId artifactIdmyEjb/artifactId version0.1/version typeejb/type scopecompile/scope /dependency dependency groupIdx.y /groupId artifactIdmyEjb/artifactId version0.1-client/version typeejb/type !-- shouldn't this be jar? -- scopecompile/scope /dependency In the child POM we have the following. Note that this seems to reference the ejb-jar, not the client-jar: dependency groupIdx.y/groupId artifactIdmyEjb/artifactId typeejb/type /dependency We'd like to know how to define the client-jar as a dependency in both the parent and child POM where only the parent POM has the version number. Help much appreciated! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] How to declare dependency tp ejb-client jar in POM
We have a project with an EJB module. With the maven-ejb-plugin we build both the ejb.jar and the ejb-client.jar. Works fine. But now we want to reference the client jar in our parent POM.
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: New SAR Plugin
Many thanks for implementing this! I look forward to using it. Do you have a public repo I can download your plugin from? Maybe I'm just impatient... :) Keep up the good work! -Oorspronkelijk bericht- Van: Frank Mena [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 16 december 2005 1:57 Aan: Maven Users List Onderwerp: New SAR Plugin I have written a sar plugin that builds a JBoss service sar. It handles the .sar extension automatically because I have given it an artifactId of maven-sar-plugin. I would like to contribute it for inclusion into the mavens plugin directory, if possible. It has the Apache license and a site. How should I go about submitting it? I have also modifed the ear plugin so it will also handle a sarModule. I have the source of the sarModule and a patch file that has the changes to the ear source to include the sar module. Also , I noticed that 2 of the source files do not have the proper Apache license header, so I fixed them. Frank Mena - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
[M2] test-jar for non-jar projects
If the packaging is set to jar in the POM you can build a test-jar. This does not work when packaging is set to ejb. Since the POM always allows you to set a testSourceDirectory for all package types I don't the reason for this limitation. Is this something that can be added to Jira as a feature request or was it a deliberate choice to only allow test-jars for jar projects?
[M2] SerialVersionUID solution / Maven compiler settings
My use-case: I build an EAR using Maven 2 and the Sun SDK 1.4.2. For testing I tend to run a few JUnit tests from Eclipse. These tests typically invoke some remote beans on the application server. This gives me the dreaded InvalidClassException because the local serialVersionUID differs from the remote serialVersionUID. Evalution: I think most of us dealing with RMI have encountered this problem before. It is known that different compilers generate different serialVersionUIDs for the same class. In my case the remote classes are generated with the Sun JavaC while the local classes are generated by Eclipse JDT. Plan: Although this problem is not actually a Maven 2 issue, I was thinking Maven 2 could assist in the solution to the problem. The maven-compiler-plugin has a compilerId setting which seems to indicate it can be reconfigured to use another compiler. Would it be possible for M2 to use the Eclipse compiler so that the artifacts will have the same serialVersionUID as in Eclipse? If so, how would I go about this? P.S. I know I can manually add serialVersionUIDs to serializable classes, but this is not an option as most of my serializable classes are value objects generated by XDoclet. XDoclet does not have a way of specifying serialVersionUID for generated value objects.
RE: Multiple source directories (again)
This works great! However, it causes the Eclipse plugin to see the
project root as the source directory. I tried to get around it to set at
least the source directory to src and use the basedir variable on the
includes like this:
sourceDirectorysrc/sourceDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0/version
configuration
source1.5/source
target1.5/target
includes
include
implementation=java.lang.String${basedir}/src/**/*.java/include
include
implementation=java.lang.String${basedir}/gen-src/**/*.java/include
/includes
/configuration
/plugin
The Maven log reports No sources to compile so it doesn't work. How
come? I noticed the eclipse plugin generates a source directory entry
for every resource you include. I managed to get my gen-src directory
added using this:
resources
resource
directorygen-src/directory
includes
include**/*.java/include
/includes
/resource
/resources
This works but has an unwanted side effect as it also adds the source
code in gen-src to the artifact.
All of the above are just hacks of get multiple source directories per
artifact in Maven. Is there a clean solution that compiles multiple
source directories, and generates the proper Eclipse projects files for
said source directories?
-Oorspronkelijk bericht-
Van: Aleksandar Likic [mailto:[EMAIL PROTECTED]
Verzonden: zondag 6 november 2005 19:49
Aan: users@maven.apache.org
Onderwerp: RE: Multiple source directories (again)
OK, I found it:
sourceDirectory./sourceDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0/version
configuration
source1.5/source
target1.5/target
includes
include
implementation=java.lang.Stringsrc/main/java/**/*.java/include
include
implementation=java.lang.Stringtarget/schema-src/**/*.java/include
/includes
testIncludes
testInclude
implementation=java.lang.Stringsrc/test/java/**/*.java/testInclude
/testIncludes
/configuration
/plugin
-Original Message-
From: Aleksandar Likic [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 06, 2005 12:50 PM
To: users@maven.apache.org
Subject: Multiple source directories (again)
I am trying to find out how to tell maven 2 to compile multiple source
directories. I am using JAXB to generate code in target/src, and then
compile it together with the rest of the code. I could have multiple
projects, but it simply doesn't make sense to me to in this particular
case.
The build process would become more complex to manage, with an extra
artifact that I don't want to have. Any ideas?
-
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 : Major Bug in xdoclet plugin ?
I ran into this myself too. It's a known bug in XDoclet itself. See
http://opensource2.atlassian.com/projects/xdoclet/browse/XDT-1505
The problem is the old definition of destDir is used which results in
the class being generated in a place you don't want or even expect them.
As a workaround you can set the destDir attribute on any subtask of the
ejbdoclet, e.g.:
ejbdoclet ejbSpec=2.1 destDir=${basedir}/src
fileset dir=${basedir}/src includes=**/*Bean.java/
homeinterface destDir=${basedir}/src/
remoteinterface destDir=${basedir}/src/
localinterface destDir=${basedir}/src/
localhomeinterface destDir=${basedir}/src/
/ejbdoclet
---Oorspronkelijk bericht-
Van: Pete [mailto:[EMAIL PROTECTED]
Verzonden: zondag 13 november 2005 17:26
Aan: Maven Users List
Onderwerp: Re: M2 : Major Bug in xdoclet plugin ?
Anyone help ?
On 12/11/05, Pete [EMAIL PROTECTED] wrote:
If I use the xdoclet plugin to generate ejb classes all works fine and
as expected - providing I running one ejb project at a time.
e.g.
mvn clean generate-sources
from the pom.xml for the EJB project(s) all is ok.
BUT if I run from the parent project pom :-
- the reactor correctly finds the order
- runs generate-sources on my 2 ejb projects
but at the end the target\generated-sources\xdoclet directory
for the 1st EJB project contains BOTH ejbs generated sources
The 2nd EJB project is missing the target\generated-sources\xdoclet
directory
The -X debug looks fine for both EJB projects.
If I swap the dependencies around then the exact reverse happens.
If I remove one EJB child module from the parent poms module list,
all works fine.
Here is what I have in each of the ejb poms
1st EJB pom (the one that ends up with both generated-sources)
build
finalNameebars_dmz_srv_ExampleService/finalName
plugins
plugin
artifactIdxdoclet-maven-plugin/artifactId
groupIdorg.codehaus.mojo/groupId
version1.0-alpha-2/version
executions
execution
phasegenerate-sources/phase
goals
goalxdoclet/goal
/goals
configuration
tasks
ejbdoclet
destdir=${project.build.directory}/generated-sources/xdoclet
fileset dir=${basedir}/src/main/java includes=**/*Bean.java/
entitycmp destDir=${project.build.outputDirectory}/
!-- session/ --
remoteinterface pattern={0}Remote/
localinterface pattern={0}Local/
homeinterface pattern={0}RemoteHome/
localhomeinterface pattern={0}LocalHome/
deploymentdescriptor
destDir=${project.build.outputDirectory}/META-INF/
!--orion
destdir=${project.build.outputDirectory}/META-INF/ --
/ejbdoclet
/tasks
/configuration
/execution
/executions
/plugin
/build
2nd EJB pom (ends up with no generated-sources)
build
finalNameebars_dmz_bus_ExampleManager/finalName
plugins
!-- needed to override to add manifest
class-path in ejb jar --
plugin
artifactIdxdoclet-maven-plugin/artifactId
groupIdorg.codehaus.mojo/groupId
version1.0-alpha-2/version
executions
execution
phasegenerate-sources/phase
goals
goalxdoclet/goal
/goals
configuration
tasks
ejbdoclet
destdir=${project.build.directory}/generated-sources/xdoclet
fileset dir=${basedir}/src/main/java includes=**/*Bean.java/
entitycmp destDir=${project.build.outputDirectory}/
!-- session/ --
remoteinterface pattern={0}Remote/
localinterface pattern={0}Local/
homeinterface pattern={0}RemoteHome/
localhomeinterface pattern={0}LocalHome/
deploymentdescriptor
destDir=${project.build.outputDirectory}/META-INF/
!--orion
destdir=${project.build.outputDirectory}/META-INF/ --
/ejbdoclet
/tasks
/configuration
/execution
/executions
/plugin
/plugins
/build
I have also tried both :-
version1.0-alpha-1/version
version1.0-alpha-2/version
of the plugin.
Finally here's the -X output (the
Deploy source jar to repository
I managed to create a jar with the source code for each of our artifacts with the maven-source-plugin. However, reading this plugin's documentation I don't see any way to: A) install/deploy the source jar to the repository, and B) link the source jar to its corresponding ejb/war/jar-artifact in the repository, and C) have the maven-eclipse-plugin generate an Eclipse classpath where each dependency will have the appropriate source jar referenced. The maven-eclipse-plugin appears to need configuration of an artifactFactory and artifactResolver to assist in locating the source jars. I could not find any documentation or example on how to do this. Has anyone managed to get steps A, B and C implemented? As it is now you can't step through any code outside the project source because the dependencies have no source attachment...
RE: Deploy source jar to repository
Thanks, this does indeed what I needed! This introduced two other issues though: 1) Is there a way to exclude certain dependencies from downloadSources? Many artifacts have no source attachment in the ibiblio.org repository causing M2 to hang 10 secs on each attempt to fetch the source jar from its repositories. Well, on my slow connection anyway :). I rather not disable the ibiblio.org repo... 2) I want include the source jar for every install/deploy of an artifact. Thus, I put this in the parent POM: pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId inheritedtrue/inherited executions execution phaseverify/phase !-- makes sure the source jar is build before install or compile -- goals goaljar/goal /goals inheritedtrue/inherited /execution /executions configuration attachtrue/attach /configuration /plugin /plugins /pluginManagement Note that I have specified the inherited-tag twice. I tried different permutations, but it did not auto inherit to the child projects. When I put the following in the child project it works: build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId /plugin /plugins /pluginManagement /build However, I rather not repeat this in 50+ subprojects... Is it possible to configure the maven-source-plugin to be executed without it being referenced in every child project? From the docs it was my understanding the inherited-tag tells M2 to let the plugin configuration in the parent propagate to child POMs. Oorspronkelijk bericht- Van: Fabrizio Giustina [mailto:[EMAIL PROTECTED] Verzonden: maandag 14 november 2005 15:23 Aan: Maven Users List Onderwerp: Re: Deploy source jar to repository On 11/14/05, Peschier J. (Jeroen) [EMAIL PROTECTED] wrote: A) install/deploy the source jar to the repository, and Just run mvn deploy after the source jar generation: mvn source:jar deploy B) link the source jar to its corresponding ejb/war/jar-artifact in the repository, and Handled by the deploy goal, the source jar will sit near to the binary artifact with a -sources suffix. C) have the maven-eclipse-plugin generate an Eclipse classpath where each dependency will have the appropriate source jar referenced. run mvn -Declipse.downloadSources=true eclipse:eclipse (the current released version has a bug so that sources already available in the local repo are not added if you don't specify eclipse.downloadSources=true) fabrizio - 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]
