possible to ship an Ant based plugin with resources?
Hi, I'm developing some custom maven plugin and am wondering if it's possible to have an Ant based maven plugin shipping some necessary resources? I'm writing a plugin that does some DB manipulations and some of the SQL scripts could already be shipped with the plugin. I've already figured that files in src/main/resources are included in the plugin JAR. But I don't know how to point my Ant scripts to those SQL-scripts. Regards, Stefan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: possible to ship an Ant based plugin with resources?
I'm writing a plugin for maven that is implemented in Ant. see http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: possible to ship an Ant based plugin with resources?
If i understand the things correct you have to locate the scripts into the
default location of the plugin (src/main/sripts)...?
Say, I have a SQL script that I want to execute from my Ant based mojo
using sql ant task. I put that script in the plugin's
src/main/scripts. My problem is how to point the SQL task to that
script:
target...
sql driver=${db.driver} url=${db.url}
userid=${db.user} password=${db.pwd}
rdbms=mysql
fileset file=createVersionTable.sql /
/sql
/target
When the plugin gets executed on the target project, I get Source
file or resource collection, transactions or sql statement must be
set!
Any ideas?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Release-Plugin remote- Tagging
OK, I wasn't aware of this new remoteTagging-Feature. sounds helpful, though. Todd Thiessen thies...@nortel.com writes: Your initial thoughts regarding what remoteTagging does is correct. ie: the tag is created from the remote scm version, not from your checkout. --- Todd Thiessen 2009/7/16 Danny Schimke schimk...@googlemail.com: Does remote- Tagging meant, that the (SVN-) Trunk- version is used for prepare / perform the release instead of using the local workingcopy? Is that correct? Thank you! -Danny Schimke - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release-Plugin remote- Tagging
Hi Danny, you're probably talking about the maven-release-plugin, right? what do you mean by remote tagging specifically? During prepare the plugin forces the user to have a clean working copy, i.e. no uncommited changes. If the working copy is clean, it modifies POM by increasing version numbers and altering SCM-connection URLs, it then commits those changes and tags them. During perform the plugin checks out that newly created tag to a temporary working folder and performs the actual release step on that. Hope that helps? -Stefan 2009/7/16 Danny Schimke schimk...@googlemail.com: Does remote- Tagging meant, that the (SVN-) Trunk- version is used for prepare / perform the release instead of using the local workingcopy? Is that correct? Thank you! -Danny Schimke -- Danny Schimke IT- Consultant incowia GmbH Albert-Einstein-Straße 3 D-98693 Ilmenau www.incowia.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin JRE classpath generation problem
2008/9/19 Tomek Maciejewski [EMAIL PROTECTED]: ... classpathContainers classpathContainerorg.elipse.mtj.JavaMEContainer/Sun Java(TM) Wireless Toolkit 2.5.2 for CLDC/DefaultColorPhone/classpathContainer /classpathContainers /configuration /plugin With this configuration I get .classpath file like this: classpath classpathentry kind=src path=src/main/java/ classpathentry kind=src path=src/main/resources excluding=**/*.java/ classpathentry kind=output path=target/classes/ classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ classpathentry kind=con path=org.elipse.mtj.JavaMEContainer/Sun Java(TM) Wireless Toolkit 2.5.2 for CLDC/DefaultColorPhone/ /classpath The problem is I would like to get rid of JRE in classpath because I use JavaME. So my question is how to set maven-eclipse-plugin to not generate this line: classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ Have you tried to eclipse:clean-up before eclipse:eclipse? Maven's Eclipse plugin suggests to run eclipse:clean if you realy want to replace earlier eclipse-settings. -Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Having trouble with setting a property in settings.xml and activating a profile in a pom based on that property
David, this gave me hard time too. After a while I realized, that profiles can only be activated by *system* properties which is a different beast than those properties one can define in a POM or the settings. System properties are those which are provided to maven by the command line parameter -D. http://maven.apache.org/guides/introduction/introduction-to-profiles.html explicitely uses the term system property when it comes to profile activation by property values. -Stefan 2008/9/19 David [EMAIL PROTECTED]: Hello All, I'm trying to set a property in the settings.xml file and then have a profile in the pom.xml file activate if that property is set. Right now I don't care about the value, I just need it to be set. Currently I have the following in my settings.xml file. profile idA/id activation activeByDefaulttrue/activeByDefault /activation properties davidC:\temp/david /properties /profile In my pom.xml I have the following. profiles profile idB/id activation property namedavid/name /property /activation ... profiles I can see from running mvn help:active-profiles that profile A in the settings.xml file is active but profile B is not. I can also use the David property in other areas of the pom file. I'm I doing something wrong? I'm using Maven-2.0.6 on Windows. Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven/Eclipse - Keeping them in sync?
David, 2008/9/19 David C. Hicks [EMAIL PROTECTED]: I'm beginning a new, fairly large, project. Eclipse will be our development platform, but I've already set up the starting point in Maven. Simple enough. Now, my question is, how can I keep them in sync, easily? I realize that it's best to re-run mvn eclipse:eclipse after adding dependencies, but what about source folders? I need to add new source folders, but Maven doesn't know anything about that, so the next time I re-generate the .project/.classpath files, it'll revert back to those folders not being source folders. Any help how to make this behave? You need to add additional source folders by using the build-helper-maven-plugin (http://mojo.codehaus.org/build-helper-maven-plugin/). Then the maven-eclipse-plugin happily add all your source folders to eclipse's project configuration. Also another hint on handling larger project setup with many submodules and maybe independent project side by side. In my last project to keep all my projects and submodules (40+) synced with eclipse I put all projects and multiprojects in the same subversion trunk and thus the same working folder in parallel subfolders. in the working folder's root I established a bootstapper-pom which included all projects as submodules. the project's parent pom resided in a parallel subfolder next to the projects as well. Also this parent-pom was included as a submodule by the bootstrapper-pom. With this setup we were able to invoke any maven commands on all projects at once. -Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cannot use -Darchetype(GroupId/ArtifactId) with maven-archetype-plugin 2.0-alpha-1
Hi Stuart, On 13/02/2008, Stuart McCulloch [EMAIL PROTECTED] wrote: I think you've picked up the new release of the archetype plugin which by default runs in interactive mode, with choices from an internal catalog (even when the archetype groupId and artifactId are already selected) Thats the behaviour I'm seeing, yes this has been raised and discussed on the developer list: http://www.nabble.com/New-archetype-plugin-issues-questions-td15435079s177.html and a fix is in progress, until a new release is made you can use: OK, fine mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create ...etc... to force Maven to use the old version :( That's OK for the hopefully shorter period of time -Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cannot use -Darchetype(GroupId/ArtifactId) with maven-archetype-plugin 2.0-alpha-1
Hi everybody, does anybody experience the same issue like me since updating to the latest maven-archetype-plugin? I'm trying to create a new project by invoking e.g. (taken directly from http://mojo.codehaus.org/groovy/groovy-maven-archetype/index.html) mvn archetype:create \ -DarchetypeGroupId=org.codehaus.mojo.groovy \ -DarchetypeArtifactId=groovy-maven-archetype \ -DgroupId=com.mycompany \ -DpackageName=com.mycompany.mymodule \ -DartifactId=mymodule When invoking this the archetype-plugin asks me to pick one of the standard-archetypes. the groovy-archetype isn't even listed, although is resides in my local repo. What's going on? -Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Assembly-Plugin: Including sources of dependencies
Hi all, I'm trying create an assembly that includes sources of some of its dependencies. Without any luck so far. Does anybody accomplished this and could share any hints? Thanks, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jmock-metadata in central repo
Hi Maven-Team, is there any chance to get central's metadata for jmock fixed? It misses jmock's 1.1.0-release. see http://repo1.maven.org/maven2/jmock/jmock/maven-metadata.xml: metadata groupIdjmock/groupId artifactIdjmock/artifactId version1.0.0/version versioning versions version1.0.0/version version1.0.0.RC1/version version1.0.1/version version20031129.200437/version version2004-03-19/version versionusedbypico/version /versions /versioning /metadata Is this issue rather to be addressed to the jmock-folks? Cheers, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MVN 2.0.6 vs. Extensions with Version Ranges
Hi all,
keen to migrate to 2.0.6 this morning I've ran right into a problem
concerning the wagon-webdav extension and the way I declared it (using
a version range) in our company wide Super POM.
Up to maven 2.0.5 the following declaration worked fine:
extension
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-webdav/artifactId
version[1.0-beta-1,)/version
/extension
With maven 2.0.6 I get the following exception:
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have been
included transitively during the resolution process. Here is the in
formation we do have for this artifact:
o GroupID: org.apache.maven.wagon
o ArtifactID: wagon-webdav
o Version: MISSING
o Type:pom
[INFO]
[INFO] Trace
org.apache.maven.artifact.InvalidArtifactRTException: For artifact
{org.apache.maven.wagon:wagon-webdav:null:pom}: The version cannot b
e empty.
What's the deal here? Is this a side effect of some refactoring or a
certain decision concerning extension handling?
Any hints much appreciated,
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MVN 2.0.6 vs. Extensions with Version Ranges
Hi Alexey, thanks for your response!
2007/4/2, Alexey Kakunin [EMAIL PROTECTED]:
we had same problem with 2.0.5
with 2.0.5 there was no problem at all here.
it seems for me the problem is:
1. you tried to get some artifacts
2. getting was failed
3. information about it was placed into local repository
The scenario you describe seems to be unrelated to mine, though. The
wagen-webdav *is* in my local repo for months now.
4. next time maven did not tried to get them
Try to remove local repository - or part related to this group/artifact -
maybe it will help
What I figured out works is to get rid of the version section in
extension's declaration alltogether. This led to exceptions in the
past but has been fixed apparently
2007/4/2, Stefan Hübner [EMAIL PROTECTED]:
Hi all,
keen to migrate to 2.0.6 this morning I've ran right into a problem
concerning the wagon-webdav extension and the way I declared it (using
a version range) in our company wide Super POM.
Up to maven 2.0.5 the following declaration worked fine:
extension
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-webdav/artifactId
version[1.0-beta-1,)/version
/extension
With maven 2.0.6 I get the following exception:
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have been
included transitively during the resolution process. Here is the in
formation we do have for this artifact:
o GroupID: org.apache.maven.wagon
o ArtifactID: wagon-webdav
o Version: MISSING
o Type:pom
[INFO]
[INFO] Trace
org.apache.maven.artifact.InvalidArtifactRTException: For artifact
{org.apache.maven.wagon:wagon-webdav:null:pom}: The version cannot b
e empty.
What's the deal here? Is this a side effect of some refactoring or a
certain decision concerning extension handling?
Any hints much appreciated,
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
With Best Regards,
Alexey Kakunin, EmDev Limited
Professional Software Development:
http://www.emdev.ru
Two Dependency Plugins: Wrong chosen by Maven
Hi, I've run into a weird issue, while trying to make use of the dependency-plugin's new resulve-feature. If I invoke Maven by mvn dependency:resolve, it complains about no goal resolve found in plugin. Digging into it with -X it becomes clear, that Maven is using a different dependency-plugin from what I was expecting, since it invokes org.codehaus.mojo:dependency-maven-plugin:1.0. Why does Maven pick up that plugin in favour of org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4, which available from my local repo as well? Any idea? Cheers, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two Dependency Plugins: Wrong chosen by Maven
2007/3/28, Maria Odea Ching [EMAIL PROTECTED]: Hi Stefan, Maybe your dependency plugin metadata file (in local repo) isn't updated? You could try installing the 2.0-alpha-4 version again with -DupdateReleaseInfo=true.. I couldn't get a clue of that updateReleaseInfo-option you mentioned, except of me fixing up the org/apache/maven/plugins/maven-metadata-central.xml in my local repo where there was depency-maven-plugin registered (the wrong one). That solved my problem. Hope this helps! :) Thanks for pointing in the right direction :-) Cheers, Stefan Thanks, Deng Stefan Hübner wrote: Hi, I've run into a weird issue, while trying to make use of the dependency-plugin's new resulve-feature. If I invoke Maven by mvn dependency:resolve, it complains about no goal resolve found in plugin. Digging into it with -X it becomes clear, that Maven is using a different dependency-plugin from what I was expecting, since it invokes org.codehaus.mojo:dependency-maven-plugin:1.0. Why does Maven pick up that plugin in favour of org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4, which available from my local repo as well? Any idea? Cheers, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !DSPAM:602,460a30a7165909301039927! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two Dependency Plugins: Wrong chosen by Maven
2007/3/28, Brian E. Fox [EMAIL PROTECTED]: The org/codehaus/mojo/metadata needs to be cleared in your local repository to permanently fix this. Apparently the search order in maven is backwards, if it finds a similar prefix in mojo, it will use that over apache. You're right, thats necessary too. I already cleared that one. Thanks nethertheless! -Original Message- From: Stefan Hübner [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 7:41 AM To: Maven Users List Subject: Re: Two Dependency Plugins: Wrong chosen by Maven 2007/3/28, Maria Odea Ching [EMAIL PROTECTED]: Hi Stefan, Maybe your dependency plugin metadata file (in local repo) isn't updated? You could try installing the 2.0-alpha-4 version again with -DupdateReleaseInfo=true.. I couldn't get a clue of that updateReleaseInfo-option you mentioned, except of me fixing up the org/apache/maven/plugins/maven-metadata-central.xml in my local repo where there was depency-maven-plugin registered (the wrong one). That solved my problem. Hope this helps! :) Thanks for pointing in the right direction :-) Cheers, Stefan Thanks, Deng Stefan Hübner wrote: Hi, I've run into a weird issue, while trying to make use of the dependency-plugin's new resulve-feature. If I invoke Maven by mvn dependency:resolve, it complains about no goal resolve found in plugin. Digging into it with -X it becomes clear, that Maven is using a different dependency-plugin from what I was expecting, since it invokes org.codehaus.mojo:dependency-maven-plugin:1.0. Why does Maven pick up that plugin in favour of org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4, which available from my local repo as well? Any idea? Cheers, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !DSPAM:602,460a30a7165909301039927! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: usage of maven-dependency-plugin
Alexander, could you please invoke mvn dependency:analyze with options -X -e? Is Maven really using the apache-version of the plugin or the codehaus-version? Another way to figure out, which plugin Maven is using is to invoke mvn help:describe -Dplugin=dependency Cheers, Stefan 2007/3/28, Lewandowski, Eric [EMAIL PROTECTED]: Hi, I want to analyze my project dependencies with maven-dependency-plugin. In my pom.xml, i put this entry to the project/build/plugins entry : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.0-alpha-4/version /plugin The resolution failed with this traces : mvn dependency:analyze [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'dependency'. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Required goal not found: dependency:analyze [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Mar 28 05:34:56 EDT 2007 [INFO] Final Memory: 1M/3M [INFO] Does anabody know what's wrong ? Do I need more configuration informations ? Regards, Eric Lewandowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AspectJ and Eclipse plugin: Support of aspect libraries
Hi, I created a library (let's call it project-a) to provide aspects (AspectJ is meant here) to other modules. To use that library as an aspect library I would create a pom for some project-b as follows: ?xml version=1.0? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdsandbox/groupId artifactIdproject-b/artifactId packagingjar/packaging version1.0-SNAPSHOT/version nameproject-b/name dependencies dependency groupIdaspectj/groupId artifactIdaspectjrt/artifactId version[1.5,)/version /dependency dependency groupIdsandbox/groupId artifactIdproject-a/artifactId version1.0-SNAPSHOT/version /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency /dependencies build plugins plugin artifactIdmaven-eclipse-plugin/artifactId configuration additionalProjectnatures projectnatureorg.eclipse.ajdt.ui.ajnature/projectnature /additionalProjectnatures buildcommands buildcommandorg.eclipse.ajdt.core.ajbuilder/buildcommand /buildcommands /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdaspectj-maven-plugin/artifactId configuration aspectLibraries aspectLibrary groupIdsandbox/groupId artifactIdproject-a/artifactId /aspectLibrary /aspectLibraries complianceLevel1.5/complianceLevel /configuration executions execution goals goalcompile/goal goaltest-compile/goal /goals /execution /executions /plugin /plugins /build /project Then I would like to use eclipse to work on project-b. so I set it up using the eclipse plugin. That works fine except for configuring project-a as an aspect library. This causes no aspects to be woven into classes of project-b. Did I miss something in setting up my poms? thanks in advance for any hints! -Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
issues with https-repositories [WAS: Re: Trying Quickly build Archiva]
Hi Tom and others, I know - it's been a while, but I've just found your post. you're mentioning issues with https-repositories and I experienced exactly the same issues described in the thread attached below. Tom recommended using https.proxyHost/Port-parameters which indeed fixed those issues. My question(s): Doesn't Maven handle proxies via settings.xml? I'm behind a proxy which is configured in my local settings. If there's actually a difference between handling of http and https-repos, how to configure properly then? Any ideas? Cheers, Stefan 2006/11/14, Tom Huybrechts [EMAIL PROTECTED]: If you are behing a proxy, this might be caused by the https-repository that is added by the archiva POMs. Try adding cmdline arguments: -Dhttps.proxyHost=... -Dhttps.proxyPort=... Tom On 11/13/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I download all of the software from the required page as described. The sun jars. I cant see what is wrong there. It happens more than once in build Archive Security Configuration project. The error you posted said it couldn't download commons-configuration 1.3, which is definitely available. Are you still getting the same error? Does it download anything at all? (At this point I start suspecting you're behind a proxy, because we've seen numerous reports of problems when a proxy is involved.) Sorry I can't help more, but Archiva builds fine here. -- Wendy - 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]
Undocumented property expansion?
Hi all,
the other day I found this statement inside commons-logging-1.1.pom
(http://repo1.maven.org/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom):
urlhttp://jakarta.apache.org/commons/${pom.artifactId.substring(8)}//url
I tried the same substring-thing in my poms, but Maven didn't expand
the URL like I would have expected. Is a statement like that actually
supposed to work? If so, is there a common pattern to use similar
features (e.g. ${groupId.replaceAll(., /)} )?
Any hints? Thanks in advance!
-Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
PMD-plugin doesn't verify automatically
Hi all, I've just started to use the PMD- (2.1), Cobertura- (2.0), and Checkstyle-Plugins (2.1) to verify some metrics on our internal projects. One strange thing with all these plugins though is, that despite of their documentation states, they would be invoked automatically during the Verify-phase, they actually don't. I use Maven 2.04. I can only make them do their work, if I explicitly define an execution, which invokes the check-goal during the verify-phase. What am I doing wrong? Any hints appreciated! -Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Server settings ignored when stage-deploying maven site
Hi,
I've got a settings.xml stating something like:
...
server
idmaven-sites/id
usernamemaven/username
/server
...
and a POM with:
...
distributionManagement
site
idmaven-sites/id
urlscpexe://some-server/srv/www/maven-sites/${groupId}/${version}//url
/site
/distributionManagement
...
Now, when I deploy a site, Maven connects with the remote server using
the given user-id maven (see settings.xml above). But if I want to
use the stage-deploy feature, that user-id is ignored and Maven wants
to deploy the staging site using my local user account - which fails
of cause.
My questions: Is this a feature or a bug? Is there a work around
giving me the chance to deploy by using the maven-user?
Any hints appreciated!
-Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do i use the hibernate3 plugin from codehause
Hi Yves, 2006/10/19, Yves Van Steen [EMAIL PROTECTED]: I want to create ddl sql files from my hbm files but none of the goals of the hibernate3 plugin actually works? Is this plugin useable or still in development? I'm using it quite successfully to generate ddl-files with hibernate3:hbm2ddl. I was also trying to get hbm2doc running, but that one is not working as of now, because the Hibernate-libraries are not stable yet. Apperently there are some screwed up dependencies. It's in development (1.0-SNAPSHOT). There was an attempt to publish 1.0, but that process got stuck a while ago. there are still some bugs left - like your one. you might want to keep track of http://jira.codehaus.org/browse/MOJO-515. I think, whenever the Hibernate guys publish their 3.2 release, this plugin will be fixed. Even now it does a great job. jm2c -Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
attributes-Map in site-plugin's configuration
Hi all, I'm wondering if there's a way to include POM-specific information in a project's site. I would like to include version info in the site's navigation bar. How would I do this? Also, while reading the site-plugin's docs at http://maven.apache.org/plugins/maven-site-plugin/site-mojo.html, I wonder what the attributes-Parameter is used for. I didn't find any examples and couldn't get it do something usefull for me. any hints on this? cheers, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi module versioning - how to?
Hi Alex, 2006/7/10, Alex Shneyderman [EMAIL PROTECTED]: Do the module lawnet-web-core's pom.xml defines a parent ? if no, it must define a version. the question is why? The answer is, it's the way pom-inheritance works. Which is something slightly different from module-aggregation. the lawnet-web-core's and the lawnet-web-jcomp's poms need to refer to your aggregating parent pom. in general, submodules inherit properties (like version-number, etc.) from a parent, to which *they* refer to via the parent-tag. they *don't* get properties injected just because they are submodules of another pom. you may find this thread useful to understand the concepts of pom inheritence and aggregation: http://www.nabble.com/Parent-vs.-Multi-Project-super-pom-tf1776475.html#a4836112 --Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disecting a webapp?
Hi guys, 2006/7/7, Alexandre Poitras [EMAIL PROTECTED]: Can't you create more than one war and add them to an ear archive? If it's not a valid strategy in your case than I guess you can use the dependency plugin unpack goal (http://mojo.codehaus.org/dependency-maven-plugin/) or you can use the war merging feature of Maven (don't know how it works but I know it exists). war merging feature? Is this documented somewhere out there? sounds promissing. I'm also interested in best practises on this topic, since we're producing large webapps too. having all resources in just one big module is a bit nasty. -Stefan In my case, I use the dependency plugin to unpack resources (images, css, ...) dependencies. Note those aren't limitations of Maven but of JEE since each web modules must be packaged as an individual war and of the web because there isn't any standard resources archive format. Hope it helps! On 7/6/06, Alex Shneyderman [EMAIL PROTECTED] wrote: Thanks, guys for your responses. But ... I think I was not understood correctly. Let me clarify a bit here. The problem is not so much to separate layers into modules (it seems that's what examples demonstrate), but how to break up a big web application into smaller modules. The module's boundary is not that of the layer (business, webapp, core, etc). Web application itself needs to be broken onto smaller submodules. So core would have all the templates, js and css files and will be a webapp on its own, the child module would have concrete pages that utilize those templates and styles and in combination with the core module would constitute complete sub-application of a bigger app. When I develop I would like to checkout just one module and a few modules that this module depends on. Of course I would be able to deploy this one small module (and all of its dependencies), but it will not be the site itself, just one little portion. It also makes creation of the new module easier. Just declare dependencies and create a simple WAR structure. When I am happy with the little module I worked on, I will want to deploy it to production. This is when I will have to merge all the configuration files (web.xml comes to mind) and directory structures but only on creation of the WAR no need for physical merge on the system someplace. I am not sure if this made my question any clearer :-) On 7/6/06, Tamás Cservenák [EMAIL PROTECTED] wrote: Hi Alex, a quick example for this, see here: https://is-micro.myip.hu/trac/ismicro-commons/browser/trunk/ismicro-proximity Three modules: px-core (j2ee and transport independent), px-core-maven (maven bindings for core, till no sign of webapp) and px-webapp. The module separation should be natural and/or logical -- whetever it means :) In my practice it means, produce ONLY ONE ARTIFACT, be as small and as simple as it can (but naturally keep the overall module count manageable). Maven generated site from these sources here: http://proximity.abstracthorizon.org/ ~t~ On 7/6/06, ben short [EMAIL PROTECTED] wrote: Also have a look at the better builds with maven book, there is an example in there. On 7/6/06, ben short [EMAIL PROTECTED] wrote: Create a project for each of the core module and the children. then the webapp can pull them in as dependancies. On 7/6/06, Alex Shneyderman [EMAIL PROTECTED] wrote: How does one disect a web app into many modules but deploy it as one web app? This is what I mean: We have a web application that is quite big. We can identify many modules of it. There is a few core modules, and a bunch of child modules. Practically all children are dependendent on core modules, some child modules depend on other child modules. The modularization is done in purely logical way. Meaning, we still have one maven project for the webapp. I was wondering if anyone can suggest a way to break those modules up into seprate physical modules while keeping the ability to create a unifying webapp? Is it even possible with Maven 1 or 2? -- Thanks, Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Transitive Dependency Questions
Wendy, 2006/7/1, Wendy Smoak [EMAIL PROTECTED]: On 6/30/06, Stephen Duncan [EMAIL PROTECTED] wrote: In either case, with Maven 2, the solution (as far as I know) is simply to directly declare your dependency on Bob's Ace Logger v1.0.1. Then you'll get that version. In addition, in Scenario One, even if Sally did know about Bob's 1.0.1 version, she should not *change* her v2.0 pom. She would need to release a 2.0.1 version of her framework with the new dependency. Would Sally be really in need to release a new version of v2.0's pom, if she had used version ranges in the first place? She could just declare the dependency to Bob's framework as version[1.0,)/version (or maybe [1.0,2.0) considering major changes probably won't be interoperable) -Stefan -- Wendy - 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: Project structure and releasing
Andy, are you saying, that deploying the multiproject-pom as 1.2.1 would automatically update the submodule's dependency on their parent from 1.2-SNAPSHOT to 1.2.1? Is it even necessary to declare the parent's version the submodules refer to? -Stefan 2006/7/1, Andrew Williams [EMAIL PROTECTED]: I may be wrong, but if your parent is, as in the book, a pom packaged artifact with a module list then doing a release at that level should prompt (with sensible defaults) the release of all the modules. Andy On Fri, 2006-06-30 at 21:29 +0200, Martijn Dashorst wrote: All, I've updated the structure of my projects that depend on one another to the structure as proposed in the better builds with maven book. The one problem I have with this way of building is the link to the parent project: parent groupIdwicket/groupId artifactIdwicket-parent/artifactId version1.2-SNAPSHOT/version /parent Now I have to update all projects to perform a release of say version 1.2.1. Or is there a better way? BTW. All projects use snapshot dependencies as adviced earlier on this mailinglist. Martijn - 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] Relocating repository-artifacts
Hi Carlos, (I'm always excited how quick users get responses to their questions here on the list. Thanks!) see my comment inside: 2006/6/27, Carlos Sanchez [EMAIL PROTECTED]: you just add the relocation info to the old poms pointing to the new ones You mean, by editing the old poms manually on the server, where the internal repository resides? On 6/27/06, Stefan Hübner [EMAIL PROTECTED] wrote: Hi there, in our company we successfully introduced Maven2 for a fair lot of modules. We didn't define conventions on group- and artifact-Ids in the early days of adoption. Thus, those artifacts are somewhat spread over our internal repository and I would like to reorganize them by giving them nice hierarchical groupIds. Studying the POM-structure there's a relocation-Element inside distributionManagemet, which can be used to expose the new location of an artifact. But how do I populate that information the right way? I came up with this steps: 1) get the artifact's regarding version from SCM 2) add the relocation-info to its POM 3) deploy the artifact 4) change the groupId of the POM to meet our new conventions 5) remove the relocation-element 6) deploy the artifact again (now to its new location) This looks a bit odd to me, though. Is there any other (smarter) way of relocating artifacts in a repository? Cheers, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Relocating repository-artifacts
I see. Thanks! I was just wondering if there was a way to do that plugin-guided or so. --Stefan 2006/6/27, Carlos Sanchez [EMAIL PROTECTED]: yes On 6/27/06, Stefan Hübner [EMAIL PROTECTED] wrote: Hi Carlos, (I'm always excited how quick users get responses to their questions here on the list. Thanks!) see my comment inside: 2006/6/27, Carlos Sanchez [EMAIL PROTECTED]: you just add the relocation info to the old poms pointing to the new ones You mean, by editing the old poms manually on the server, where the internal repository resides? On 6/27/06, Stefan Hübner [EMAIL PROTECTED] wrote: Hi there, in our company we successfully introduced Maven2 for a fair lot of modules. We didn't define conventions on group- and artifact-Ids in the early days of adoption. Thus, those artifacts are somewhat spread over our internal repository and I would like to reorganize them by giving them nice hierarchical groupIds. Studying the POM-structure there's a relocation-Element inside distributionManagemet, which can be used to expose the new location of an artifact. But how do I populate that information the right way? I came up with this steps: 1) get the artifact's regarding version from SCM 2) add the relocation-info to its POM 3) deploy the artifact 4) change the groupId of the POM to meet our new conventions 5) remove the relocation-element 6) deploy the artifact again (now to its new location) This looks a bit odd to me, though. Is there any other (smarter) way of relocating artifacts in a repository? Cheers, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin configuration inheritance?
Hi Brad, see comment inside: 2006/6/27, Brad Harper [EMAIL PROTECTED]: Are plugin configurations inherited/cumulative? E.g., given project 'A' descriptor containing build plugins plugin artifactIdP/artifactId configuration blah-1 and sub-project/module 'B', with descriptor containing build plugins plugin artifactIdP/artifactId configuration blah-2 blah-3 Does plugin 'P' see 'blah-1' in its configuration? I would assume, it doesn't. Not sure though. --Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plugin configuration inheritance?
This would meen, that the configuration contents of the second pom
gets merged with that from parent pom. Is any documentation available
about this feature?
2006/6/27, Roland Asmann [EMAIL PROTECTED]:
Here's a sample of 2 of my POM's:
Parent:
build
pluginManagement
plugins
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
configuration
container
containerIdjboss4x/containerId
home${appserver.home}/home
output${project.build.directory}/jboss4x.log/output
/container
configuration
typestandalone/type
home${project.build.directory}/jboss4x/home
/configuration
waitfalse/wait
/configuration
executions
execution
idstart/id
phasetest-compile/phase
goals
goalstart/goal
/goals
/execution
execution
idstop/id
phasetest/phase
goals
goalstop/goal
/goals
/execution
/executions
/plugin
/plugins
/pluginManagement
/build
Child:
build
plugins
!-- Plugins that are already configured in the parent POM --
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
!-- Extend the configuration --
configuration
configuration
deployables
deployable
groupId${groupId}/groupId
artifactIdmy-ear/artifactId
typeear/type
/deployable
/deployables
/configuration
/configuration
/plugin
/plugins
/build
And this works perfectly for me...
Roland
On Tuesday 27 June 2006 18:45, Stefan Hübner wrote:
I think, that inheriting plugin configuration, whether by plugins or
pluginManagement, only inherits full configurations. That meens,
whenever you reference a plugin and define a configuration-element
inside, its inherited configuration will be lost.
That's just my experience (and I think a was reading about this
behaviour, but not sure where or when) and I'd appreciate any other
opinions :-)
--Stefan
2006/6/27, Brad Harper [EMAIL PROTECTED]:
Stefan:
Until recently, I've had the expectation that plugin configurations
*should* be inherited by default. Apparently not.
Another poster (Dan Tran) has recommended using pluginManagement to
control build configuration inheritance. Better Builds doesn't even
reference the element.
I've tried using inheritedtrue/inherited in several positions, now
including within pluginManagement, but without success.
Brad
-Original Message-
From: Stefan Hübner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 27, 2006 10:59 AM
To: Maven Users List
Subject: Re: plugin configuration inheritance?
Hi Brad,
see comment inside:
2006/6/27, Brad Harper [EMAIL PROTECTED]:
Are plugin configurations inherited/cumulative? E.g., given
project 'A' descriptor containing
build
plugins
plugin
artifactIdP/artifactId
configuration
blah-1
and sub-project/module 'B', with descriptor containing
build
plugins
plugin
artifactIdP/artifactId
configuration
blah-2
blah-3
Does plugin 'P' see 'blah-1' in its
Re: Parent vs. Multi Project super pom
Hi Kenney, 2006/6/13, Kenney Westerhof [EMAIL PROTECTED]: On Mon, 12 Jun 2006, Stephen Duncan wrote: Hi, I'd thought I'd throw in a pair of $0.01.. Using the aggregating POM as the parent pom implies that the projects are structured in a directory structure matching the child-parent relationship. That means that the child-parent relationship is the inverse of the parent-module relationship. A simple sample is the grouping of a set of plugins. Since they're siblings in the directory structure, the parent pom can easily serve as the parent pom, defining all things common to plugins. ...the parent pom can easily serve as the parent pom... ;-) Isn't there any more precise wording? But like you, I've also found that this sometimes gives problems, since there's no multiple inheritance. In my case it was when working on a project that consists of two applications, both EARs each containing a WAR using the same web framework (and thus sharing some settings and dependencies). The modules were grouped by application, and using the parent-as-aggregator there's no way to let both WAR projects have the same settings if they're not siblings in the directory structure. There's also some common POM configuration for the two applications (for instance the groupId's). Another advantage, more of convenience, of differ between parent and aggregating pom: you can have the parent pom at the same level as it's inherited poms. Thus in Eclipse I can edit at least the parent pom easily, since I can import it as a Eclipse project. This is not true for the aggregating pom, though. But since typically the parent pom is more often edited than the aggregating pom, this is fine by me. Basically, there are too many relations to fit into a tree (it becomes a graph), and you just have to pick the one that makes the most sense. In my experience, it's convenient to have the parent pom as an aggregator so your project tree is actually a tree. OK, understood. (But with the lack of not beeing able to edit the parent pom easily inside Eclipse.) On a side note, there are some plugins, like the site plugin, that currently kind of expect the parent-module relationship to be bidirectional (meaning modules must specify the aggregator as their parent). The behaviour of this plugin depends on whether it's run in reactor-mode or not, and when the modules define different parents, you get unexpected results. But this is being addressed. See, it's the implicit assumptions, that make me scratch my head. -- Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Parent vs. Multi Project super pom
Hi Stephen,
2006/6/13, Stephen Duncan [EMAIL PROTECTED]:
I personally do more as you do.
I have team-wide super-POMs I have a primary one that has basic
url, issue management, etc. type settings. Then I have a core POM
with common dependencyManagment section to encourage use of the same
versions of Jar's to prevent incompatibilities, as well as common
reporting configuration. Then I have a webapp parent POM that
specifically states the provided dependencies for webapps to be
deployed to our target server, as well as webapp specific stuff, such
as setting finalName${project.artifactId}/finalName to remove the
version number from wars, and wtpVersion1.0/wtpVersion for the
Eclipse plugin.
Right Stephen, that's the kind of pom inheritance, which I quite like
about Maven. It gives me the chance to encourage reliable and
maintenable project configurations throughout the company.
-- Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cactus plugin?
Hi Vincent, 2006/6/13, Vincent Massol [EMAIL PROTECTED]: [SNIP] Do you meen the cargo-maven2-plugin? Does this actually help cactifying WARs? No it doesn't. This is the last missing piece of the puzzle. That said it should be possible to do a manual cactification using the war plugin in an execution or, as suggested by Kenney to use the Ant plugin to execute the Cactus Ant tasks. I was trying to do that, but couldn't get it working yet. Any examples out there? -- Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cactus plugin?
Thanks anyway! 2006/6/13, Vincent Massol [EMAIL PROTECTED]: -Original Message- From: Stefan Hübner [mailto:[EMAIL PROTECTED] Sent: mardi 13 juin 2006 13:37 To: Maven Users List Subject: Re: Cactus plugin? Hi Vincent, 2006/6/13, Vincent Massol [EMAIL PROTECTED]: [SNIP] Do you meen the cargo-maven2-plugin? Does this actually help cactifying WARs? No it doesn't. This is the last missing piece of the puzzle. That said it should be possible to do a manual cactification using the war plugin in an execution or, as suggested by Kenney to use the Ant plugin to execute the Cactus Ant tasks. I was trying to do that, but couldn't get it working yet. Any examples out there? No idea. I haven't done it myself. -Vincent ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
javancss-maven-plugin-2.0-beta-1 released?
Hi all, I'm wondering if this plugin has already been released? I might be blind, but I do not find it anywhere in the release-repo. any hints appreciated! Cheers, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: exported pom encoding
Hi Jörg, 2006/6/12, Jörg Schaible [EMAIL PROTECTED]: Hi Stefan, Stefan Hübner wrote on Sunday, June 11, 2006 9:25 AM: Hi all, an issue has been created on this over at http://jira.codehaus.org/browse/MECLIPSE-56, already. Fixing it decently seems to be quite a hassle though, because maven doesn't care much about pom.xml's encoding. at the moment the developers seem to consider rewriting the whole parsing stuff from scratch. well, this might be another effect of the encoding problem, but this has nothing to do with Eclipse in special. As stated, the deployed POM will have the entities (like #xf6;) resolved and the XML is simply invalid. [snip] you're absolutely right, Jörg. The encoding misery is not limited to Eclipse at all. This is just one symptom of many. Maven doesn't read POMs using their declared encoding properly. It's certainly able to resolve all sorts of entities but only with the effect, that those characters will lead to new problems during POM-exports. Maven simply uses the local system's default character set while parsing or writing a POM. The same probably happens while writing POMs. To me it seems, that lots of those different sorts of character set problems will only be resolved, if Maven starts to fully take into account the POM's declared encoding. You might have a look at http://jira.codehaus.org/browse/PLX-214 for further discussions. jm2c, Stefan
Re: Cactus plugin?
Hi Raphael, 2006/6/12, Raphaël Piéroni [EMAIL PROTECTED]: There is one... check it at cargo.codehaus.org If you search for an example of use, the axistools archetype in the mojo.codehaus.org sandbox's use it for testing. [SNIP] Do you meen the cargo-maven2-plugin? Does this actually help cactifying WARs? Stefan
Re: Cactus plugin?
Hi Kenney, 2006/6/12, Kenney Westerhof [EMAIL PROTECTED]: On Mon, 12 Jun 2006 [EMAIL PROTECTED] wrote: Hi, I believe there's nothing usable yet, but I could be wrong. In the mean time you could use the maven-antrun-plugin to call the cactus ant tasks. It's not ideal but it'll help you migrate. [SNIP] I'm currently trying to go that direction. But I didn't manage to cactify the web application to test. That web application is different from it's i-test-module and is referred as a dependency. Do you have an example how to achieve this? Cheers, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Parent vs. Multi Project super pom
Hi all, this is kind of a best-practise-question about your habbits of using the concepts of multi-project-super-pom. First of all, are there distinctive terms commonly agreed upon for each of those concepts? Second, those two ways of using POMs appear to me to be orthogonal to each other, really. Parent POMs are used to define common characterisitics for a group of projects. Multi Project POMs on the other hand aggregate modules belonging to a greater project. I usually have the habbit of defining two diffent poms for multiproject situations. e.g.: /multiproject-pom X -parent-pom Y -module A / pom A (parent pom: Y) -module B / pom B (parent pom: Y) In most examples found though (e.g. in maven's own sources themselfs) typically multi project poms at the same time are used as parent poms for those modules they aggregated. So, what I can't get my head around yet is, is it just a matter of habbit or taste to combine those two usages in just one POM? or am I really missing something important here, if I define two distinctive POMs the way described above. I'm thinking about this for quite a while now and any clarification would be much appreciated. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: exported pom encoding
Hi all, an issue has been created on this over at http://jira.codehaus.org/browse/MECLIPSE-56, already. Fixing it decently seems to be quite a hassle though, because maven doesn't care much about pom.xml's encoding. at the moment the developers seem to consider rewriting the whole parsing stuff from scratch. Stefan 2006/6/8, Jörg Schaible [EMAIL PROTECTED]: Alexandre Poitras wrote on Thursday, June 08, 2006 4:12 PM: Hi all, I have a little problem. My pom.xml encoding is set to ISO-8859-1 but each time I run 'mvn package', maven generates an exported pom which has a 'UTF-8 encoding. I would like to keep the original encoding because Eclipse complains about bad characters in the generated xml file. Any idea how to solve this? It's even worse. Even if you have UTF-8 as encoding and add your special characters as entities (e.g. #xf6;), the entitiy is converted into the character and the POM is again invalid. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: uses for config directory?
Hi all, just some thoughts: I think maven doesn't make use of it, because the art of configuration management is not a simple thing to implement and one can find nearly in every project a different approach to it. the config-directory appears to me to be a first idea of where configuration data could be stored - for simple cases anyways. so, how to use it is completely up to you. I'm using it for files which are only usefull in the assembly to be delivered to clients. i.e. files which could end up in a /etc-dir inside the installation directory of a deployed application. So I use the assembly-plugin to store those files in the right place in the assembly to be created. maybe, this makes some sense to you. Stefan 2006/6/8, Wayne Fay [EMAIL PROTECTED]: This is all theory... Perhaps while writing the docs, someone involved with Maven development thought it might be useful to have a src/main/config directory and so it was included in docs, but since it was never implemented in the code, it is not being used today. Perhaps file a JIRA bug and request that references to this config directory be removed if it is not actually being used, or ask for clarification on the proper usage of the directory, etc. Wayne On 6/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've seen all the reference information on it as well however Maven 2.X appears to completely ignore that directory...so I really don't understand what its real purpose is. So say I store application configuration files in there...now what? Maven doesn't read them or treat it as a source directory. The directory doesn't show up on the classpath so the application or test classes can't read anything in it. Packing doesn't package that dir so nothing in it will end up in any of your jar files. Assemblies don't assemble the dir so it won't end up in any of your assemblies. What else is there? Nothing in Maven seems to do anything with that directory so why is it a standard directory? -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 11:17 AM To: Maven Users List Subject: Re: uses for config directory? Found a reference to src/main/config in the Better Builds with Maven book (pg 273): src/main/config/ Standard location for application configuration files. So I guess you'd use that directory for application configuration files. But I have never personally used it, as of this point. Wayne On 6/8/06, Wayne Fay [EMAIL PROTECTED] wrote: What version of Maven? What config directory? Where did you read about this config directory etc? Wayne On 6/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Can someone tell me or give me an example of what the config directory is actually used for? I can't seem to figure out a reasonable use for this directory. Maven doesn't actually appear to do anything with this dir. It doesn't end up on the classpath that I can tell, packaging and assemblies ignore it, you can't filter stuff in it. What do you actually do with it? ---Rudy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException in Release Plugin 2.0-beta-4
uhm, not yet, I guess. I was off the list for a couple of days, so sorry for not replying. You will find the issue soon. Stefan 2006/5/24, Mark Hobson [EMAIL PROTECTED]: Was an issue raised for this? On 23/05/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Yup, solves the problem thank. On 5/23/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: I think you'll can fix your pb if you define the version of the extension in your pom. File an issue about it and we'll fix this problem. Emmanuel Stefan Hübner a écrit : Any news on this issue, Emmanuel? Stefan 2006/5/19, Stefan Hübner [EMAIL PROTECTED]: Hi Emmanuel, sorry for the delay! 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: The pb seems to be in extension rewriting. Do you have some extensions in your poms? Do you have a version for them? yes, there's an extension defined in the parent POM: ... groupIdki-commons/groupId artifactIdki-commons-parent/artifactId packagingpom/packaging nameKI Commons Parent/name version1.1/version build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh-external/artifactId /extension /extensions as you see, there's no version to the wagen-extension. is that problematic? Stefan Stefan Hübner a écrit : oh, sorry! But, yes there is a version in my pom: ?xml version=1.0 encoding=UTF-8? project parent artifactIdki-commons-parent/artifactId groupIdki-commons/groupId version1.1/version /parent modelVersion4.0.0/modelVersion groupIdki-commons/groupId artifactIdki-foundation/artifactId nameKI Foundation/name version1.17.2-SNAPSHOT/version ... Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: I didn't talk about release plugin version but about your pom version Emmanuel Stefan Hübner a écrit : no, but the latest version of maven-release-plugin in my local repository is 2.0-beta-4 Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: Do you have a version defined in your pom? Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException in Release Plugin 2.0-beta-4
OK. There's an issue beeing filed under MRELEASE-122 now. see http://jira.codehaus.org/browse/MRELEASE-122 Stefan 2006/5/28, Stefan Hübner [EMAIL PROTECTED]: uhm, not yet, I guess. I was off the list for a couple of days, so sorry for not replying. You will find the issue soon. Stefan 2006/5/24, Mark Hobson [EMAIL PROTECTED]: Was an issue raised for this? On 23/05/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Yup, solves the problem thank. On 5/23/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: I think you'll can fix your pb if you define the version of the extension in your pom. File an issue about it and we'll fix this problem. Emmanuel Stefan Hübner a écrit : Any news on this issue, Emmanuel? Stefan 2006/5/19, Stefan Hübner [EMAIL PROTECTED]: Hi Emmanuel, sorry for the delay! 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: The pb seems to be in extension rewriting. Do you have some extensions in your poms? Do you have a version for them? yes, there's an extension defined in the parent POM: ... groupIdki-commons/groupId artifactIdki-commons-parent/artifactId packagingpom/packaging nameKI Commons Parent/name version1.1/version build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh-external/artifactId /extension /extensions as you see, there's no version to the wagen-extension. is that problematic? Stefan Stefan Hübner a écrit : oh, sorry! But, yes there is a version in my pom: ?xml version=1.0 encoding=UTF-8? project parent artifactIdki-commons-parent/artifactId groupIdki-commons/groupId version1.1/version /parent modelVersion4.0.0/modelVersion groupIdki-commons/groupId artifactIdki-foundation/artifactId nameKI Foundation/name version1.17.2-SNAPSHOT/version ... Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: I didn't talk about release plugin version but about your pom version Emmanuel Stefan Hübner a écrit : no, but the latest version of maven-release-plugin in my local repository is 2.0-beta-4 Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: Do you have a version defined in your pom? Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException in Release Plugin 2.0-beta-4
Any news on this issue, Emmanuel? Stefan 2006/5/19, Stefan Hübner [EMAIL PROTECTED]: Hi Emmanuel, sorry for the delay! 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: The pb seems to be in extension rewriting. Do you have some extensions in your poms? Do you have a version for them? yes, there's an extension defined in the parent POM: ... groupIdki-commons/groupId artifactIdki-commons-parent/artifactId packagingpom/packaging nameKI Commons Parent/name version1.1/version build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh-external/artifactId /extension /extensions as you see, there's no version to the wagen-extension. is that problematic? Stefan Stefan Hübner a écrit : oh, sorry! But, yes there is a version in my pom: ?xml version=1.0 encoding=UTF-8? project parent artifactIdki-commons-parent/artifactId groupIdki-commons/groupId version1.1/version /parent modelVersion4.0.0/modelVersion groupIdki-commons/groupId artifactIdki-foundation/artifactId nameKI Foundation/name version1.17.2-SNAPSHOT/version ... Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: I didn't talk about release plugin version but about your pom version Emmanuel Stefan Hübner a écrit : no, but the latest version of maven-release-plugin in my local repository is 2.0-beta-4 Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: Do you have a version defined in your pom? Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: some questions
Hi Thorsten, 2006/5/20, Thorsten Düvelmeyer [EMAIL PROTECTED]: Hello, i'm quiet new with maven and have these questions: In the maven2 book a read: To set up Jetty, download the Jetty 5.1.10 server bundle from the book's Web site and copy it to the repository directory. Does anyone have a link for me? I didn't found it yet? go to http://jetty.mortbay.org/jetty/index.html. you should find what you're looking for. Where i can find the Repository Manager? That one isn't ready yet. Its development seems to be lacking progress... How i can put all needed files into the shared repository? Just copy it from the local repo? Can I bring up a shared repository with a normal web server (IIS)? What exactly do you mean by shared repository? If you're going to establish a company wide repository, see the description at http://maven.apache.org/guides/introduction/introduction-to-repositories.html (chapter Internal Repositories). Once set up, you can deploy 3rd-party-files by invoking mvn deploy:deploy-file. see description of deploy plugin for further details on usage. What is the easiest way to make a developer maven installation make working with the new shared repo instead of repo1.maven.org? What is to do for eclipse? have a look at http://maven.apache.org/guides/index.html (chapter development guides). And my last one: I have a Serena Version Manager as SCM plattform. Can i work with continuum and version manager? I don't found a plugin ;-( What I tried is a file as scm connection, but than I only get a No file changed and in the output window Error: with no exception sorry Thorsten, no clue on that one. cheers, Stefan
Re: NullPointerException in Release Plugin 2.0-beta-4
Hi Emmanuel, sorry for the delay! 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: The pb seems to be in extension rewriting. Do you have some extensions in your poms? Do you have a version for them? yes, there's an extension defined in the parent POM: ... groupIdki-commons/groupId artifactIdki-commons-parent/artifactId packagingpom/packaging nameKI Commons Parent/name version1.1/version build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh-external/artifactId /extension /extensions as you see, there's no version to the wagen-extension. is that problematic? Stefan Stefan Hübner a écrit : oh, sorry! But, yes there is a version in my pom: ?xml version=1.0 encoding=UTF-8? project parent artifactIdki-commons-parent/artifactId groupIdki-commons/groupId version1.1/version /parent modelVersion4.0.0/modelVersion groupIdki-commons/groupId artifactIdki-foundation/artifactId nameKI Foundation/name version1.17.2-SNAPSHOT/version ... Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: I didn't talk about release plugin version but about your pom version Emmanuel Stefan Hübner a écrit : no, but the latest version of maven-release-plugin in my local repository is 2.0-beta-4 Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: Do you have a version defined in your pom? Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException in Release Plugin 2.0-beta-4
no, but the latest version of maven-release-plugin in my local repository is 2.0-beta-4 Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: Do you have a version defined in your pom? Emmanuel Stefan Hübner a écrit : Hi folks, I'm getting a NullPointerException when invoking mvn release:prepare -DdryRun=true (don't know, if the dryRun-parameter makes any difference). See the stack trace below. Any thoughts on this issue? cheers, Stefan java.lang.NullPointerException at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.updateDomVersion(AbstractRewritePomsPhase.java:388) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.rewriteExtensions(AbstractRewritePomsPhase.java:352) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:230) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:165) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:102) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:529) at org.apache.maven.plugins.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:135) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:106) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException in Release Plugin 2.0-beta-4
oh, sorry! But, yes there is a version in my pom: ?xml version=1.0 encoding=UTF-8? project parent artifactIdki-commons-parent/artifactId groupIdki-commons/groupId version1.1/version /parent modelVersion4.0.0/modelVersion groupIdki-commons/groupId artifactIdki-foundation/artifactId nameKI Foundation/name version1.17.2-SNAPSHOT/version ... Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: I didn't talk about release plugin version but about your pom version Emmanuel Stefan Hübner a écrit : no, but the latest version of maven-release-plugin in my local repository is 2.0-beta-4 Stefan 2006/5/18, Emmanuel Venisse [EMAIL PROTECTED]: Do you have a version defined in your pom? Emmanuel
NullPointerException in Release Plugin 2.0-beta-4
Hi folks, I'm getting a NullPointerException when invoking mvn release:prepare -DdryRun=true (don't know, if the dryRun-parameter makes any difference). See the stack trace below. Any thoughts on this issue? cheers, Stefan java.lang.NullPointerException at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.updateDomVersion(AbstractRewritePomsPhase.java:388) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.rewriteExtensions(AbstractRewritePomsPhase.java:352) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:230) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:165) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:102) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:529) at org.apache.maven.plugins.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:135) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:106) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Re: Maven Not Resolving Dependencies
Bruno, I first run the eclipse plugin and eclipse is able to load the dependencies. I then attempt to install, and the maven compiler gives me messages like this: /home/ole/workspaces/current/UIShowOneComponent/src/main/java/TestComponent.java:[1,29] package javax.faces.component does not exist so, does this mean, that your project depends upon JSF? if so, the artifact javax.faces:jsf-api - as found in maven's central repository - can't actually be downloaded. Reason is, there's just a placeholder POM in the repo because of license considerations. this thought, the jsf-library shouldn't be referenced by eclipse either. If it does, does eclipse reference to a jar in your local maven repo or somewhere else? So eclipse sees the dependencies in the repository, but maven does not. the eclipse-plugin might have told you, to download the jsf-api.jar manually, because that JAR can't be found in the global repository. you might have a second look on the eclipse-plugin's output. just my 2c - may be, I'm misleaded Stefan
Re: Maven Not Resolving Dependencies
make sure to check this out: http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html cheers, Stefan 2006/5/18, Stefan Hübner [EMAIL PROTECTED]: Bruno, I first run the eclipse plugin and eclipse is able to load the dependencies. I then attempt to install, and the maven compiler gives me messages like this: /home/ole/workspaces/current/UIShowOneComponent/src/main/java/TestComponent.java:[1,29] package javax.faces.component does not exist so, does this mean, that your project depends upon JSF? if so, the artifact javax.faces:jsf-api - as found in maven's central repository - can't actually be downloaded. Reason is, there's just a placeholder POM in the repo because of license considerations. this thought, the jsf-library shouldn't be referenced by eclipse either. If it does, does eclipse reference to a jar in your local maven repo or somewhere else? So eclipse sees the dependencies in the repository, but maven does not. the eclipse-plugin might have told you, to download the jsf-api.jar manually, because that JAR can't be found in the global repository. you might have a second look on the eclipse-plugin's output. just my 2c - may be, I'm misleaded Stefan
