Re: [M2] Ghost dependencies
Hi Sebastien, I don't know how the war packaging plugin handles scoperuntime/scope dependencies. I use no scope at all for required JARs and scopeprovided/scope for those, which should not be packaged inside the WAR file i.e. are available on your Container. How do you build you WAR? Markus Am Freitag, den 02.06.2006, 07:33 +0200 schrieb Sebastien Arbogast: I have trouble understanding the new dependency mechanism. I added a dependency like this in my root pom dependencyManagament section: dependency groupIdjakarta-regexp/groupId artifactIdjakarta-regexp/artifactId version1.4/version scoperuntime/scope /dependency It's not the only one, I've added several ones like that and they all appear in the resulting webapp WEB-INF/lib directory, except for this one. There is no exclude on jakarta-regexp in other dependencies, and I can't find what's wrong. Any idea? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Getting Started / Problem with plugin
Hello Wayne, this helped ! I was assuming that all the settings are done in the directory in which I installed maven. Now I can carry on with the next step. Thank you very much for your support ! François -- View this message in context: http://www.nabble.com/Getting-Started---Problem-with-plugin-t1704376.html#a4674906 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Free book on maven 2.0
There are some typo remaining like the the 2006/6/2, Carlos Sanchez [EMAIL PROTECTED]: Not yet, I hope it will be soon. On 6/1/06, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 6/1/06, Brett Porter [EMAIL PROTECTED] wrote: Well, then - the users have spoken! http://maven.apache.org/articles.html Btw, is the printed book available for sales somewhere? Have found no pointer on the Mergere site and Amazon doesn't know it. -- Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain) - 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: Getting Started / Problem with plugin
Wayne, My settings.xml is in my maven directory. Which I added as my maven home directory and t all works fine for me. Although i dont use a proxy. Ben On 6/2/06, Francois Vandewalle [EMAIL PROTECTED] wrote: Hello Wayne, this helped ! I was assuming that all the settings are done in the directory in which I installed maven. Now I can carry on with the next step. Thank you very much for your support ! François -- View this message in context: http://www.nabble.com/Getting-Started---Problem-with-plugin-t1704376.html#a4674906 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Ghost dependencies
Hello, 2.1-SNAPSHOT of the war plugin only includes dependencies with a runtime scope for exploded,inplace and war goals. I think by default an artifact has a compile scope unless you modify the default scope then it shouldn't be included in the war. pete marvin Markus Reinhardt wrote: Hi Sebastien, I don't know how the war packaging plugin handles scoperuntime/scope dependencies. I use no scope at all for required JARs and scopeprovided/scope for those, which should not be packaged inside the WAR file i.e. are available on your Container. How do you build you WAR? Markus Am Freitag, den 02.06.2006, 07:33 +0200 schrieb Sebastien Arbogast: I have trouble understanding the new dependency mechanism. I added a dependency like this in my root pom dependencyManagament section: dependency groupIdjakarta-regexp/groupId artifactIdjakarta-regexp/artifactId version1.4/version scoperuntime/scope /dependency It's not the only one, I've added several ones like that and they all appear in the resulting webapp WEB-INF/lib directory, except for this one. There is no exclude on jakarta-regexp in other dependencies, and I can't find what's wrong. Any idea?
Re: mvn (shell script) too old?
Maven2 use M2_HOME and not MAVEN_HOME. MAVEN_HOME is used by maven1 Emmanuel Vitaly Berdinskikh a écrit : Hi users. In mvn (shell script) present old strings. ... if [ -z $M2_HOME ] ; then # try to find MAVEN if [ -d /opt/m2 ] ; then MAVEN_HOME=/opt/m2 fi if [ -d $HOME/m2 ] ; then MAVEN_HOME=$HOME/m2 fi ## resolve links - $0 may be a link to maven's home PRG=$0 # need this for relative symlinks while [ -h $PRG ] ; do ls=`ls -ld $PRG` link=`expr $ls : '.*- \(.*\)$'` if expr $link : '/.*' /dev/null; then PRG=$link else PRG=`dirname $PRG`/$link fi done saveddir=`pwd` M2_HOME=`dirname $PRG`/.. # make it fully qualified M2_HOME=`cd $M2_HOME pwd` cd $saveddir # echo Using m2 at $M2_HOME fi ... MAVEN_HOME is old name M2_HOME? In mvn.bat MAVEN_HOME not present. Also MAVEN_HOME not use is shell script (only accept value). Please, fix it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bypass compliation error
We are in an iterative mode of project. So there will be developement undergoing in a project during Testing for a previous iteration. So there will be chances of having uncompiled code in a project which can be totally ignored. Any ways thanks for the advice :-) -- View this message in context: http://www.nabble.com/Bypass-compliation-error-t1705845.html#a4676630 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mvn install:install
I it possible to force maven to generate POM files every time when command mvn install:install-file -DgroupId=somegroup -DartifactId=someartifact -Dversion=1.0 -Dpackaging=jar -Dfile=./package.jar Right now maven tries to dowload POM every time when JAR file is used for compilation etc. -- Eugene N Dzhurinsky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn install:install
You need another parameter: mvn install:install-file -DgroupId=somegroup -DartifactId=someartifact -Dversion=1.0 -Dpackaging=jar -Dfile=./package.jar -DgeneratePom=true - Original Message - From: Eugeny N Dzhurinsky [EMAIL PROTECTED] To: users@maven.apache.org Sent: Friday, June 02, 2006 12:52 PM Subject: mvn install:install I it possible to force maven to generate POM files every time when command mvn install:install-file -DgroupId=somegroup -DartifactId=someartifact -Dversion=1.0 -Dpackaging=jar -Dfile=./package.jar Right now maven tries to dowload POM every time when JAR file is used for compilation etc. -- Eugene N Dzhurinsky - 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: mvn install:install
On Fri, Jun 02, 2006 at 12:59:10PM +0100, Kieran Brady wrote: You need another parameter: mvn install:install-file -DgroupId=somegroup -DartifactId=someartifact -Dversion=1.0 -Dpackaging=jar -Dfile=./package.jar -DgeneratePom=true Really. Thanks! -- Eugene N Dzhurinsky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Problem deploying with maven 2 and Ant
On 5/30/06, Roland Asmann [EMAIL PROTECTED] wrote: Or just forget about the ant-part and use the jboss-maven-plugin! (See also this thread: Unable to locate local repo in Mac-OSX(how to call ant from maven)) plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-maven-plugin/artifactId configuration jbossHome/path/to/jboss/jbossHome /configuration /plugin And then run one of its goals (deploy / harddeploy) I'm using this plugin too. It kind of works. What I really don't like is that I have to do a mvn install in my project's top level directory and then a jboss:deploy in the ear module directory. Is there any way around that? S. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn install:install
On Friday 02 June 2006 7:59 am, Kieran Brady wrote: You need another parameter: mvn install:install-file -DgroupId=somegroup -DartifactId=someartifact -Dversion=1.0 -Dpackaging=jar -Dfile=./package.jar -DgeneratePom=true That's a new one on me too! I just learned and used this command for the first time yesterday afternoon and I did note the missing POM but thought nothing of it. Thanx a heap! --- Clifton C. Craig, Software Engineer Intelligent Computer Systems - A Division of GBG [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
resolving and including dependency libraries
I'm trying to rework legacy app to use Maven. This application consists of
several modules:
* Common
* MPL
* MML
Where MPL and MML depends of Common, and MML depends of Common and MPL
I separated code for these modules and application builds fine now.
After running mvn package I got 3 JAR files Common-1.0.jar, MML-1.0.jar and
MPL-1.0.jar.
Application itself is distributed using InstallAnywhere, and I would like to
keep current directory structure as it is now.
From this point I have few questions:
1) Right now required JAR files for application are located at
${modulename}/lib directory (or ${modulename}/WEB-INF/lib). I think it could
be good idea to specify dependencies using POM. So I need to know how can I
tell Maven to copy required JAR files into appropriate directory (for example
log4j.jar, ibatis.jar etc)
2) Is it possible to copy application's JAR files (Common*-1.0.jar,
MML-1.0.jar and MML-1.0.jar) into appropriate directories with solving
dependencies?
For instance MPL/lib should contain Common-1.0.jar and MPL-1.0.jar, and
MML/WEB-INF/lib should contain Common-1.0.jar, MPL-1.0.jar and MML-1.0.jar, so
all libraries module depends on should be kept inside specific module's
library directory.
Thanks in advance and sorry for probably trivial questions!
--
Eugene N Dzhurinsky
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn install:install
No probs. It would be nice if it was true by default IMO, all that typing is error prone. It was introduced in version 2.1 of the install plugin: http://jira.codehaus.org/browse/MINSTALL-6 - Original Message - From: Clifton Craig [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Friday, June 02, 2006 2:10 PM Subject: Re: mvn install:install On Friday 02 June 2006 7:59 am, Kieran Brady wrote: You need another parameter: mvn install:install-file -DgroupId=somegroup -DartifactId=someartifact -Dversion=1.0 -Dpackaging=jar -Dfile=./package.jar -DgeneratePom=true That's a new one on me too! I just learned and used this command for the first time yesterday afternoon and I did note the missing POM but thought nothing of it. Thanx a heap! --- Clifton C. Craig, Software Engineer Intelligent Computer Systems - A Division of GBG [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Problem deploying with maven 2 and Ant
Bind it to a certain phase in your ear so that it gets run automatically, eg:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjboss-maven-plugin/artifactId
inheritedtrue/inherited
configuration
jbossHome${appserver.home}/jbossHome
/configuration
executions
execution
iddeploy/id
phaseverify/phase
goals
goalharddeploy/goal
/goals
/execution
/executions
/plugin
Roland
On Friday 02 June 2006 15:00, Stefan Arentz wrote:
On 5/30/06, Roland Asmann [EMAIL PROTECTED] wrote:
Or just forget about the ant-part and use the jboss-maven-plugin! (See
also this thread: Unable to locate local repo in Mac-OSX(how to call ant
from maven))
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjboss-maven-plugin/artifactId
configuration
jbossHome/path/to/jboss/jbossHome
/configuration
/plugin
And then run one of its goals (deploy / harddeploy)
I'm using this plugin too. It kind of works. What I really don't like
is that I have to do a mvn install in my project's top level directory
and then a jboss:deploy in the ear module directory. Is there any way
around that?
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]
Problem with filtering of property files
Hi,
I have a problem filtering property files (using maven 2.0.4):
Setup:
...
build
finalNameplanb/finalName
sourceDirectorysrc/java/sourceDirectory
testSourceDirectorysrc/test/testSourceDirectory
filters
filter${basedir}/context.properties/filter
/filters
resources
resource
directory${basedir}/src/conf/directory
filteringtrue/filtering
includes
includecontext.xml/include
includeversion.properties/include
/includes
/resource
...
/resources
...
/build
...
Filtering of the above context.xml works fine, but filtering of
version.properties dosn't seem to work?
If I create a version.xml file instead an replaces it with
version.properties again it works... (any difference for *.xml contra
*.properties filtering?)
Ideally I would like to use settings.xml as filter instead of
context.properties but it only seems to work with context.properties...
Can anybody please help me with
1. why isn't version.properties being filtered?
2. why can't I use settings.xml as a filter?
Best Regards,
Claus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
maven-was-plugin
Hello, I d like to make ear deployment automatically on websphere 5.1. After some search, David Karlsen's plugin [maven-was-plugin] seems to fit exactly my need. But there are some issues that I can not resolve. To sum up, there are some points I made previously: - WAS_HOME is set to installation directory of used server ([C:\Program Files\IBM\Rational\SDP\6.0\runtimes\base_v51] in my case) - JAVA_HOME is set to WAS'jre because the deployment script need it. (JAVA_HOME=%WAS_HOME%\java) - %WAS_HOME%/bin and %WAS_HOME%\deploytool\itp are adding in the PATH PATH=%WAS_HOME%/bin;%WAS_HOME%\deploytool\itp;%PATH% - WAS_EXT_DIRS=%WAS_HOME%\java\lib;%WAS_HOME%\lib\classes;%WAS_HOME%\lib\lib;% WAS_HOME%\lib\lib\ext;%WAS_HOME%\lib\web\help - in the project pom file, I also declared the plugin repository of maven-was-plugin. NB: to be sure, I replaced all used env variables by its real value. Finally mvn returns following error: [ERROR] The java class is not found: Files\IBM\Rational\SDP\6/0\runtimes\base_v51\java\lib;C:\Program It seems that space character in the path is not allowed... But I do not want to reinstall all. Does anyone have created unit test of this plugin ? or find a solution ? Thanks for your help, Andre This message is intended for the addressee or its representative only. Any form of unauthorized use, publication, reproduction, copying or disclosure of the content of this e-mail is not permitted. If you are not the intended recipient of this e-mail message and its contents, please notify the sender immediately and delete this message and all its attachments subsequently. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
REPOST: [M2] external config of artifact and dependencies
Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have to alter the exploded web application directory after it is installed and add the log4j.properties file. That seems like a great deal of work and a kludge . . . what am I missing here? -Original Message- From: Fernandez, Carlos Sent: Thursday, June 01, 2006 10:49 AM To: users@maven.apache.org Subject: RE: [M2] questions about migrating to maven Carlos, EXTERNAL CONFIGURATION OF AN ARTIFACT AND DEPENDENCIES Sorry for belaboring this point - but I tend to think better in concrete terms. Let me walk through a scenario just to make sure I understand this. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have to alter the exploded web application directory after it is installed and add the log4j.properties file. That seems like a great deal of work and a kludge . . . what am I missing here? BTW - My father's family is from Galicia, with a lot of them living in a coruna. My parents have been a few times and have loved each and every trip. I hope to visit with my wife and daughter soon, and see a bit of the old country ;) Carlos -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, May 30, 2006 12:50 PM To: Maven Users List Subject: Re: [M2] questions about migrating to maven On 5/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Carlos, -- re FILTERING PROPERTIES FILES FOR ENVIRONMENTS My suggestion is to externalie that configuration options in a
Re: resolving and including dependency libraries
Hi,
maybe the dependecy-maven-plugin at http://mojo.codehaus.org/dependency-maven-plugin/ and
the assembly-plugin at http://maven.apache.org/plugins/maven-assembly-plugin/ are what you
are looking for.
-Tim
Eugeny N Dzhurinsky schrieb:
I'm trying to rework legacy app to use Maven. This application consists of
several modules:
* Common
* MPL
* MML
Where MPL and MML depends of Common, and MML depends of Common and MPL
I separated code for these modules and application builds fine now.
After running mvn package I got 3 JAR files Common-1.0.jar, MML-1.0.jar and
MPL-1.0.jar.
Application itself is distributed using InstallAnywhere, and I would like to
keep current directory structure as it is now.
From this point I have few questions:
1) Right now required JAR files for application are located at
${modulename}/lib directory (or ${modulename}/WEB-INF/lib). I think it could
be good idea to specify dependencies using POM. So I need to know how can I
tell Maven to copy required JAR files into appropriate directory (for example
log4j.jar, ibatis.jar etc)
2) Is it possible to copy application's JAR files (Common*-1.0.jar,
MML-1.0.jar and MML-1.0.jar) into appropriate directories with solving
dependencies?
For instance MPL/lib should contain Common-1.0.jar and MPL-1.0.jar, and
MML/WEB-INF/lib should contain Common-1.0.jar, MPL-1.0.jar and MML-1.0.jar, so
all libraries module depends on should be kept inside specific module's
library directory.
Thanks in advance and sorry for probably trivial questions!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting Started / Problem with plugin
Thanks, Ben. Perhaps I misspoke. From my MAVEN_HOME/conf/settings.xml file:
| This is the configuration file for Maven. It can be specified at two levels:
|
| 1. User Level. This settings.xml file provides configuration for a
single user,
| and is normally provided in $HOME/.m2/settings.xml.
|
| 2. Global Level. This settings.xml file provides configuration for all maven
| users on a machine (assuming they're all using the same maven
| installation). It's normally provided in
| ${maven.home}/conf/settings.xml.
So it would appear that both of those locations are valid. I
personally have never used the MAVEN_HOME/conf file location.
But if Francois had the same exact file in MAVEN_HOME/conf, with the
proxy defined etc, and it wasn't being picked up until he copied it to
~/.m2/, then I don't know what's going on with his machine.
Wayne
On 6/2/06, ben short [EMAIL PROTECTED] wrote:
Wayne,
My settings.xml is in my maven directory. Which I added as my maven
home directory and t all works fine for me. Although i dont use a
proxy.
Ben
On 6/2/06, Francois Vandewalle [EMAIL PROTECTED] wrote:
Hello Wayne,
this helped !
I was assuming that all the settings are done in the directory in which I
installed maven.
Now I can carry on with the next step.
Thank you very much for your support !
François
--
View this message in context:
http://www.nabble.com/Getting-Started---Problem-with-plugin-t1704376.html#a4674906
Sent from the Maven - Users forum at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Snapshot repository
Hi all, I have been having problem with snapshot repositories lately. My internal repository doesn't want to serve snapshot anymore. I think it has begun with Maven 2.0.4 since it was working well in the past. I know some other people have complained about the same thing so I was wondering if this a known bug and if there is JIRA filled. Any news on this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REPOST: [M2] external config of artifact and dependencies
Hi, you can define different profiles for the environments you deploy to in your pom. In these profiles you can then define resource locations to pull the config files from. -Tim [EMAIL PROTECTED] schrieb: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have to alter the exploded web application directory after it is installed and add the log4j.properties file. That seems like a great deal of work and a kludge . . . what am I missing here? -Original Message- From: Fernandez, Carlos Sent: Thursday, June 01, 2006 10:49 AM To: users@maven.apache.org Subject: RE: [M2] questions about migrating to maven Carlos, EXTERNAL CONFIGURATION OF AN ARTIFACT AND DEPENDENCIES Sorry for belaboring this point - but I tend to think better in concrete terms. Let me walk through a scenario just to make sure I understand this. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have to alter the exploded web application directory after it is installed and add the log4j.properties file. That seems like a great deal of work and a kludge . . . what am I missing here? BTW - My father's family is from Galicia, with a lot of them living in a coruna. My parents have been a few times and have loved each and every trip. I hope to visit with my wife and daughter soon, and see a bit of the old country ;) Carlos -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, May 30, 2006 12:50 PM To: Maven Users List Subject: Re: [M2]
Re: REPOST: [M2] external config of artifact and dependencies
One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have to alter the exploded web application directory after it is installed and add the log4j.properties file. That seems like a great deal of work and a kludge . . . what am I missing here? -Original Message- From: Fernandez, Carlos Sent: Thursday, June 01, 2006 10:49 AM To: users@maven.apache.org Subject: RE: [M2] questions about migrating to maven Carlos, EXTERNAL CONFIGURATION OF AN ARTIFACT AND DEPENDENCIES Sorry for belaboring this point - but I tend to think better in concrete terms. Let me walk through a scenario just to make sure I understand this. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have
Re: maven-was-plugin
Spaces in directories on Windows are a known issue in Java when dealing with RMI. And while I don't use it myself, its a good guess that this plugin uses RMI to talk to the WAS for deploying your EAR. You will need to reinstall to a directory with no spaces. Alternatively, you could perhaps use the subst command to create a fake k:\ drive (or similar) for your c:\program files\ibm directory. Then your path would be k:\rational\... which has no spaces. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I d like to make ear deployment automatically on websphere 5.1. After some search, David Karlsen's plugin [maven-was-plugin] seems to fit exactly my need. But there are some issues that I can not resolve. To sum up, there are some points I made previously: - WAS_HOME is set to installation directory of used server ([C:\Program Files\IBM\Rational\SDP\6.0\runtimes\base_v51] in my case) - JAVA_HOME is set to WAS'jre because the deployment script need it. (JAVA_HOME=%WAS_HOME%\java) - %WAS_HOME%/bin and %WAS_HOME%\deploytool\itp are adding in the PATH PATH=%WAS_HOME%/bin;%WAS_HOME%\deploytool\itp;%PATH% - WAS_EXT_DIRS=%WAS_HOME%\java\lib;%WAS_HOME%\lib\classes;%WAS_HOME%\lib\lib;% WAS_HOME%\lib\lib\ext;%WAS_HOME%\lib\web\help - in the project pom file, I also declared the plugin repository of maven-was-plugin. NB: to be sure, I replaced all used env variables by its real value. Finally mvn returns following error: [ERROR] The java class is not found: Files\IBM\Rational\SDP\6/0\runtimes\base_v51\java\lib;C:\Program It seems that space character in the path is not allowed... But I do not want to reinstall all. Does anyone have created unit test of this plugin ? or find a solution ? Thanks for your help, Andre This message is intended for the addressee or its representative only. Any form of unauthorized use, publication, reproduction, copying or disclosure of the content of this e-mail is not permitted. If you are not the intended recipient of this e-mail message and its contents, please notify the sender immediately and delete this message and all its attachments subsequently. - 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] Ghost dependencies
2.1-SNAPSHOT of the war plugin only includes dependencies with a runtime scope for exploded,inplace and war goals. I think by default an artifact has a compile scope unless you modify the default scope then it shouldn't be included in the war. I don't know which version of the war plugin I'm using but what disturbs me is that, for all the other dependencies in my root pom, a runtime scope is enough to have them included in the WAR, sometimes I don't even mention them in the dependencies section of my web module pom. But you're right: I just added it to my web module pom and it works great. Thank you very much! -- Sébastien Arbogast The Epseelon Project : http://www.epseelon.net Blog : http://sebastien-arbogast.epseelon.net TagSpot : http://www.tagspot.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Stand-alone app
Hi Tim, Hi Tim. Yes, I'm using the assembly plugin to copy the dependencies into a subdirectory called ./lib, and I'm using the jar plugin to build the executable jar, and actually everything works basically OK. My only problem is that the jar plugin is adding the dependency jar files into the executable artifact jar. These are unnecessary and only increase the size of executable jar file. There is no way I've found to put a jarred jar library onto the classpath without writing extra code in your executable to support this. The jar libraries need to reside outside the executable jar in the normal filesystem to be easily accessible. For now, I'm just removing the unneeded dependency jars from the executable jar manually, but I'm curious how one might go about configuring jar:jar so that it properly configures the manifest.mf without also rolling the dependency jars into its artifact. Here is my POM: 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 groupIdcom.galaxyusa.pairfinder/groupId artifactIdpairfinder/artifactId packagingjar/packaging version0.9/version nameMaven Quick Start Archetype/name urlhttp://maven.apache.org/url dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdorg.skroople/groupId artifactIdskroople/artifactId version0.7/version /dependency /dependencies build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0/version configuration source1.5/source target1.5/target /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest mainClasscom.galaxyusa.pairfinder.PairFinder/mainClass addClasspathtrue/addClasspath classpathPrefixlib/classpathPrefix /manifest /archive /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId configuration descriptors descriptorsrc/main/assembly/stand-alone-app.xml/descriptor /descriptors /configuration /plugin /plugins /pluginManagement /build /project The assembly configuration descriptor is this: assembly idstand-alone-app/id formats formatzip/format /formats fileSets fileSet directorytarget/directory outputDirectory./outputDirectory includes include*.jar/include /includes /fileSet /fileSets dependencySets dependencySet outputDirectory/lib/outputDirectory unpackfalse/unpack scoperuntime/scope /dependencySet /dependencySets /assembly Note: this project has a number of transitive dependencies that come through the dependency for skroople. So far, it's still feeling to me like there should be a goal in the assembly plugin that handles building a standalone app and optionally zips it up into a zip file or tarball, depending on the platform. It could even have sensible defaults such that if you're happy enough with a stand-alone app set up the way I'm doing it here, (with the jar library dependencies copied into ./lib) all you would have to do is tell it what your main
Maven2 book version 1.1?
When I started reading the new Maven2 book, I noticed quite a few mistakes here and there and I tried to mark them in the PDF in order to report them later... until I noticed that the Errata section on Mergere's site was already quite complete. My question is, do you plan to release an updated version of the book with errata corrected? Because reading the book on a screen is already not very comfortable, but reading it in parallel with the errata page can be a real pain. -- Sébastien Arbogast The Epseelon Project : http://www.epseelon.net Blog : http://sebastien-arbogast.epseelon.net TagSpot : http://www.tagspot.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resolving and including dependency libraries
On Fri, Jun 02, 2006 at 04:35:00PM +0200, Tim Kettler wrote: Hi, maybe the dependecy-maven-plugin at http://mojo.codehaus.org/dependency-maven-plugin/ and the assembly-plugin at http://maven.apache.org/plugins/maven-assembly-plugin/ are what you are looking for. http://mojo.codehaus.org/dependency-maven-plugin/ Looks like that's what I need. Thanks! -- Eugene N Dzhurinsky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Change build order for multi-module build
Thanks Wayne for the suggestion. Yes, my parent is only a pom, interited by the module poms. I have considered refactoring into a separate module for the site generation (a logical parent, but technically a sibling to the modules that it is supposed to aggregate information from), just to get the ordering right. The problem however is that the approach to site report aggregation that I plan to use (copied from the javadoc and jxr plugin approach to aggregation) depends on the ability to get hold of the MavenProject objects for the modules (in order to fetch module specific settings). So I seem to be caught in a catch 22? /Bjorn -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: den 2 juni 2006 00:12 To: Maven Users List Subject: Re: Change build order for multi-module build Does your parent actually contain code? Or only a pom which is inherited by the module poms with the parent tag? If it has code, I'd restructure to put that code in another module subdirectory, add proper dependencies in that new module's pom, and allow Maven to figure out the proper build order etc with regular dependency resolution. Can't guarantee it will fix things but I'd try that first. Wayne On 6/1/06, Björn Beskow [EMAIL PROTECTED] wrote: Hi I'm working on enhancing the Cobertura plugin to aggregate coverage results when generating a report in a multi-module setting. In order to be able to aggregate coverage results from the separate sub-modules, I would need the sub-modules to be processed before the parent module. But it seems the parent project is always processed first. Does anyone know if there is a way to control/change that ordering? For example, with the following structure parent |- module1 |- module2 when running 'mvn site' in the parent project, the parent will be processed first, followed by module1 and module2. Any help greatly appreciated! /Björn - 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]
APT: Images and links
Hi,
I noticed that with APT, the following constructs are supported:
{{}} for hyperlinks, [] to place images in the generated site.
Is there some way to combine those, like putting an image which is
surrounded by a hyperref? Like {{{http://example.com}
[/images/myimage.png]}}. I tried this one, but it simply puts a link
named '[/images/myimage.png]' in my site.
Regards, Erhard
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Problems while running maven2
Hi everybody. I'm sorry for my poor English, but I'm French and I'm not fluent ;-) I am trying to use maven2, but every time I try some commands line I've got this error: FATAL ERROR INFO org.apache.maven.profiles.ProfileManager.LoadSettingsProfiles(Lorg/apache/maven/settings/Settings;)V at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273) I'm using windows XP, and maven 2.0.4... Thanks in advance for every tips. regards greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Need a release to run mvn release:prepare/perform
Title: Message Hi, I need a released version of the maven-csharp stuff in order to be able to use the maven release plugin. Indeed, with the SNAPSHOT version, the following occurs: mvn release:prepare [INFO] [release:prepare][INFO] Verifying that there are no local modifications...[INFO] Executing: svn --non-interactive status[INFO] Working directory: D:\dev\projects\ird-pricer[INFO] Checking dependencies and plugins for snapshots ...[INFO] [ERROR] BUILD FAILURE[INFO] [INFO] Can't release project due to non released dependencies : org.apache.maven.plugins:maven-vstudio-plugin:maven-plugin:1.0.RC6-SNAPSHOT:runtimein project 'IRD Pricer POM' (com.calyon.fovanille.ird-pricer.poms:ird-pricer:pom:0.1-SNAPSHOT)[INFO] [INFO] For more information, run Maven with the -e switch[INFO] [INFO] Total time: 8 minutes 10 seconds[INFO] Finished at: Fri Jun 02 14:38:37 CEST 2006[INFO] Final Memory: 8M/16M[INFO] What can you done asap? If this is not possible at the project level, is there a way to build a non-SNAPSHOT version on my own build environment? Is there any other suggestion? Best regards, Xavier Ce message et ses pièces jointes (le message) est destiné à l'usage exclusif de son destinataire. Si vous recevez ce message par erreur, merci d'en aviser immédiatement l'expéditeur et de le détruire ensuite. Le présent message pouvant être altéré à notre insu, CALYON Corporate and Investment Bank ne peut pas être engagé par son contenu. Tous droits réservés. This message and/or any attachments (the message) is intended for the sole use of its addressee. If you are not the addressee, please immediately notify the sender and then destroy the message. As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Corporate and Investment Bank. All rights reserved. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help explaining maven 2
Hi I'm a student on work placement and the company I'm working for asked me to investigate updating to maven 2. So I've been modifying one of their projects to use maven 2, they currently use maven 1. 1st, what would ye say if ye had to explain maven 2 to someone who has been using maven 1 but doesn;t know much (if anything about maven 2) 2nd, I'm trying to explain pregoals and post goals but stuck myself as how to explain it. Really because I'm not I get it myself. What I was going to say was: Plugins can be executed during a phase, this is how pregoals and postgoals are managed, i.e. pregoal could be to compile; main goal could be to create a jar; and postgoal could be to create the docs, three separate plugins will have to be used. Thanks, Brian -- View this message in context: http://www.nabble.com/Help-explaining-maven-2-t1723384.html#a4681740 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Need a release to run mvn release:prepare/perform
I doubt you can get a release of this plugin soon, you can cut the release yourself internally by fetching the latest source from svn and give it a version number like 1.0-[somenumber], build, and deploy to your internal repository. I use svn revision number for the version, just incase i need to go back to the source -D On 6/2/06, Galleri, Xavier (CALYON) [EMAIL PROTECTED] wrote: Hi, I need a released version of the maven-csharp stuff in order to be able to use the maven release plugin. Indeed, with the SNAPSHOT version, the following occurs: mvn release:prepare [INFO] [release:prepare] [INFO] Verifying that there are no local modifications... [INFO] Executing: svn --non-interactive status [INFO] Working directory: D:\dev\projects\ird-pricer [INFO] Checking dependencies and plugins for snapshots ... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Can't release project due to non released dependencies : org.apache.maven.plugins:maven-vstudio-plugin:maven-plugin:1.0.RC6-SNAPSHOT:runtime in project 'IRD Pricer POM' ( com.calyon.fovanille.ird-pricer.poms:ird-pricer:pom:0.1-SNAPSHOT) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 8 minutes 10 seconds [INFO] Finished at: Fri Jun 02 14:38:37 CEST 2006 [INFO] Final Memory: 8M/16M [INFO] What can you done asap? If this is not possible at the project level, is there a way to build a non-SNAPSHOT version on my own build environment? Is there any other suggestion? Best regards, Xavier Ce message et ses pièces jointes (le message) est destiné à l'usage exclusif de son destinataire. Si vous recevez ce message par erreur, merci d'en aviser immédiatement l'expéditeur et de le détruire ensuite. Le présent message pouvant être altéré à notre insu, CALYON Corporate and Investment Bank ne peut pas être engagé par son contenu. Tous droits réservés. This message and/or any attachments (the message) is intended for the sole use of its addressee. If you are not the addressee, please immediately notify the sender and then destroy the message. As this message and/or any attachments may have been altered without our knowledge, its content is not legally binding on CALYON Corporate and Investment Bank. All rights reserved. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
archetype pom.xml not same as archetype-resources/pom.xml
for some reason when i create a new project from an existing archetype, the
pom.xml copied to the root of the new project has its project element
stripped of the xml namespace information and the empty dependencies
element is removed, as is the packaging element. this worked a couple of
days ago, so i can't tell if this is something that i've done or something
that's changed underneath me? any ideas?
this is my pom.xml from archetype-resources:
?xml version=1.0 encoding=UTF-8?
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;
parent
groupIdcom.mycompany.lacrs/groupId
artifactIdlacrs-parent/artifactId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
name${artifactId}/name
artifactId${artifactId}/artifactId
packagingjar/packaging
dependencies
/dependencies
/project
when i create the archetype, this is the pom that's copied to the root of
the project:
?xml version=1.0 encoding=UTF-8?
project
parent
artifactIdlacrs-parent/artifactId
groupIdcom.mycompany.lacrs/groupId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
artifactIdtestjava/artifactId
nametestjava/name
/project
--
View this message in context:
http://www.nabble.com/archetype-pom.xml-not-same-as-archetype-resources-pom.xml-t1723419.html#a4681828
Sent from the Maven - Users forum at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help explaining maven 2
First, I think you should grab a copy of the book discussed on the mailing-list a couple of times. Check the Maven homepage for it. Second, the pregoal-stuff is no longer available in Maven. I think you want to discuss the life-cycle. For that, there's also a nice bit of documentation on the Maven-site. Roland On Friday 02 June 2006 17:26, rebels_mascot wrote: Hi I'm a student on work placement and the company I'm working for asked me to investigate updating to maven 2. So I've been modifying one of their projects to use maven 2, they currently use maven 1. 1st, what would ye say if ye had to explain maven 2 to someone who has been using maven 1 but doesn;t know much (if anything about maven 2) 2nd, I'm trying to explain pregoals and post goals but stuck myself as how to explain it. Really because I'm not I get it myself. What I was going to say was: Plugins can be executed during a phase, this is how pregoals and postgoals are managed, i.e. pregoal could be to compile; main goal could be to create a jar; and postgoal could be to create the docs, three separate plugins will have to be used. Thanks, Brian -- View this message in context: http://www.nabble.com/Help-explaining-maven-2-t1723384.html#a4681740 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems while running maven2
Hi Gregory, could you run mvn with -e option to get stacktracee error. Tom. 2006/6/2, legrand gregory [EMAIL PROTECTED]: Hi everybody. I'm sorry for my poor English, but I'm French and I'm not fluent ;-) I am trying to use maven2, but every time I try some commands line I've got this error: FATAL ERROR INFO org.apache.maven.profiles.ProfileManager.LoadSettingsProfiles(Lorg/apache/maven/settings/Settings;)V at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:273) I'm using windows XP, and maven 2.0.4... Thanks in advance for every tips. regards greg - 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: Help explaining maven 2
Ya I've a bit of reading to do alright, tis endless!! Sorry, wrote the pregoals sentence wrong, I'm trying to explain how they're handled in maven 2 by using plugins. As in I need to say to them, goals are no longer used instead you do 1, 2, 3 ... -- View this message in context: http://www.nabble.com/Help-explaining-maven-2-t1723384.html#a4681950 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: REPOST: [M2] external config of artifact and dependencies
Are you referring to using profiles to filter properties files or otherwise tailor the build and resulting artifact to a particular environment? If that is your suggestion, I have some issues with that. In filtering the configuration information, you generate an artifact, such as a war or ear, that is tailored for an environment. Doesn't that compromise the utility of the artifact? Don't you need to be careful about where you install that artifact? Should artifacts generated with local only be installed in each developer's local repository? What about the artifacts for the testing and production environments? Should the internal repository only be used to store production artifacts? Should there be multiple shared internal repositories, one for production and one for pre-prod? It seems that this can also significantly muddy dependency management. This is why external configuration was suggested. Which I can clearly see working well for the application code I write. My code can be written to work just as well accessing properties via JNDI as it can be written to access props files on the classpath. However, what do I do with dependencies that expect their configuration settings to be on the classpath - such as log4j. This seems to be less of an issue for the jars that my projects generally produce. These tend to either be common utilities or client jars. None of these are intended to be packaged with any configuration information - it is the responsibility of the application using these resources to configure them. Just as you would with log4j. I suspect I am just spinning myself out of control on this issue. -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:45 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies Hi, you can define different profiles for the environments you deploy to in your pom. In these profiles you can then define resource locations to pull the config files from. -Tim [EMAIL PROTECTED] schrieb: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have to alter the exploded web application directory after it is installed and add the log4j.properties file. That seems like a great deal of work and a kludge . . . what am I missing here? -Original Message- From: Fernandez, Carlos Sent: Thursday, June 01, 2006 10:49 AM To: users@maven.apache.org Subject: RE: [M2] questions about migrating to maven Carlos, EXTERNAL CONFIGURATION OF AN ARTIFACT AND DEPENDENCIES Sorry for belaboring this point - but I tend to think better in concrete terms. Let me walk through a scenario just to make sure I understand this. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop
Re: site:deploy -p switch
Hi Wayne, I'm more than happy to be proven wrong, but if memory serves the '-p' switch was introduced in GNU Fileutils. It may been picked up in other utilities (let's face it, it is an extremely handy feature!), but I don't believe it is part of the POSIX standard. Even if it is, Windows is not a POSIX-compliant operating system. I would consider it a bug for any code to depend on Windows acting as if it were. On a side note, I also consider it a bug for Java code to make system calls, that's probably more personal philosophy than a technical issue... :) Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 Wayne Fay [EMAIL PROTECTED] omTo Maven Users List 06/01/2006 05:59 users@maven.apache.org PM cc Subject Please respond to Re: site:deploy -p switch Maven Users List [EMAIL PROTECTED] he.org I don't believe this is a Maven bug. Instead it looks like your FTP Server (vsFTPd) does not support the -p flag to create any missing intermediate pathname components. Here's some info I found on mkdir specs: http://www.opengroup.org/onlinepubs/009695399/utilities/mkdir.html Perhaps file a bug with the vsFTPd people? Seems like -p is a normal flag for mkdir commands in most operating systems/ftp servers... At least, you're the first person I've seen report this problem on the User list, so I can't imagine its a widespread problem. Wayne On 6/1/06, Borut Bolčina [EMAIL PROTECTED] wrote: On Windows XP, with maven 2.0.4 and site plugin 2.0-beta-5 when doing site:deploy with distributionManagement site idwebsite/id namemy project site/name urlsftp://my.server/project/url /site /distributionManagement a command mkdir -p /project/ is issued which I think is not correct When executing from cmd window C:\Documents and Settings\Borut\Desktop\Workspace\MyProjectftp my.server Connected to my.server. 220 (vsFTPd 2.0.3) User (my.server:(none)): myusername 331 Please specify the password. Password: 230 Login successful. ftp mkdir -p /project/ 257 /-p created ftp Instead of creating /project directory, the ftp client creates a directory with name -p. I think that is the reason the site:deploy fails. See bellow. C:\Documents and Settings\Borut\Desktop\Workspace\MyProjectmvn site:deploy [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'site'. [INFO] [INFO] Building MyProject [INFO]task-segment: [site:deploy] [INFO] [INFO] [site:deploy] The authenticity of host 'my.server' can't be established. RSA key fingerprint is 4a:86:2b:a7:15:29:ee:4b:10:8f:8e:73:53:b0:9e:cd. Are you sure you want to continue connecting? (yes/no): yes sftp://my.server/project - Session: Opened Executing command: mkdir -p /project/. sftp://my.server/project - Session: Disconnecting sftp://my.server/project - Session: Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Error performing commands for file transfer Exit code: 1 - mkdir: cannot create directory `/project': Permission denied [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Thu Jun 01 23:06:05 CEST 2006 [INFO] Final Memory: 7M/13M [INFO]
Re: archetype pom.xml not same as archetype-resources/pom.xml
Since you claim nothing has changed on your side, I would generally
suspect that some new archetype plugin was released in the last few
days/weeks that has changed something that you weren't aware of.
Go check your local repo for artifacts with dates newer than the last
time this executed properly. Delete them, and run mvn -o ... to see if
it works with the old code, and if so, go file a JIRA regression bug
on the plugin.
Wayne
On 6/2/06, ertnutler [EMAIL PROTECTED] wrote:
for some reason when i create a new project from an existing archetype, the
pom.xml copied to the root of the new project has its project element
stripped of the xml namespace information and the empty dependencies
element is removed, as is the packaging element. this worked a couple of
days ago, so i can't tell if this is something that i've done or something
that's changed underneath me? any ideas?
this is my pom.xml from archetype-resources:
?xml version=1.0 encoding=UTF-8?
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;
parent
groupIdcom.mycompany.lacrs/groupId
artifactIdlacrs-parent/artifactId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
name${artifactId}/name
artifactId${artifactId}/artifactId
packagingjar/packaging
dependencies
/dependencies
/project
when i create the archetype, this is the pom that's copied to the root of
the project:
?xml version=1.0 encoding=UTF-8?
project
parent
artifactIdlacrs-parent/artifactId
groupIdcom.mycompany.lacrs/groupId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
artifactIdtestjava/artifactId
nametestjava/name
/project
--
View this message in context:
http://www.nabble.com/archetype-pom.xml-not-same-as-archetype-resources-pom.xml-t1723419.html#a4681828
Sent from the Maven - Users forum at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: REPOST: [M2] external config of artifact and dependencies
I don't think my team will react nicely if I tell them that in order to have all the maven niceties we have to buy and run oracle app server or have half a dozen instances of tomcat running on our servers. Is this what people commonly do with maven built wars? What I am trying to figure out is rote for a lot of people out there. I just can't get my pea-sized brain to come up with a palatable solution. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:49 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have to alter the exploded web application directory after it is installed and add the log4j.properties file. That seems like a great deal of work and a kludge . . . what am I missing here? -Original Message- From: Fernandez, Carlos Sent: Thursday, June 01, 2006 10:49 AM To: users@maven.apache.org Subject: RE: [M2] questions about migrating to maven Carlos, EXTERNAL CONFIGURATION OF AN ARTIFACT AND DEPENDENCIES Sorry for belaboring this point - but I tend to think better in concrete terms. Let me walk through a scenario just to make sure I understand this. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter
Re: REPOST: [M2] external config of artifact and dependencies
Out of curiosity, why is programmatically configuring log4j (say in a servlet context listener) not a great idea? Kris [EMAIL PROTECTED] wrote: I don't think my team will react nicely if I tell them that in order to have all the maven niceties we have to buy and run oracle app server or have half a dozen instances of tomcat running on our servers. Is this what people commonly do with maven built wars? What I am trying to figure out is rote for a lot of people out there. I just can't get my pea-sized brain to come up with a palatable solution. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:49 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have to alter the exploded web application directory after it is installed and add the log4j.properties file. That seems like a great deal of work and a kludge . . . what am I missing here? -Original Message- From: Fernandez, Carlos Sent: Thursday, June 01, 2006 10:49 AM To: users@maven.apache.org Subject: RE: [M2] questions about migrating to maven Carlos, EXTERNAL CONFIGURATION OF AN ARTIFACT AND DEPENDENCIES Sorry for belaboring this point - but I tend to think better in concrete terms. Let me walk through a scenario just to make sure I understand this. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change
Re: Stand-alone app
Just to be sure I understand you correctly: Your problem is that the dependendcies of your
project are included in in the created jar artifact ('pairfinder-0.9.jar')?
I ask this because I can't reproduce your problem with the pom/descriptor you posted. I
just replaced your internal dependency with a dependency to commons-beanutils. When I now
run 'mvn assembly:assembly' the artifact is created with the right classpath entries in
the manifest and the zip file has the dependencies in the lib directory ???
Have you tried to run a 'mvn clean' before creating the assembly?
-Tim
Midtskogen, Erik schrieb:
Hi Tim,
Hi Tim. Yes, I'm using the assembly plugin to copy the dependencies
into a subdirectory called ./lib, and I'm using the jar plugin to
build the executable jar, and actually everything works basically OK.
My only problem is that the jar plugin is adding the dependency jar
files into the executable artifact jar. These are unnecessary and only
increase the size of executable jar file. There is no way I've found to
put a jarred jar library onto the classpath without writing extra code
in your executable to support this. The jar libraries need to reside
outside the executable jar in the normal filesystem to be easily
accessible.
For now, I'm just removing the unneeded dependency jars from the
executable jar manually, but I'm curious how one might go about
configuring jar:jar so that it properly configures the manifest.mf
without also rolling the dependency jars into its artifact.
Here is my POM:
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
groupIdcom.galaxyusa.pairfinder/groupId
artifactIdpairfinder/artifactId
packagingjar/packaging
version0.9/version
nameMaven Quick Start Archetype/name
urlhttp://maven.apache.org/url
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
dependency
groupIdorg.skroople/groupId
artifactIdskroople/artifactId
version0.7/version
/dependency
/dependencies
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0/version
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
manifest
mainClasscom.galaxyusa.pairfinder.PairFinder/mainClass
addClasspathtrue/addClasspath
classpathPrefixlib/classpathPrefix
/manifest
/archive
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors
descriptorsrc/main/assembly/stand-alone-app.xml/descriptor
/descriptors
/configuration
/plugin
/plugins
/pluginManagement
/build
/project
The assembly configuration descriptor is this:
assembly
idstand-alone-app/id
formats
formatzip/format
/formats
fileSets
fileSet
directorytarget/directory
outputDirectory./outputDirectory
includes
include*.jar/include
/includes
/fileSet
/fileSets
dependencySets
dependencySet
outputDirectory/lib/outputDirectory
unpackfalse/unpack
scoperuntime/scope
Re: archetype pom.xml not same as archetype-resources/pom.xml
I'm not sure on this, but I've seen that Maven 'rewrites' the POM (e.g. when
asking him for the effective-pom) and doesn't
like the XML Namespace-stuff... As for the dependencies, it might be that Maven
just ignores empty xml-blocks...
Try putting a real dependency in there, just for testing sake...
Roland
On Friday 02 June 2006 17:42, Wayne Fay wrote:
Since you claim nothing has changed on your side, I would generally
suspect that some new archetype plugin was released in the last few
days/weeks that has changed something that you weren't aware of.
Go check your local repo for artifacts with dates newer than the last
time this executed properly. Delete them, and run mvn -o ... to see if
it works with the old code, and if so, go file a JIRA regression bug
on the plugin.
Wayne
On 6/2/06, ertnutler [EMAIL PROTECTED] wrote:
for some reason when i create a new project from an existing archetype,
the pom.xml copied to the root of the new project has its project
element stripped of the xml namespace information and the empty
dependencies element is removed, as is the packaging element. this
worked a couple of days ago, so i can't tell if this is something that
i've done or something that's changed underneath me? any ideas?
this is my pom.xml from archetype-resources:
?xml version=1.0 encoding=UTF-8?
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;
parent
groupIdcom.mycompany.lacrs/groupId
artifactIdlacrs-parent/artifactId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
name${artifactId}/name
artifactId${artifactId}/artifactId
packagingjar/packaging
dependencies
/dependencies
/project
when i create the archetype, this is the pom that's copied to the root of
the project:
?xml version=1.0 encoding=UTF-8?
project
parent
artifactIdlacrs-parent/artifactId
groupIdcom.mycompany.lacrs/groupId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
artifactIdtestjava/artifactId
nametestjava/name
/project
--
View this message in context:
http://www.nabble.com/archetype-pom.xml-not-same-as-archetype-resources-p
om.xml-t1723419.html#a4681828 Sent from the Maven - Users forum at
Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: REPOST: [M2] external config of artifact and dependencies
It is more work than writing a properties file. Also, I am lazy. Which is probably why I want to use maven on my projects. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 11:51 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies Out of curiosity, why is programmatically configuring log4j (say in a servlet context listener) not a great idea? Kris [EMAIL PROTECTED] wrote: I don't think my team will react nicely if I tell them that in order to have all the maven niceties we have to buy and run oracle app server or have half a dozen instances of tomcat running on our servers. Is this what people commonly do with maven built wars? What I am trying to figure out is rote for a lot of people out there. I just can't get my pea-sized brain to come up with a palatable solution. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:49 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have to alter the exploded web application directory after it is installed and add the log4j.properties file. That seems like a great deal of work and a kludge . . . what am I missing here? -Original Message- From: Fernandez, Carlos Sent: Thursday, June 01, 2006 10:49 AM To: users@maven.apache.org Subject: RE: [M2] questions about migrating to maven Carlos, EXTERNAL CONFIGURATION OF AN ARTIFACT AND DEPENDENCIES Sorry for belaboring this point - but I tend to think better in concrete terms. Let me walk through a scenario just to make sure I understand this. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop
Re: archetype pom.xml not same as archetype-resources/pom.xml
I agree with you on the rewriting POMs bit Roland, except that he said
this worked a couple of days ago, so i can't tell if this is
something that i've done or something that's changed underneath me.
So if it worked a few days ago, and he's done nothing, then I'd
suspect there might have been some Maven changes...?
Wayne
On 6/2/06, Roland Asmann [EMAIL PROTECTED] wrote:
I'm not sure on this, but I've seen that Maven 'rewrites' the POM (e.g. when
asking him for the effective-pom) and doesn't
like the XML Namespace-stuff... As for the dependencies, it might be that Maven
just ignores empty xml-blocks...
Try putting a real dependency in there, just for testing sake...
Roland
On Friday 02 June 2006 17:42, Wayne Fay wrote:
Since you claim nothing has changed on your side, I would generally
suspect that some new archetype plugin was released in the last few
days/weeks that has changed something that you weren't aware of.
Go check your local repo for artifacts with dates newer than the last
time this executed properly. Delete them, and run mvn -o ... to see if
it works with the old code, and if so, go file a JIRA regression bug
on the plugin.
Wayne
On 6/2/06, ertnutler [EMAIL PROTECTED] wrote:
for some reason when i create a new project from an existing archetype,
the pom.xml copied to the root of the new project has its project
element stripped of the xml namespace information and the empty
dependencies element is removed, as is the packaging element. this
worked a couple of days ago, so i can't tell if this is something that
i've done or something that's changed underneath me? any ideas?
this is my pom.xml from archetype-resources:
?xml version=1.0 encoding=UTF-8?
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;
parent
groupIdcom.mycompany.lacrs/groupId
artifactIdlacrs-parent/artifactId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
name${artifactId}/name
artifactId${artifactId}/artifactId
packagingjar/packaging
dependencies
/dependencies
/project
when i create the archetype, this is the pom that's copied to the root of
the project:
?xml version=1.0 encoding=UTF-8?
project
parent
artifactIdlacrs-parent/artifactId
groupIdcom.mycompany.lacrs/groupId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
artifactIdtestjava/artifactId
nametestjava/name
/project
--
View this message in context:
http://www.nabble.com/archetype-pom.xml-not-same-as-archetype-resources-p
om.xml-t1723419.html#a4681828 Sent from the Maven - Users forum at
Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
M2 Validate/verify that all dependencies are in the internal remote repositories
One problem I 've encountered a few times now is that everything builds locally but team mates can't build because my local repository differs from theirs. For example, I am working on 2 different projects, each with it's own internal remote repo. The internal repo A contains the ejb3 jar, but the other one (B) doesn't. When I created an indirect dependency on the ejb3 jar in the B project, it works locally. My team mates (of spring-richclient) which only work on B get problems. Is there a command to validate or verify that every dependency my project needs is available in one of the repositories defined on the project and fail if they aren't available there? mvn validate verify didn't work. -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: archetype pom.xml not same as archetype-resources/pom.xml
I must be sleeping on the job, I completely missed that sentence! :-S
Roland
On Friday 02 June 2006 17:59, Wayne Fay wrote:
I agree with you on the rewriting POMs bit Roland, except that he said
this worked a couple of days ago, so i can't tell if this is
something that i've done or something that's changed underneath me.
So if it worked a few days ago, and he's done nothing, then I'd
suspect there might have been some Maven changes...?
Wayne
On 6/2/06, Roland Asmann [EMAIL PROTECTED] wrote:
I'm not sure on this, but I've seen that Maven 'rewrites' the POM (e.g.
when asking him for the effective-pom) and doesn't like the XML
Namespace-stuff... As for the dependencies, it might be that Maven just
ignores empty xml-blocks... Try putting a real dependency in there, just
for testing sake...
Roland
On Friday 02 June 2006 17:42, Wayne Fay wrote:
Since you claim nothing has changed on your side, I would generally
suspect that some new archetype plugin was released in the last few
days/weeks that has changed something that you weren't aware of.
Go check your local repo for artifacts with dates newer than the last
time this executed properly. Delete them, and run mvn -o ... to see if
it works with the old code, and if so, go file a JIRA regression bug
on the plugin.
Wayne
On 6/2/06, ertnutler [EMAIL PROTECTED] wrote:
for some reason when i create a new project from an existing
archetype, the pom.xml copied to the root of the new project has its
project element stripped of the xml namespace information and the
empty dependencies element is removed, as is the packaging
element. this worked a couple of days ago, so i can't tell if this
is something that i've done or something that's changed underneath
me? any ideas?
this is my pom.xml from archetype-resources:
?xml version=1.0 encoding=UTF-8?
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;
parent
groupIdcom.mycompany.lacrs/groupId
artifactIdlacrs-parent/artifactId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
name${artifactId}/name
artifactId${artifactId}/artifactId
packagingjar/packaging
dependencies
/dependencies
/project
when i create the archetype, this is the pom that's copied to the
root of the project:
?xml version=1.0 encoding=UTF-8?
project
parent
artifactIdlacrs-parent/artifactId
groupIdcom.mycompany.lacrs/groupId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
artifactIdtestjava/artifactId
nametestjava/name
/project
--
View this message in context:
http://www.nabble.com/archetype-pom.xml-not-same-as-archetype-resourc
es-p om.xml-t1723419.html#a4681828 Sent from the Maven - Users forum
at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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 change log level of maven?
How to change log level of maven? I mean the output on the console when you launch mvn goal. By default I guess that 'INFO' level is applied. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
specifying plugin parameters in POM
Is it possible to alter some plugin parameters in POM? For example, if project consists of several modules, I would like to provide some module-specific parameters (for instance - for dependency plugin I need to provide different target directory to place dependencies into, and for packaging plugin i need to provide custom placement of resulting JAR file, instead of target/ directory). -- Eugene N Dzhurinsky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REPOST: [M2] external config of artifact and dependencies
I'm not talking about manually setting up the appenders, etc - I'm just talking about configuring log4j from a properties file that can vary by the deployment environment (i.e, be called something other than log4j.properties.) I have a somewhat similar issue to what you have, except that I use the log4j xml dialect for configuration and consequently have to run DOMConfigurator.configure(...) on application startup. It seems to me that you could do something similar - you still get to configure by a properties instance, but this instance is then selectable at runtime (and potentially pulled from JNDI.) Kris [EMAIL PROTECTED] wrote: It is more work than writing a properties file. Also, I am lazy. Which is probably why I want to use maven on my projects. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 11:51 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies Out of curiosity, why is programmatically configuring log4j (say in a servlet context listener) not a great idea? Kris [EMAIL PROTECTED] wrote: I don't think my team will react nicely if I tell them that in order to have all the maven niceties we have to buy and run oracle app server or have half a dozen instances of tomcat running on our servers. Is this what people commonly do with maven built wars? What I am trying to figure out is rote for a lot of people out there. I just can't get my pea-sized brain to come up with a palatable solution. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:49 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other web applications, if they don't have their own version of the resource locally. Moreover, it can only be done for a single application - I can't have two different log4j.properties files in the shared/classes dir. So now I have to alter the exploded web application directory after it is installed and add the log4j.properties file. That seems like a great deal of work and a kludge . . . what am I missing here? -Original Message- From: Fernandez, Carlos Sent: Thursday, June 01, 2006 10:49 AM To: users@maven.apache.org Subject: RE: [M2] questions about migrating to maven Carlos, EXTERNAL CONFIGURATION OF AN ARTIFACT AND DEPENDENCIES Sorry for belaboring this
Re: MANIFEST.MF generation outside of jar:jar plugin
Hi.
What I'm looking for is a way to generate or manipulate the MANIFEST.MF
such that it contains values from the POM, like version, etc. I can do
this via the 'archive' element in the 'configuration' of the jar plugin,
but this doesn't leave an artifact for use outside of the JAR, such as
being used within the Eclipse IDE's PDE.
You could try using Maven's resource filtering. Place a skeleton
manifest in your resource directory. Place in that any variables you
want to reference: ${project.version} I believe is one. Then enable
filtering on your resource directory, with the proper character encoding
to be used. My thought is that Maven might filter your manifest and
deposit it into the target/classes directory.
You might also be able to do this filtering and then make some assembly
that grabs resources which you filter so that only the manifest is
included; and Maven filters and deposits the manifest in some assembly
output directory.
Not the best answers, but maybe you'll find something out.
Good luck.
Steev Coco.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: specifying plugin parameters in POM
On Fri, Jun 02, 2006 at 07:31:00PM +0300, Eugeny N Dzhurinsky wrote: Is it possible to alter some plugin parameters in POM? For example, if project consists of several modules, I would like to provide some module-specific parameters (for instance - for dependency plugin I need to provide different target directory to place dependencies into, and for packaging plugin i need to provide custom placement of resulting JAR file, instead of target/ directory). I found how to work with dependencies at http://mojo.codehaus.org/dependency-maven-plugin/howto.html But still wandering how I can specify different directory for placing JAR file produced with package goal? -- Eugene N Dzhurinsky - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] How to change log level of maven?
On Fri, 2 Jun 2006, Szczepan Faber wrote: How to change log level of maven? I mean the output on the console when you launch mvn goal. By default I guess that 'INFO' level is applied. Yes, the default is INFO. You can enable DEBUG by specifying the '-X' option. Currently these are the only loglevels that are accessible through the commandline. -- kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: archetype pom.xml not same as archetype-resources/pom.xml
wayne, thanks for your response. now that i think about it, i changed the maven-archetype pom in my local repo as you suggested in the thread below because i was having the problem described there: http://www.nabble.com/Archetype-installation-and-creation-of-the-app-problem-t1593239.html#a4340854 i believe my current problem is a result of that change, but i've thrashed around a bit in the meantime so i can't be sure. some of that thrashing involved deleting my local repo and resynching (which i now realize probably wasn't the best idea), so i can't do what you suggest. any other suggestions? -- View this message in context: http://www.nabble.com/archetype-pom.xml-not-same-as-archetype-resources-pom.xml-t1723419.html#a4683337 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why do my builds fail to honor the repositories settings?
I thought I was progressing in my knowledge of how to configure maven2 so that multiple developers can build with maven. However today, I no longer can download anything from repositories configured in my project pom.xml file. Here is a typical setting in a module's pom: repositories repository idinternal/id nameInternal Release Repository/name urlftp://XRBUILD2.xrite.com/internal/url /repository repository idcodehaus/id nameCodehaus maven repository/name urlhttp://dist.codehaus.org//url layoutlegacy/layout /repository /repositories My understanding was that I could add any number of repositories like this to look for specified dependencies. This module also has a parent pom which adds other repositories; I assume these are additive...I could specify them in either place, is that correct? Today I cannot even download from our local ftp://XRBUILD2.xrite.com ftp://xrbuild2.xrite.com/ server, yes I use the wagon-ftp extension to allow ftp downloads. My maven conf.xml file specifies all the local servers such as: server idinternal/id usernameanonymous/username passwordxrbuild/password /server What am I doing wrong? It seems like a network problem but I can go to all the repos with my browser and download just fine. How can I troubleshoot where the problem is? P.S. One thing I don't like about this (when it does work) is that it tries to download each artifact from all the repositories until it finds one that works. Often times, I know which repo should be use for each artifiact...but this isn't a big deal. -dh
Inheriting POM
Now, I have 20 or so POM's that are all taking a top level POM as the parent shown below: parent groupIdcom.mycompay.apps/groupId artifactIdBaseApp/artifactId version9.5-SNAPSHOT/version relativePath../BaseApp/relativePath /parent Now the question is - if we later on change the version of the BaseApp, we will have to modify the parent section in each of my 20 POM's with the new version number. Is there a way so that I can modify the version number in only one place? Again, we can do this in maven1 using currentVersion defined in parent POM. But Maven2 removed this element. Please advise. Thanks. -- View this message in context: http://www.nabble.com/Inheriting-POM-t1724007.html#a4683779 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Stand-alone app
Hi Tim,
Ohhh! I think I see what's happening. I was expecting the final result
zip file to appear under the ./target directory instead of right in the
root directory. After running assembly:assembly there is a zip file
under the ./target directory with a somewhat longer name
pairfinder-0.9-stand-alone-app.zip, and this zip file is quite large
because it has the redundant copies of the jar files. I thought this
was the final artifact of the assembly:assembly goal. I didn't notice
the pairfinder-0.9.zip file sitting right in the root, and this file is
the correct file to distribute the app. It's exactly what I wanted.
Well, thank you so much!
Even though this jar:jar/assembly:assembly combination does work, I'm
still looking into writing an explicit goal for accomplishing this task.
The fact that lots of people are probably going to want to do this, but
yet it took me (a beginning user, in case you couldn't tell) several
days of fumbling to get it right is an indication that there may be a
need for it. I agree that It's not difficult to use the jar and
assembly to create a stand-alone build once you understand how to do it.
But I think it could be even easier with a goal. Even if nobody else
has any need for it, at least I'm learning a lot about how Maven works
by doing it. And maybe other people would like it, too. Especially
Maven beginners like me :-)
Do you think I should look into writing it as a goal/mojo under the
assembly plugin, in the hopes that maybe I could submit it to the Maven
Project, or should I write it into my own plugin that I write from
scratch?
Thanks so much!
--Erik
-Original Message-
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 11:52 AM
To: Maven Users List
Subject: Re: Stand-alone app
Just to be sure I understand you correctly: Your problem is that the
dependendcies of your
project are included in in the created jar artifact
('pairfinder-0.9.jar')?
I ask this because I can't reproduce your problem with the
pom/descriptor you posted. I
just replaced your internal dependency with a dependency to
commons-beanutils. When I now
run 'mvn assembly:assembly' the artifact is created with the right
classpath entries in
the manifest and the zip file has the dependencies in the lib directory
???
Have you tried to run a 'mvn clean' before creating the assembly?
-Tim
Midtskogen, Erik schrieb:
Hi Tim,
Hi Tim. Yes, I'm using the assembly plugin to copy the dependencies
into a subdirectory called ./lib, and I'm using the jar plugin to
build the executable jar, and actually everything works basically OK.
My only problem is that the jar plugin is adding the dependency jar
files into the executable artifact jar. These are unnecessary and
only increase the size of executable jar file. There is no way I've
found to put a jarred jar library onto the classpath without writing
extra code in your executable to support this. The jar libraries need
to reside outside the executable jar in the normal filesystem to be
easily accessible.
For now, I'm just removing the unneeded dependency jars from the
executable jar manually, but I'm curious how one might go about
configuring jar:jar so that it properly configures the manifest.mf
without also rolling the dependency jars into its artifact.
Here is my POM:
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
groupIdcom.galaxyusa.pairfinder/groupId
artifactIdpairfinder/artifactId
packagingjar/packaging
version0.9/version
nameMaven Quick Start Archetype/name
urlhttp://maven.apache.org/url
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
dependency
groupIdorg.skroople/groupId
artifactIdskroople/artifactId
version0.7/version
/dependency
/dependencies
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.0/version
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
Re: Stand-alone app
Writing a plugin from scratch that basically duplicates existing
effort/code is probably a waste of time.
Adding it under the assembly plugin sounds reasonable. But given that
you got it working with a few configurations in your pom, I'm not even
sure that's necessary. Instead I'd prefer that you just write a little
documentation and provide a sample pom.xml that people can refer to
for building their own stand-alone app.
Wayne
On 6/2/06, Midtskogen, Erik [EMAIL PROTECTED] wrote:
Hi Tim,
Ohhh! I think I see what's happening. I was expecting the final result
zip file to appear under the ./target directory instead of right in the
root directory. After running assembly:assembly there is a zip file
under the ./target directory with a somewhat longer name
pairfinder-0.9-stand-alone-app.zip, and this zip file is quite large
because it has the redundant copies of the jar files. I thought this
was the final artifact of the assembly:assembly goal. I didn't notice
the pairfinder-0.9.zip file sitting right in the root, and this file is
the correct file to distribute the app. It's exactly what I wanted.
Well, thank you so much!
Even though this jar:jar/assembly:assembly combination does work, I'm
still looking into writing an explicit goal for accomplishing this task.
The fact that lots of people are probably going to want to do this, but
yet it took me (a beginning user, in case you couldn't tell) several
days of fumbling to get it right is an indication that there may be a
need for it. I agree that It's not difficult to use the jar and
assembly to create a stand-alone build once you understand how to do it.
But I think it could be even easier with a goal. Even if nobody else
has any need for it, at least I'm learning a lot about how Maven works
by doing it. And maybe other people would like it, too. Especially
Maven beginners like me :-)
Do you think I should look into writing it as a goal/mojo under the
assembly plugin, in the hopes that maybe I could submit it to the Maven
Project, or should I write it into my own plugin that I write from
scratch?
Thanks so much!
--Erik
-Original Message-
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 11:52 AM
To: Maven Users List
Subject: Re: Stand-alone app
Just to be sure I understand you correctly: Your problem is that the
dependendcies of your
project are included in in the created jar artifact
('pairfinder-0.9.jar')?
I ask this because I can't reproduce your problem with the
pom/descriptor you posted. I
just replaced your internal dependency with a dependency to
commons-beanutils. When I now
run 'mvn assembly:assembly' the artifact is created with the right
classpath entries in
the manifest and the zip file has the dependencies in the lib directory
???
Have you tried to run a 'mvn clean' before creating the assembly?
-Tim
Midtskogen, Erik schrieb:
Hi Tim,
Hi Tim. Yes, I'm using the assembly plugin to copy the dependencies
into a subdirectory called ./lib, and I'm using the jar plugin to
build the executable jar, and actually everything works basically OK.
My only problem is that the jar plugin is adding the dependency jar
files into the executable artifact jar. These are unnecessary and
only increase the size of executable jar file. There is no way I've
found to put a jarred jar library onto the classpath without writing
extra code in your executable to support this. The jar libraries need
to reside outside the executable jar in the normal filesystem to be
easily accessible.
For now, I'm just removing the unneeded dependency jars from the
executable jar manually, but I'm curious how one might go about
configuring jar:jar so that it properly configures the manifest.mf
without also rolling the dependency jars into its artifact.
Here is my POM:
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
groupIdcom.galaxyusa.pairfinder/groupId
artifactIdpairfinder/artifactId
packagingjar/packaging
version0.9/version
nameMaven Quick Start Archetype/name
urlhttp://maven.apache.org/url
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
dependency
groupIdorg.skroople/groupId
artifactIdskroople/artifactId
version0.7/version
/dependency
/dependencies
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
RE: Why do my builds fail to honor the repositories settings?
Correction...local ftp problem is fixed; I only have trouble with the remote repositories. -dh -Original Message- From: Dave Hoffer [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 1:08 PM To: users@maven.apache.org Subject: Why do my builds fail to honor the repositories settings? I thought I was progressing in my knowledge of how to configure maven2 so that multiple developers can build with maven. However today, I no longer can download anything from repositories configured in my project pom.xml file. Here is a typical setting in a module's pom: repositories repository idinternal/id nameInternal Release Repository/name urlftp://XRBUILD2.xrite.com/internal/url /repository repository idcodehaus/id nameCodehaus maven repository/name urlhttp://dist.codehaus.org//url layoutlegacy/layout /repository /repositories My understanding was that I could add any number of repositories like this to look for specified dependencies. This module also has a parent pom which adds other repositories; I assume these are additive...I could specify them in either place, is that correct? Today I cannot even download from our local ftp://XRBUILD2.xrite.com ftp://xrbuild2.xrite.com/ server, yes I use the wagon-ftp extension to allow ftp downloads. My maven conf.xml file specifies all the local servers such as: server idinternal/id usernameanonymous/username passwordxrbuild/password /server What am I doing wrong? It seems like a network problem but I can go to all the repos with my browser and download just fine. How can I troubleshoot where the problem is? P.S. One thing I don't like about this (when it does work) is that it tries to download each artifact from all the repositories until it finds one that works. Often times, I know which repo should be use for each artifiact...but this isn't a big deal. -dh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MANIFEST.MF generation outside of jar:jar plugin
war:manifest will generate a standalone MANIFEST.MF in
warSourceDirectory/META-INF. Despite the war association it does not
require a war project; you can use it anywhere (for ejb/mdb projects for
instance). Example:
plugin
artifactIdmaven-war-plugin/artifactId
configuration
warSourceDirectoryWebContent/warSourceDirectory
archive
manifest
addClasspathtrue/addClasspath
classpathPrefixlib//classpathPrefix
/manifest
/archive
/configuration
executions
execution
phasepackage/phase
goals
goalmanifest/goal
/goals
inheritedtrue/inherited
/execution
/executions
/plugin
This will generate the manifest in WebContent/META-INF every time the
package phase is executed as part of the build. The goal probably
should move to the jar plugin.
-Original Message-
From: Steven Coco [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 11:43 AM
To: users@maven.apache.org
Subject: Re: MANIFEST.MF generation outside of jar:jar plugin
Hi.
What I'm looking for is a way to generate or manipulate the
MANIFEST.MF such that it contains values from the POM, like version,
etc. I can do this via the 'archive' element in the 'configuration' of
the jar plugin, but this doesn't leave an artifact for use outside of
the JAR, such as being used within the Eclipse IDE's PDE.
You could try using Maven's resource filtering. Place a skeleton
manifest in your resource directory. Place in that any variables you
want to reference: ${project.version} I believe is one. Then enable
filtering on your resource directory, with the proper character encoding
to be used. My thought is that Maven might filter your manifest and
deposit it into the target/classes directory.
You might also be able to do this filtering and then make some assembly
that grabs resources which you filter so that only the manifest is
included; and Maven filters and deposits the manifest in some assembly
output directory.
Not the best answers, but maybe you'll find something out.
Good luck.
Steev Coco.
-
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: REPOST: [M2] external config of artifact and dependencies
Although I could do this for log4j - what about other 3rd party frameworks that use classpath resources for configuration. Log4j was just kind of a stand-in for a more general condition. Do you end up having to spool up and configure all of those resources programmatically in order to externalize configuration? - I have a somewhat similar issue to what you have. Can you elaborate? This might help my small brain think outside of the ant shaped box it is current encased in. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 12:35 PM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies I'm not talking about manually setting up the appenders, etc - I'm just talking about configuring log4j from a properties file that can vary by the deployment environment (i.e, be called something other than log4j.properties.) I have a somewhat similar issue to what you have, except that I use the log4j xml dialect for configuration and consequently have to run DOMConfigurator.configure(...) on application startup. It seems to me that you could do something similar - you still get to configure by a properties instance, but this instance is then selectable at runtime (and potentially pulled from JNDI.) Kris [EMAIL PROTECTED] wrote: It is more work than writing a properties file. Also, I am lazy. Which is probably why I want to use maven on my projects. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 11:51 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies Out of curiosity, why is programmatically configuring log4j (say in a servlet context listener) not a great idea? Kris [EMAIL PROTECTED] wrote: I don't think my team will react nicely if I tell them that in order to have all the maven niceties we have to buy and run oracle app server or have half a dozen instances of tomcat running on our servers. Is this what people commonly do with maven built wars? What I am trying to figure out is rote for a lot of people out there. I just can't get my pea-sized brain to come up with a palatable solution. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:49 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to drop the log4 files in TomcatRoot/shared/classes, that is the nuclear bomb of config. Doing so may impact other
Re: maven-was-plugin
Also in windows each folder and file has short name that has no spaces in it and is 8 or less characters. You can see the short name by going to a DOS box and using dir /X which adds a column about midscreen showing the short form. Then specify the short names to define that path. It would be something like: c:\PROGRA~1\IBM\RATIONAL\SDP and so forth. -- Lee On 6/2/06, Wayne Fay [EMAIL PROTECTED] wrote: Spaces in directories on Windows are a known issue in Java when dealing with RMI. And while I don't use it myself, its a good guess that this plugin uses RMI to talk to the WAS for deploying your EAR. You will need to reinstall to a directory with no spaces. Alternatively, you could perhaps use the subst command to create a fake k:\ drive (or similar) for your c:\program files\ibm directory. Then your path would be k:\rational\... which has no spaces. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I d like to make ear deployment automatically on websphere 5.1. After some search, David Karlsen's plugin [maven-was-plugin] seems to fit exactly my need. But there are some issues that I can not resolve. To sum up, there are some points I made previously: - WAS_HOME is set to installation directory of used server ([C:\Program Files\IBM\Rational\SDP\6.0\runtimes\base_v51] in my case) - JAVA_HOME is set to WAS'jre because the deployment script need it. (JAVA_HOME=%WAS_HOME%\java) - %WAS_HOME%/bin and %WAS_HOME%\deploytool\itp are adding in the PATH PATH=%WAS_HOME%/bin;%WAS_HOME%\deploytool\itp;%PATH% - WAS_EXT_DIRS=%WAS_HOME%\java\lib;%WAS_HOME%\lib\classes;%WAS_HOME%\lib\lib;% WAS_HOME%\lib\lib\ext;%WAS_HOME%\lib\web\help - in the project pom file, I also declared the plugin repository of maven-was-plugin. NB: to be sure, I replaced all used env variables by its real value. Finally mvn returns following error: [ERROR] The java class is not found: Files\IBM\Rational\SDP\6/0\runtimes\base_v51\java\lib;C:\Program It seems that space character in the path is not allowed... But I do not want to reinstall all. Does anyone have created unit test of this plugin ? or find a solution ? Thanks for your help, Andre This message is intended for the addressee or its representative only. Any form of unauthorized use, publication, reproduction, copying or disclosure of the content of this e-mail is not permitted. If you are not the intended recipient of this e-mail message and its contents, please notify the sender immediately and delete this message and all its attachments subsequently. - 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] -- -- Lee Meador Sent from gmail. My real email address is [EMAIL PROTECTED]
Re: Maven2 book version 1.1?
It will be done, sure. I think around end of June. On 6/2/06, Sebastien Arbogast [EMAIL PROTECTED] wrote: When I started reading the new Maven2 book, I noticed quite a few mistakes here and there and I tried to mark them in the PDF in order to report them later... until I noticed that the Errata section on Mergere's site was already quite complete. My question is, do you plan to release an updated version of the book with errata corrected? Because reading the book on a screen is already not very comfortable, but reading it in parallel with the errata page can be a real pain. -- Sébastien Arbogast The Epseelon Project : http://www.epseelon.net Blog : http://sebastien-arbogast.epseelon.net TagSpot : http://www.tagspot.org - 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: Stand-alone app
Midtskogen, Erik schrieb:
Hi Tim,
Ohhh! I think I see what's happening. I was expecting the final result
zip file to appear under the ./target directory instead of right in the
root directory. After running assembly:assembly there is a zip file
under the ./target directory with a somewhat longer name
pairfinder-0.9-stand-alone-app.zip, and this zip file is quite large
because it has the redundant copies of the jar files. I thought this
was the final artifact of the assembly:assembly goal. I didn't notice
the pairfinder-0.9.zip file sitting right in the root, and this file is
the correct file to distribute the app. It's exactly what I wanted.
This isn't the result I am getting.
There are two files generated in the target directory: pairfinder-0.9.jar and
pairfinder-0.9-stand-alone-app.zip. There is no third file generated in the root directory
of the project.
The jar just contains the compiled classes and the manifest with the Class-Path entry. And
the zip contains the build artifact and its dependencies... Exactly as wanted.
I have attached the test project I created. Can you try to run 'mvn assembly:assambly' on
that and see what it produces for you.
Well, thank you so much!
Even though this jar:jar/assembly:assembly combination does work, I'm
still looking into writing an explicit goal for accomplishing this task.
The fact that lots of people are probably going to want to do this, but
yet it took me (a beginning user, in case you couldn't tell) several
days of fumbling to get it right is an indication that there may be a
need for it. I agree that It's not difficult to use the jar and
assembly to create a stand-alone build once you understand how to do it.
But I think it could be even easier with a goal. Even if nobody else
has any need for it, at least I'm learning a lot about how Maven works
by doing it. And maybe other people would like it, too. Especially
Maven beginners like me :-)
Do you think I should look into writing it as a goal/mojo under the
assembly plugin, in the hopes that maybe I could submit it to the Maven
Project, or should I write it into my own plugin that I write from
scratch?
As Wayne said, writing a small guide to help other new users seems more
appropriate.
Thanks so much!
--Erik
-Original Message-
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 11:52 AM
To: Maven Users List
Subject: Re: Stand-alone app
Just to be sure I understand you correctly: Your problem is that the
dependendcies of your
project are included in in the created jar artifact
('pairfinder-0.9.jar')?
I ask this because I can't reproduce your problem with the
pom/descriptor you posted. I
just replaced your internal dependency with a dependency to
commons-beanutils. When I now
run 'mvn assembly:assembly' the artifact is created with the right
classpath entries in
the manifest and the zip file has the dependencies in the lib directory
???
Have you tried to run a 'mvn clean' before creating the assembly?
-Tim
Midtskogen, Erik schrieb:
Hi Tim,
Hi Tim. Yes, I'm using the assembly plugin to copy the dependencies
into a subdirectory called ./lib, and I'm using the jar plugin to
build the executable jar, and actually everything works basically OK.
My only problem is that the jar plugin is adding the dependency jar
files into the executable artifact jar. These are unnecessary and
only increase the size of executable jar file. There is no way I've
found to put a jarred jar library onto the classpath without writing
extra code in your executable to support this. The jar libraries need
to reside outside the executable jar in the normal filesystem to be
easily accessible.
For now, I'm just removing the unneeded dependency jars from the
executable jar manually, but I'm curious how one might go about
configuring jar:jar so that it properly configures the manifest.mf
without also rolling the dependency jars into its artifact.
Here is my POM:
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
groupIdcom.galaxyusa.pairfinder/groupId
artifactIdpairfinder/artifactId
packagingjar/packaging
version0.9/version
nameMaven Quick Start Archetype/name
urlhttp://maven.apache.org/url
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
dependency
groupIdorg.skroople/groupId
artifactIdskroople/artifactId
version0.7/version
/dependency
/dependencies
build
Re: REPOST: [M2] external config of artifact and dependencies
How do you handle this in ant? Assuming of course that you're coming from ant, and that you've previously solved this problem. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Although I could do this for log4j - what about other 3rd party frameworks that use classpath resources for configuration. Log4j was just kind of a stand-in for a more general condition. Do you end up having to spool up and configure all of those resources programmatically in order to externalize configuration? - I have a somewhat similar issue to what you have. Can you elaborate? This might help my small brain think outside of the ant shaped box it is current encased in. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 12:35 PM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies I'm not talking about manually setting up the appenders, etc - I'm just talking about configuring log4j from a properties file that can vary by the deployment environment (i.e, be called something other than log4j.properties.) I have a somewhat similar issue to what you have, except that I use the log4j xml dialect for configuration and consequently have to run DOMConfigurator.configure(...) on application startup. It seems to me that you could do something similar - you still get to configure by a properties instance, but this instance is then selectable at runtime (and potentially pulled from JNDI.) Kris [EMAIL PROTECTED] wrote: It is more work than writing a properties file. Also, I am lazy. Which is probably why I want to use maven on my projects. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 11:51 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies Out of curiosity, why is programmatically configuring log4j (say in a servlet context listener) not a great idea? Kris [EMAIL PROTECTED] wrote: I don't think my team will react nicely if I tell them that in order to have all the maven niceties we have to buy and run oracle app server or have half a dozen instances of tomcat running on our servers. Is this what people commonly do with maven built wars? What I am trying to figure out is rote for a lot of people out there. I just can't get my pea-sized brain to come up with a palatable solution. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:49 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are currently working on, the testing environment is set to DEBUG while production is set to WARN. I don't want to filter the log4j configuration file when I package the artifact. Doing so would place environment specific settings in the archive, compromising its value. I can't use JNDI to configure log4j. So that seems to leave adding it to the classpath as the only viable option. Our app servers are tomcat 5.x. Although I have the option to
Re: site:deploy -p switch
Man, I told you in http://jira.codehaus.org/browse/MSITE-145 SFTP is NOT FTP You configured Maven to use SFTP You are connecting by hand to FTP http://en.wikipedia.org/wiki/SSH_file_transfer_protocol http://en.wikipedia.org/wiki/File-Transfer_Protocol On 6/1/06, Borut Bolčina [EMAIL PROTECTED] wrote: On Windows XP, with maven 2.0.4 and site plugin 2.0-beta-5 when doing site:deploy with distributionManagement site idwebsite/id namemy project site/name urlsftp://my.server/project/url /site /distributionManagement a command mkdir -p /project/ is issued which I think is not correct When executing from cmd window C:\Documents and Settings\Borut\Desktop\Workspace\MyProjectftp my.server Connected to my.server. 220 (vsFTPd 2.0.3) User (my.server:(none)): myusername 331 Please specify the password. Password: 230 Login successful. ftp mkdir -p /project/ 257 /-p created ftp Instead of creating /project directory, the ftp client creates a directory with name -p. I think that is the reason the site:deploy fails. See bellow. C:\Documents and Settings\Borut\Desktop\Workspace\MyProjectmvn site:deploy [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'site'. [INFO] [INFO] Building MyProject [INFO]task-segment: [site:deploy] [INFO] [INFO] [site:deploy] The authenticity of host 'my.server' can't be established. RSA key fingerprint is 4a:86:2b:a7:15:29:ee:4b:10:8f:8e:73:53:b0:9e:cd. Are you sure you want to continue connecting? (yes/no): yes sftp://my.server/project - Session: Opened Executing command: mkdir -p /project/. sftp://my.server/project - Session: Disconnecting sftp://my.server/project - Session: Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Error performing commands for file transfer Exit code: 1 - mkdir: cannot create directory `/project': Permission denied [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Thu Jun 01 23:06:05 CEST 2006 [INFO] Final Memory: 7M/13M [INFO] The same happens when trying to deploy with scp. Regards, Borut - 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
Re: REPOST: [M2] external config of artifact and dependencies
My suggestion is, include ALL the properties files and in your code look for a system property to choose one. If it's not present you can default to dev environment or fail, whatever you want. Then you just have to run your server with that property -Denv=prod That's it On 6/2/06, Wayne Fay [EMAIL PROTECTED] wrote: How do you handle this in ant? Assuming of course that you're coming from ant, and that you've previously solved this problem. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Although I could do this for log4j - what about other 3rd party frameworks that use classpath resources for configuration. Log4j was just kind of a stand-in for a more general condition. Do you end up having to spool up and configure all of those resources programmatically in order to externalize configuration? - I have a somewhat similar issue to what you have. Can you elaborate? This might help my small brain think outside of the ant shaped box it is current encased in. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 12:35 PM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies I'm not talking about manually setting up the appenders, etc - I'm just talking about configuring log4j from a properties file that can vary by the deployment environment (i.e, be called something other than log4j.properties.) I have a somewhat similar issue to what you have, except that I use the log4j xml dialect for configuration and consequently have to run DOMConfigurator.configure(...) on application startup. It seems to me that you could do something similar - you still get to configure by a properties instance, but this instance is then selectable at runtime (and potentially pulled from JNDI.) Kris [EMAIL PROTECTED] wrote: It is more work than writing a properties file. Also, I am lazy. Which is probably why I want to use maven on my projects. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 11:51 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies Out of curiosity, why is programmatically configuring log4j (say in a servlet context listener) not a great idea? Kris [EMAIL PROTECTED] wrote: I don't think my team will react nicely if I tell them that in order to have all the maven niceties we have to buy and run oracle app server or have half a dozen instances of tomcat running on our servers. Is this what people commonly do with maven built wars? What I am trying to figure out is rote for a lot of people out there. I just can't get my pea-sized brain to come up with a palatable solution. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:49 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for its configuration file on the classpath at application initialization. Although you can configure log4j programmatically, that probably isn't a great idea. log4j is configured differently for each target environment. E.g. Developers will change settings based on what they are
Re: REPOST: [M2] external config of artifact and dependencies
I didn't see the log4j part. That looks more like a log4j question. IIRC there's a web.xml config option that specify the path of the configuration. Maybe I saw that in spring utilities. SLF4J facade may also help you, http://www.slf4j.org/ On 6/2/06, Carlos Sanchez [EMAIL PROTECTED] wrote: My suggestion is, include ALL the properties files and in your code look for a system property to choose one. If it's not present you can default to dev environment or fail, whatever you want. Then you just have to run your server with that property -Denv=prod That's it On 6/2/06, Wayne Fay [EMAIL PROTECTED] wrote: How do you handle this in ant? Assuming of course that you're coming from ant, and that you've previously solved this problem. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Although I could do this for log4j - what about other 3rd party frameworks that use classpath resources for configuration. Log4j was just kind of a stand-in for a more general condition. Do you end up having to spool up and configure all of those resources programmatically in order to externalize configuration? - I have a somewhat similar issue to what you have. Can you elaborate? This might help my small brain think outside of the ant shaped box it is current encased in. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 12:35 PM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies I'm not talking about manually setting up the appenders, etc - I'm just talking about configuring log4j from a properties file that can vary by the deployment environment (i.e, be called something other than log4j.properties.) I have a somewhat similar issue to what you have, except that I use the log4j xml dialect for configuration and consequently have to run DOMConfigurator.configure(...) on application startup. It seems to me that you could do something similar - you still get to configure by a properties instance, but this instance is then selectable at runtime (and potentially pulled from JNDI.) Kris [EMAIL PROTECTED] wrote: It is more work than writing a properties file. Also, I am lazy. Which is probably why I want to use maven on my projects. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 11:51 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies Out of curiosity, why is programmatically configuring log4j (say in a servlet context listener) not a great idea? Kris [EMAIL PROTECTED] wrote: I don't think my team will react nicely if I tell them that in order to have all the maven niceties we have to buy and run oracle app server or have half a dozen instances of tomcat running on our servers. Is this what people commonly do with maven built wars? What I am trying to figure out is rote for a lot of people out there. I just can't get my pea-sized brain to come up with a palatable solution. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:49 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the
Re: REPOST: [M2] external config of artifact and dependencies
This is a great suggestion. I'm going to take this approach when JNDI is not feasible. Thanks Carlos. Wayne On 6/2/06, Carlos Sanchez [EMAIL PROTECTED] wrote: My suggestion is, include ALL the properties files and in your code look for a system property to choose one. If it's not present you can default to dev environment or fail, whatever you want. Then you just have to run your server with that property -Denv=prod That's it On 6/2/06, Wayne Fay [EMAIL PROTECTED] wrote: How do you handle this in ant? Assuming of course that you're coming from ant, and that you've previously solved this problem. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Although I could do this for log4j - what about other 3rd party frameworks that use classpath resources for configuration. Log4j was just kind of a stand-in for a more general condition. Do you end up having to spool up and configure all of those resources programmatically in order to externalize configuration? - I have a somewhat similar issue to what you have. Can you elaborate? This might help my small brain think outside of the ant shaped box it is current encased in. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 12:35 PM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies I'm not talking about manually setting up the appenders, etc - I'm just talking about configuring log4j from a properties file that can vary by the deployment environment (i.e, be called something other than log4j.properties.) I have a somewhat similar issue to what you have, except that I use the log4j xml dialect for configuration and consequently have to run DOMConfigurator.configure(...) on application startup. It seems to me that you could do something similar - you still get to configure by a properties instance, but this instance is then selectable at runtime (and potentially pulled from JNDI.) Kris [EMAIL PROTECTED] wrote: It is more work than writing a properties file. Also, I am lazy. Which is probably why I want to use maven on my projects. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 11:51 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies Out of curiosity, why is programmatically configuring log4j (say in a servlet context listener) not a great idea? Kris [EMAIL PROTECTED] wrote: I don't think my team will react nicely if I tell them that in order to have all the maven niceties we have to buy and run oracle app server or have half a dozen instances of tomcat running on our servers. Is this what people commonly do with maven built wars? What I am trying to figure out is rote for a lot of people out there. I just can't get my pea-sized brain to come up with a palatable solution. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:49 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me that the crying wheel gets fed . . . or something like that. Let's say I am working on a web application. This application is a maven project configured as a war. During its lifecycle this application will be deployed on: - developer workstations - testing environment - production environment This project has a dependency on log4j. At runtime, my application code is configured to pull properties files with configuration information from a well-known JNDI location. The prop file will include environment specific settings. At deployment time, the engineer responsible for generating the war will, if necessary, also update the prop file (or individual properties) in the JNDI tree. log4j however, looks for
Re: REPOST: [M2] external config of artifact and dependencies
In one situation, I put some log4j settings in a file in the jar or war and allow putting an override properties file on the classpath. I use the settings inside the jar to configure log4j and then override the log levels from the classpath file (if it is there). [You could override whatever suits your application.] In this way, when I build for a particular environment, I set the default value of the settings in the file that is in the jar/war. There are many ways to do this with or without maven. Only when debugging and such is there a need to override and in that environment it is easy to add the override values with a properties file on the classpath. The disadvantage of this is that there is a short time during startup that third party libraries may log something before I get everything set up and overridden. I haven't found it to be a big issue for me. On 6/2/06, Carlos Sanchez [EMAIL PROTECTED] wrote: My suggestion is, include ALL the properties files and in your code look for a system property to choose one. If it's not present you can default to dev environment or fail, whatever you want. Then you just have to run your server with that property -Denv=prod That's it On 6/2/06, Wayne Fay [EMAIL PROTECTED] wrote: How do you handle this in ant? Assuming of course that you're coming from ant, and that you've previously solved this problem. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Although I could do this for log4j - what about other 3rd party frameworks that use classpath resources for configuration. Log4j was just kind of a stand-in for a more general condition. Do you end up having to spool up and configure all of those resources programmatically in order to externalize configuration? - I have a somewhat similar issue to what you have. Can you elaborate? This might help my small brain think outside of the ant shaped box it is current encased in. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 12:35 PM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies I'm not talking about manually setting up the appenders, etc - I'm just talking about configuring log4j from a properties file that can vary by the deployment environment (i.e, be called something other than log4j.properties.) I have a somewhat similar issue to what you have, except that I use the log4j xml dialect for configuration and consequently have to run DOMConfigurator.configure(...) on application startup. It seems to me that you could do something similar - you still get to configure by a properties instance, but this instance is then selectable at runtime (and potentially pulled from JNDI.) Kris [EMAIL PROTECTED] wrote: It is more work than writing a properties file. Also, I am lazy. Which is probably why I want to use maven on my projects. Carlos -Original Message- From: Kris Nuttycombe [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 11:51 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies Out of curiosity, why is programmatically configuring log4j (say in a servlet context listener) not a great idea? Kris [EMAIL PROTECTED] wrote: I don't think my team will react nicely if I tell them that in order to have all the maven niceties we have to buy and run oracle app server or have half a dozen instances of tomcat running on our servers. Is this what people commonly do with maven built wars? What I am trying to figure out is rote for a lot of people out there. I just can't get my pea-sized brain to come up with a palatable solution. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 10:49 AM To: Maven Users List Subject: Re: REPOST: [M2] external config of artifact and dependencies One suggestion would be to use an app server that allows instancing of webapps. We run Oracle App Server, and each webapp is deployed to its own OC4J instance. Each OC4J instance has its own full directory structure which allows us to copy things like log4j.properties files and other configuration files into specific webapp directories. So webapp1 has its own webapp1/shared/classes type directory and webapp2 has webapp2/shared/classes. They run in completely separated memory so there is no issue of one app accessing the other's log4 configuration file. In Tomcat, you could do this too, but you'd be to run individual Tomcat instances for each webapp. This would allow you to maintain a single build of your code with different configurations for each deployment. Wayne On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Sorry - about the repost, but my 10 month old daughter has taught me
RE: Stand-alone app
Hi Tim,
I'm sorry, but I didn't receive the attachment. It only came through as
what looked like the end of a text message. I suspect that some
firewall must have intervened and deleted the bulk of the attachment.
Also, I was wrong about getting exactly what I wanted in the root
directory from the existing assembly configuration. That zip file that
I got that I said was perfect was just a copy of my hand-edited file
left-over from earlier.
Yes, the ./target/pairfinder-0.9-stand-alone-app.zip file does work, and
I could use it just the way it is. But it is much larger than it needs
to be. If you unzip it and then examine the contents, you'll find that
it contains two duplicate copies of pairfinder-0.9.jar. One is located
at pairfinder-0.9/pairfinder-0.9.jar, and the other is located at
pairfinder-0.9/lib/pairfinder-0.9.jar.
Not only that, but each of those duplicate copies of pairfinder-0.9.jar
contain all the dependency jar libraries rolled up inside themselves
where they do nothing other than take up space. The net result is that
the zip file generated by the assembly:assembly mvn command is 14.1MB in
size, while the result after I have edited out all the unwanted copy of
pairfinder-0.9.jar and the unwanted dependency jars from the other copy
of pairfinder-0.9.jar and then zip everything back up, the resulting zip
file is 3.4MB. And the larger this project gets, the larger that
distributable will get--multiplied by three.
That's why I'm still looking into writing a goal. Even if it turns out
to be possible to get what I want, it should be easier than spending
days messing with it.
Thanks,
--Erik
-Original Message-
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 2:08 PM
To: Maven Users List
Subject: Re: Stand-alone app
Midtskogen, Erik schrieb:
Hi Tim,
Ohhh! I think I see what's happening. I was expecting the final
result zip file to appear under the ./target directory instead of
right in the root directory. After running assembly:assembly there is
a zip file under the ./target directory with a somewhat longer name
pairfinder-0.9-stand-alone-app.zip, and this zip file is quite large
because it has the redundant copies of the jar files. I thought this
was the final artifact of the assembly:assembly goal. I didn't notice
the pairfinder-0.9.zip file sitting right in the root, and this file
is the correct file to distribute the app. It's exactly what I
wanted.
This isn't the result I am getting.
There are two files generated in the target directory:
pairfinder-0.9.jar and
pairfinder-0.9-stand-alone-app.zip. There is no third file generated in
the root directory
of the project.
The jar just contains the compiled classes and the manifest with the
Class-Path entry. And
the zip contains the build artifact and its dependencies... Exactly as
wanted.
I have attached the test project I created. Can you try to run 'mvn
assembly:assambly' on
that and see what it produces for you.
Well, thank you so much!
Even though this jar:jar/assembly:assembly combination does work, I'm
still looking into writing an explicit goal for accomplishing this
task. The fact that lots of people are probably going to want to do
this, but yet it took me (a beginning user, in case you couldn't tell)
several days of fumbling to get it right is an indication that there
may be a need for it. I agree that It's not difficult to use the jar
and assembly to create a stand-alone build once you understand how to
do it. But I think it could be even easier with a goal. Even if
nobody else has any need for it, at least I'm learning a lot about how
Maven works by doing it. And maybe other people would like it, too.
Especially Maven beginners like me :-)
Do you think I should look into writing it as a goal/mojo under the
assembly plugin, in the hopes that maybe I could submit it to the
Maven Project, or should I write it into my own plugin that I write
from scratch?
As Wayne said, writing a small guide to help other new users seems more
appropriate.
Thanks so much!
--Erik
-Original Message-
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 11:52 AM
To: Maven Users List
Subject: Re: Stand-alone app
Just to be sure I understand you correctly: Your problem is that the
dependendcies of your project are included in in the created jar
artifact ('pairfinder-0.9.jar')?
I ask this because I can't reproduce your problem with the
pom/descriptor you posted. I just replaced your internal dependency
with a dependency to commons-beanutils. When I now
run 'mvn assembly:assembly' the artifact is created with the right
classpath entries in
the manifest and the zip file has the dependencies in the lib
directory
???
Have you tried to run a 'mvn clean' before creating the assembly?
-Tim
Midtskogen, Erik schrieb:
Hi Tim,
Hi Tim. Yes, I'm using the assembly plugin to copy the
RE: Stand-alone app
Hi Wayne,
Where would I put such documentation? I don't really see any place on
the maven site to put documentation of tips and techniques. If I were
to create a assembly:stand-alone-app goal, then at least I'd have
somewhere to hang the documentation.
I guess my thinking is that if you can make building a standalone app so
easy that even a newbie can do it with a single command within ten
minutes of starting to use Maven, then that will do a lot more to
promote Maven and increase the user community than requiring mastery of
two different plugins and writing an assembly configuration file, to
boot.
Thanks,
--Erik
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 1:43 PM
To: Maven Users List
Subject: Re: Stand-alone app
Writing a plugin from scratch that basically duplicates existing
effort/code is probably a waste of time.
Adding it under the assembly plugin sounds reasonable. But given that
you got it working with a few configurations in your pom, I'm not even
sure that's necessary. Instead I'd prefer that you just write a little
documentation and provide a sample pom.xml that people can refer to for
building their own stand-alone app.
Wayne
On 6/2/06, Midtskogen, Erik [EMAIL PROTECTED] wrote:
Hi Tim,
Ohhh! I think I see what's happening. I was expecting the final
result zip file to appear under the ./target directory instead of
right in the root directory. After running assembly:assembly there is
a zip file under the ./target directory with a somewhat longer name
pairfinder-0.9-stand-alone-app.zip, and this zip file is quite large
because it has the redundant copies of the jar files. I thought this
was the final artifact of the assembly:assembly goal. I didn't notice
the pairfinder-0.9.zip file sitting right in the root, and this file
is the correct file to distribute the app. It's exactly what I
wanted.
Well, thank you so much!
Even though this jar:jar/assembly:assembly combination does work, I'm
still looking into writing an explicit goal for accomplishing this
task. The fact that lots of people are probably going to want to do
this, but yet it took me (a beginning user, in case you couldn't tell)
several days of fumbling to get it right is an indication that there
may be a need for it. I agree that It's not difficult to use the jar
and assembly to create a stand-alone build once you understand how to
do it. But I think it could be even easier with a goal. Even if
nobody else has any need for it, at least I'm learning a lot about how
Maven works by doing it. And maybe other people would like it, too.
Especially Maven beginners like me :-)
Do you think I should look into writing it as a goal/mojo under the
assembly plugin, in the hopes that maybe I could submit it to the
Maven Project, or should I write it into my own plugin that I write
from scratch?
Thanks so much!
--Erik
-Original Message-
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 11:52 AM
To: Maven Users List
Subject: Re: Stand-alone app
Just to be sure I understand you correctly: Your problem is that the
dependendcies of your project are included in in the created jar
artifact ('pairfinder-0.9.jar')?
I ask this because I can't reproduce your problem with the
pom/descriptor you posted. I just replaced your internal dependency
with a dependency to commons-beanutils. When I now
run 'mvn assembly:assembly' the artifact is created with the right
classpath entries in
the manifest and the zip file has the dependencies in the lib
directory
???
Have you tried to run a 'mvn clean' before creating the assembly?
-Tim
Midtskogen, Erik schrieb:
Hi Tim,
Hi Tim. Yes, I'm using the assembly plugin to copy the dependencies
into a subdirectory called ./lib, and I'm using the jar plugin to
build the executable jar, and actually everything works basically
OK. My only problem is that the jar plugin is adding the dependency
jar files into the executable artifact jar. These are unnecessary
and only increase the size of executable jar file. There is no way
I've found to put a jarred jar library onto the classpath without
writing extra code in your executable to support this. The jar
libraries need
to reside outside the executable jar in the normal filesystem to be
easily accessible.
For now, I'm just removing the unneeded dependency jars from the
executable jar manually, but I'm curious how one might go about
configuring jar:jar so that it properly configures the manifest.mf
without also rolling the dependency jars into its artifact.
Here is my POM:
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
RE: Stand-alone app
Hi Wendy, Thanks. I'll definitely keep that in mind--once I get the thing actually working the way I want it to work! --Erik -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 2:53 PM To: Maven Users List Subject: Re: Stand-alone app On 6/2/06, Midtskogen, Erik [EMAIL PROTECTED] wrote: Hi Wayne, Where would I put such documentation? I don't really see any place on the maven site to put documentation of tips and techniques. If I were to create a assembly:stand-alone-app goal, then at least I'd have somewhere to hang the documentation. The Wiki would be a great place to start: http://docs.codehaus.org/display/MAVENUSER/Home -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. __ The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
getting dependencies
is there way to get all the depenedencies of artifactid, version, and groupId from antrun plugin (build.xml)? Dave
Re: Stand-alone app
I have a build very much like yours. My config for the jar plugin is virtually the same. My assembly xml file is similar. I do NOT get any extra jar files in the executable jar. They are only in the assembled jar under /lib. Here are some differences. I don't see any that should matter. I don't have a packaging tag. I have the classpath prefix as ./lib instead of lib I'm using java 1.4. I have a parent pom that may be supplying something. For someone that knows more about maven than I -- what would one add to a pom for a jar that would cause the dependencies to be added to the jar itself? The situation is that the assembly jar contains the executable jar and the dependencies under the lib folder. The executable jar also contains the dependency jars along with the application class files itself. Is that right? Are the dependency jars inside some folder in the executable jar? On 6/2/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/2/06, Midtskogen, Erik [EMAIL PROTECTED] wrote: Hi Wayne, Where would I put such documentation? I don't really see any place on the maven site to put documentation of tips and techniques. If I were to create a assembly:stand-alone-app goal, then at least I'd have somewhere to hang the documentation. The Wiki would be a great place to start: http://docs.codehaus.org/display/MAVENUSER/Home -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Lee Meador Sent from gmail. My real email address is [EMAIL PROTECTED]
RE: Stand-alone app
Hi Lee, The situation is that the assembly jar contains the executable jar and the dependencies under the lib folder. The executable jar also contains the dependency jars along with the application class files itself. Is that right? Are the dependency jars inside some folder in the executable jar? Not exactly. What I'm looking for is for the dependency jars to reside only in the file system--for example, under ./lib. Then the executable jar's manifest.mf file contains only the project-specific code, and the necessary manifest.mf to put the dependency jars in the file system on the classpath and tell the runtime what class to use as the main class. This is all that is required for an executable jar to run properly, as far as I know. I'm not sure I understand why everyone seems to feel that having the dependency jars also copied into the executable jar itself is useful or desirable. As far as I can tell all it does is bloat the size of the executable jar, since only the dependencies that are in the file system actually get used. And then, of course, if the assembly would zip/tar/jar everything up into one distributable file intended to be unzipped prior to use, that would be nice, too, but it's not essential. --Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee Meador Sent: Friday, June 02, 2006 3:11 PM To: Maven Users List Subject: Re: Stand-alone app I have a build very much like yours. My config for the jar plugin is virtually the same. My assembly xml file is similar. I do NOT get any extra jar files in the executable jar. They are only in the assembled jar under /lib. Here are some differences. I don't see any that should matter. I don't have a packaging tag. I have the classpath prefix as ./lib instead of lib I'm using java 1.4. I have a parent pom that may be supplying something. For someone that knows more about maven than I -- what would one add to a pom for a jar that would cause the dependencies to be added to the jar itself? On 6/2/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/2/06, Midtskogen, Erik [EMAIL PROTECTED] wrote: Hi Wayne, Where would I put such documentation? I don't really see any place on the maven site to put documentation of tips and techniques. If I were to create a assembly:stand-alone-app goal, then at least I'd have somewhere to hang the documentation. The Wiki would be a great place to start: http://docs.codehaus.org/display/MAVENUSER/Home -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Lee Meador Sent from gmail. My real email address is [EMAIL PROTECTED] *** The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. __ The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Stand-alone app
Quick question: is there any way to put jar libraries that are located under the virtual directories inside an executable jar onto the class path, other than by writing code into your application to do this or by unzipping the jars into the computer's filesystem prior to running the executable? I'm thinking about some sort of entry or entries in the manifest.mf file of the executable jar. That would be a logical place to put such a setting, don't you think? Pardon my ignorance if this is something basic. Thanks, --Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee Meador Sent: Friday, June 02, 2006 3:11 PM To: Maven Users List Subject: Re: Stand-alone app I have a build very much like yours. My config for the jar plugin is virtually the same. My assembly xml file is similar. I do NOT get any extra jar files in the executable jar. They are only in the assembled jar under /lib. Here are some differences. I don't see any that should matter. I don't have a packaging tag. I have the classpath prefix as ./lib instead of lib I'm using java 1.4. I have a parent pom that may be supplying something. For someone that knows more about maven than I -- what would one add to a pom for a jar that would cause the dependencies to be added to the jar itself? The situation is that the assembly jar contains the executable jar and the dependencies under the lib folder. The executable jar also contains the dependency jars along with the application class files itself. Is that right? Are the dependency jars inside some folder in the executable jar? On 6/2/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/2/06, Midtskogen, Erik [EMAIL PROTECTED] wrote: Hi Wayne, Where would I put such documentation? I don't really see any place on the maven site to put documentation of tips and techniques. If I were to create a assembly:stand-alone-app goal, then at least I'd have somewhere to hang the documentation. The Wiki would be a great place to start: http://docs.codehaus.org/display/MAVENUSER/Home -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Lee Meador Sent from gmail. My real email address is [EMAIL PROTECTED] *** The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. __ The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Stand-alone app
Hi Lee, I'm sorry. I misunderstood your query. Yes, the situation I'm seeing is exactly as you described. I'm getting unwanted dependency jars copied into the executable jar in addition to the ones I do want copied into the file system under (for example) ./lib. I thought you were asking if that was what I wanted, which, of course, is not the case. Thanks, --Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee Meador Sent: Friday, June 02, 2006 3:11 PM To: Maven Users List Subject: Re: Stand-alone app I have a build very much like yours. My config for the jar plugin is virtually the same. My assembly xml file is similar. I do NOT get any extra jar files in the executable jar. They are only in the assembled jar under /lib. Here are some differences. I don't see any that should matter. I don't have a packaging tag. I have the classpath prefix as ./lib instead of lib I'm using java 1.4. I have a parent pom that may be supplying something. For someone that knows more about maven than I -- what would one add to a pom for a jar that would cause the dependencies to be added to the jar itself? The situation is that the assembly jar contains the executable jar and the dependencies under the lib folder. The executable jar also contains the dependency jars along with the application class files itself. Is that right? Are the dependency jars inside some folder in the executable jar? On 6/2/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 6/2/06, Midtskogen, Erik [EMAIL PROTECTED] wrote: Hi Wayne, Where would I put such documentation? I don't really see any place on the maven site to put documentation of tips and techniques. If I were to create a assembly:stand-alone-app goal, then at least I'd have somewhere to hang the documentation. The Wiki would be a great place to start: http://docs.codehaus.org/display/MAVENUSER/Home -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Lee Meador Sent from gmail. My real email address is [EMAIL PROTECTED] *** The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. __ The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2] Ghost dependencies
Move this to the dependencies tag instead of dependencyManagement and try again. dependencies ... dependency groupIdjakarta-regexp/groupId artifactIdjakarta-regexp/artifactId version1.4/version scoperuntime/scope /dependency /dependencies kris bravo · Clarify Development · office: 678.893.1288 · mobile: 678.296.8723 -Original Message- From: Sebastien Arbogast [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 1:34 AM To: Maven users list Subject: [M2] Ghost dependencies I have trouble understanding the new dependency mechanism. I added a dependency like this in my root pom dependencyManagament section: dependency groupIdjakarta-regexp/groupId artifactIdjakarta-regexp/artifactId version1.4/version scoperuntime/scope /dependency It's not the only one, I've added several ones like that and they all appear in the resulting webapp WEB-INF/lib directory, except for this one. There is no exclude on jakarta-regexp in other dependencies, and I can't find what's wrong. Any idea? -- Sébastien Arbogast The Epseelon Project : http://www.epseelon.net Blog : http://sebastien-arbogast.epseelon.net TagSpot : http://www.tagspot.org - 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]
Pragma: no-cache on GET requests?
Here's a GET that Maven 2.0.4 generated: GET /maven/mirror/ibiblio/org/apache/maven/plugins/maven-surefire- plugin/2.2-SNAPSHOT/maven-surefire-plugin-2.2-SNAPSHOT.pom HTT P/1.1 Pragma: no-cache User-Agent: Java/1.5.0_06 Host: dev.manhunt.net Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive Content-type: application/x-www-form-urlencoded Is there a way to disable the no-cache pragma? I set up a caching reverse proxy of ibiblio (i.e., a partial mirror), and was surprised when Maven disabled it. — G
Maven Assembly
Has anyone else noticed how the main jar file you create is now included as a dependency when using the dependendencySets in an assembly file? Now the zip I create has 2 copies of my main jar in it? One under the output directory for files picked up as dependencies and one under the main directory? BTW this is only occurring with 2.0.4 too...I reverted back to 2.0.3 and did an assembly and the main file wasn't included twice. --Rudy
Re: Stand-alone app
Erik,
I have sent you the project in a private mail too. Have you received that?
However, I misunderstood you until now. I thought your only problem was the dependencies
in the executable jar and not the duplicate executable jar in the created assembly. I get
this as well. I will send you another test project per private mail. Can you run that and
tell if it produces everything as expected.
-Tim
Midtskogen, Erik schrieb:
Hi Tim,
I'm sorry, but I didn't receive the attachment. It only came through as
what looked like the end of a text message. I suspect that some
firewall must have intervened and deleted the bulk of the attachment.
Also, I was wrong about getting exactly what I wanted in the root
directory from the existing assembly configuration. That zip file that
I got that I said was perfect was just a copy of my hand-edited file
left-over from earlier.
Yes, the ./target/pairfinder-0.9-stand-alone-app.zip file does work, and
I could use it just the way it is. But it is much larger than it needs
to be. If you unzip it and then examine the contents, you'll find that
it contains two duplicate copies of pairfinder-0.9.jar. One is located
at pairfinder-0.9/pairfinder-0.9.jar, and the other is located at
pairfinder-0.9/lib/pairfinder-0.9.jar.
Not only that, but each of those duplicate copies of pairfinder-0.9.jar
contain all the dependency jar libraries rolled up inside themselves
where they do nothing other than take up space. The net result is that
the zip file generated by the assembly:assembly mvn command is 14.1MB in
size, while the result after I have edited out all the unwanted copy of
pairfinder-0.9.jar and the unwanted dependency jars from the other copy
of pairfinder-0.9.jar and then zip everything back up, the resulting zip
file is 3.4MB. And the larger this project gets, the larger that
distributable will get--multiplied by three.
That's why I'm still looking into writing a goal. Even if it turns out
to be possible to get what I want, it should be easier than spending
days messing with it.
Thanks,
--Erik
-Original Message-
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 2:08 PM
To: Maven Users List
Subject: Re: Stand-alone app
Midtskogen, Erik schrieb:
Hi Tim,
Ohhh! I think I see what's happening. I was expecting the final
result zip file to appear under the ./target directory instead of
right in the root directory. After running assembly:assembly there is
a zip file under the ./target directory with a somewhat longer name
pairfinder-0.9-stand-alone-app.zip, and this zip file is quite large
because it has the redundant copies of the jar files. I thought this
was the final artifact of the assembly:assembly goal. I didn't notice
the pairfinder-0.9.zip file sitting right in the root, and this file
is the correct file to distribute the app. It's exactly what I
wanted.
This isn't the result I am getting.
There are two files generated in the target directory:
pairfinder-0.9.jar and
pairfinder-0.9-stand-alone-app.zip. There is no third file generated in
the root directory
of the project.
The jar just contains the compiled classes and the manifest with the
Class-Path entry. And
the zip contains the build artifact and its dependencies... Exactly as
wanted.
I have attached the test project I created. Can you try to run 'mvn
assembly:assambly' on
that and see what it produces for you.
Well, thank you so much!
Even though this jar:jar/assembly:assembly combination does work, I'm
still looking into writing an explicit goal for accomplishing this
task. The fact that lots of people are probably going to want to do
this, but yet it took me (a beginning user, in case you couldn't tell)
several days of fumbling to get it right is an indication that there
may be a need for it. I agree that It's not difficult to use the jar
and assembly to create a stand-alone build once you understand how to
do it. But I think it could be even easier with a goal. Even if
nobody else has any need for it, at least I'm learning a lot about how
Maven works by doing it. And maybe other people would like it, too.
Especially Maven beginners like me :-)
Do you think I should look into writing it as a goal/mojo under the
assembly plugin, in the hopes that maybe I could submit it to the
Maven Project, or should I write it into my own plugin that I write
from scratch?
As Wayne said, writing a small guide to help other new users seems more
appropriate.
Thanks so much!
--Erik
-Original Message-
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 11:52 AM
To: Maven Users List
Subject: Re: Stand-alone app
Just to be sure I understand you correctly: Your problem is that the
dependendcies of your project are included in in the created jar
artifact ('pairfinder-0.9.jar')?
I ask this because I can't reproduce your problem with the
pom/descriptor you posted. I just replaced your internal
RE: Maven Assembly
Hi Rudy, Yes, I'm seeing this when assembly runs. And yes, I'm using maven 2.0.4. I wonder if this is related to my issue of seeing all the dependency jar libraries jarred up into the executable jar I'm trying to create during the package (jar:jar) lifecycle. --Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 3:53 PM To: users@maven.apache.org Subject: Maven Assembly Has anyone else noticed how the main jar file you create is now included as a dependency when using the dependendencySets in an assembly file? Now the zip I create has 2 copies of my main jar in it? One under the output directory for files picked up as dependencies and one under the main directory? BTW this is only occurring with 2.0.4 too...I reverted back to 2.0.3 and did an assembly and the main file wasn't included twice. --Rudy *** The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. __ The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with filtering of property files
Are the files underneath subdirectories? You may need to go from this:
includecontext.xml/include
includeversion.properties/include
To this:
includecontext.xml/include
include**/version.properties/include
kris bravo * Clarify Development * office: 678.893.1288 * mobile:
678.296.8723
-Original Message-
From: Claus Myglegaard Vagner [mailto:[EMAIL PROTECTED]
Sent: Friday, June 02, 2006 9:59 AM
To: Maven Users List
Subject: Problem with filtering of property files
Hi,
I have a problem filtering property files (using maven 2.0.4):
Setup:
...
build
finalNameplanb/finalName
sourceDirectorysrc/java/sourceDirectory
testSourceDirectorysrc/test/testSourceDirectory
filters
filter${basedir}/context.properties/filter
/filters
resources
resource
directory${basedir}/src/conf/directory
filteringtrue/filtering
includes
includecontext.xml/include
includeversion.properties/include
/includes
/resource
...
/resources
...
/build
...
Filtering of the above context.xml works fine, but filtering of
version.properties dosn't seem to work?
If I create a version.xml file instead an replaces it with
version.properties again it works... (any difference for *.xml contra
*.properties filtering?)
Ideally I would like to use settings.xml as filter instead of
context.properties but it only seems to work with context.properties...
Can anybody please help me with
1. why isn't version.properties being filtered?
2. why can't I use settings.xml as a filter?
Best Regards,
Claus
-
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]
Changing the version specified in a middle tier module...
Here's the scenario - we have three levels of modules - top, middle, bottom. In the top level module, that pom says it depends on some snapshot of the middle level module. That middle level module depends on some version of the bottom level module. If the middle tier doesn't change, how can I specify to use a specific version of that middle tier instead of snapshot?
Firing off a shellscript prior to unittesting
Quick question - if I need to have a server started for unittesting (which is started up via a shell script), how does one go about doing this and is this considered safe (I wouldn't consider these unittests personally)?
scripts/bin directory
According to the following document http://maven.apache.org/guides/introduction/introduction-to-the-standard -directory-layout.html Where are scripts supposed to be located (and where is this mentioned on the site)?
Re: Problem with filtering of property files
I am not precisely sure what the difference is, but from looking at the
filtering code in the maven-resources-plugin in the past, I know that it
does treat *.properties files differently than other files.
These things might make a difference, too:
1. What delimiters are you using for the tokens? ${} is probably more
likely to work than @@.
2. How are the properties specified? There is an issue with replacing
system properties (specified on the command line with -Dname=value). Are
you are using system properties in your token replacements?
3. Watch out for typos that might mess up the token replacement engine.
For example, an unmatched }, {, or @ character can mess up replacement.
As a real-world example of #3, the jboss-service.xml file that ships
with JBoss 4.0.3SP1 has a typo in it, and my token replacements weren't
working properly until I resolved it. This was the offending line (note
the paren instead of curly brace after jboss.server.home):
scans ${jboss.server.home)/deploy, which is always local
-Max
Claus Myglegaard Vagner wrote:
Hi,
I have a problem filtering property files (using maven 2.0.4):
Setup:
...
build
finalNameplanb/finalName
sourceDirectorysrc/java/sourceDirectory
testSourceDirectorysrc/test/testSourceDirectory
filters
filter${basedir}/context.properties/filter
/filters
resources
resource
directory${basedir}/src/conf/directory
filteringtrue/filtering
includes
includecontext.xml/include
includeversion.properties/include
/includes
/resource
...
/resources
...
/build
...
Filtering of the above context.xml works fine, but filtering of
version.properties dosn't seem to work?
If I create a version.xml file instead an replaces it with
version.properties again it works... (any difference for *.xml contra
*.properties filtering?)
Ideally I would like to use settings.xml as filter instead of
context.properties but it only seems to work with context.properties...
Can anybody please help me with
1. why isn't version.properties being filtered?
2. why can't I use settings.xml as a filter?
Best Regards,
Claus
-
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: Stand-alone app
Thank you. My setup, so similar to yours, generates things organized as you want. That's what I want as well. I don't know why yours doesn't. Sometimes knowing that someone else is doing something similar to what you are doing and they get the right results is useful. So the real question is what are you doing (or not doing) that causes the dependency jars to get put into your executable jar? On 6/2/06, Tim Kettler [EMAIL PROTECTED] wrote: Erik, I have sent you the project in a private mail too. Have you received that? However, I misunderstood you until now. I thought your only problem was the dependencies in the executable jar and not the duplicate executable jar in the created assembly. I get this as well. I will send you another test project per private mail. Can you run that and tell if it produces everything as expected. -Tim Midtskogen, Erik schrieb: Hi Tim, I'm sorry, but I didn't receive the attachment. It only came through as what looked like the end of a text message. I suspect that some firewall must have intervened and deleted the bulk of the attachment. Also, I was wrong about getting exactly what I wanted in the root directory from the existing assembly configuration. That zip file that I got that I said was perfect was just a copy of my hand-edited file left-over from earlier. Yes, the ./target/pairfinder-0.9-stand-alone-app.zip file does work, and I could use it just the way it is. But it is much larger than it needs to be. If you unzip it and then examine the contents, you'll find that it contains two duplicate copies of pairfinder-0.9.jar. One is located at pairfinder-0.9/pairfinder-0.9.jar, and the other is located at pairfinder-0.9/lib/pairfinder-0.9.jar. Not only that, but each of those duplicate copies of pairfinder-0.9.jar contain all the dependency jar libraries rolled up inside themselves where they do nothing other than take up space. The net result is that the zip file generated by the assembly:assembly mvn command is 14.1MB in size, while the result after I have edited out all the unwanted copy of pairfinder-0.9.jar and the unwanted dependency jars from the other copy of pairfinder-0.9.jar and then zip everything back up, the resulting zip file is 3.4MB. And the larger this project gets, the larger that distributable will get--multiplied by three. That's why I'm still looking into writing a goal. Even if it turns out to be possible to get what I want, it should be easier than spending days messing with it. Thanks, --Erik -Original Message- From: Tim Kettler [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 2:08 PM To: Maven Users List Subject: Re: Stand-alone app Midtskogen, Erik schrieb: Hi Tim, Ohhh! I think I see what's happening. I was expecting the final result zip file to appear under the ./target directory instead of right in the root directory. After running assembly:assembly there is a zip file under the ./target directory with a somewhat longer name pairfinder-0.9-stand-alone-app.zip, and this zip file is quite large because it has the redundant copies of the jar files. I thought this was the final artifact of the assembly:assembly goal. I didn't notice the pairfinder-0.9.zip file sitting right in the root, and this file is the correct file to distribute the app. It's exactly what I wanted. This isn't the result I am getting. There are two files generated in the target directory: pairfinder-0.9.jar and pairfinder-0.9-stand-alone-app.zip. There is no third file generated in the root directory of the project. The jar just contains the compiled classes and the manifest with the Class-Path entry. And the zip contains the build artifact and its dependencies... Exactly as wanted. I have attached the test project I created. Can you try to run 'mvn assembly:assambly' on that and see what it produces for you. Well, thank you so much! Even though this jar:jar/assembly:assembly combination does work, I'm still looking into writing an explicit goal for accomplishing this task. The fact that lots of people are probably going to want to do this, but yet it took me (a beginning user, in case you couldn't tell) several days of fumbling to get it right is an indication that there may be a need for it. I agree that It's not difficult to use the jar and assembly to create a stand-alone build once you understand how to do it. But I think it could be even easier with a goal. Even if nobody else has any need for it, at least I'm learning a lot about how Maven works by doing it. And maybe other people would like it, too. Especially Maven beginners like me :-) Do you think I should look into writing it as a goal/mojo under the assembly plugin, in the hopes that maybe I could submit it to the Maven Project, or should I write it into my own plugin that I write from scratch? As Wayne said, writing a small guide to help other new users seems more
Re: Maven Assembly
I am using 2.0.4 and I do not get two copies. I checked a zip file built just 3 minutes ago. This is what's in my assembly xml file: dependencySets dependencySet outputDirectory/lib/outputDirectory unpackfalse/unpack scoperuntime/scope /dependencySet /dependencySets I recently deleted my entire repository and reloaded everything. All that means is that my plugin versions are stable. I am using assembly plugin version 2.1. On 6/2/06, Midtskogen, Erik [EMAIL PROTECTED] wrote: Hi Rudy, Yes, I'm seeing this when assembly runs. And yes, I'm using maven 2.0.4. I wonder if this is related to my issue of seeing all the dependency jar libraries jarred up into the executable jar I'm trying to create during the package (jar:jar) lifecycle. --Erik -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 3:53 PM To: users@maven.apache.org Subject: Maven Assembly Has anyone else noticed how the main jar file you create is now included as a dependency when using the dependendencySets in an assembly file? Now the zip I create has 2 copies of my main jar in it? One under the output directory for files picked up as dependencies and one under the main directory? BTW this is only occurring with 2.0.4 too...I reverted back to 2.0.3 and did an assembly and the main file wasn't included twice. --Rudy *** The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. __ The information in this email (including any attachments) is confidential and may be legally privileged. Access to this e-mail by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it (including any attachments) is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, all attachments, and any copies thereof from your system and destroy any printout thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Lee Meador Sent from gmail. My real email address is [EMAIL PROTECTED]
RE: ArcheType definition
Yes it is: http://maven.apache.org/guides/mini/guide-creating-archetypes.html Unfortunately, the command line for a custom tag is a bit clunky. You have to pass the artifactId and groupId of your archetype as parameters. kris bravo * Clarify Development * office: 678.893.1288 * mobile: 678.296.8723 -Original Message- From: Roland Asmann [mailto:[EMAIL PROTECTED] Sent: Thursday, June 01, 2006 1:46 PM To: Maven Users List Subject: ArcheType definition Hi, I was wondering if it is possible to write my own Archetype-definition, so that when I run 'mvn achetype:create' Maven will generate me a POM that has some more stuff in it than the current default. The thing is, that my company will be writing lots of projects that are fairly similar, so I have introduced a company- wide POM, which I would like to have automatically added to the POM created with an archetype:create. Also, depending on the type of project (currently we have 4 different types), I want to add the default plugins and dependencies for those type of projects. Is there an easy and fast way, or should I re-write the Archetype-plugin as a new plugin that has this functionality? Roland - 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] How to change log level of maven?
I was hoping I can set WARN or even ERROR only :( thanks! Szczepan On 6/2/06, Kenney Westerhof [EMAIL PROTECTED] wrote: On Fri, 2 Jun 2006, Szczepan Faber wrote: How to change log level of maven? I mean the output on the console when you launch mvn goal. By default I guess that 'INFO' level is applied. Yes, the default is INFO. You can enable DEBUG by specifying the '-X' option. Currently these are the only loglevels that are accessible through the commandline. -- kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - 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: scripts/bin directory
I am just another Maven user, so don't take this response as Maven gospel... I assume you mean scripts that end users will run to start your application, or something of that nature. I am not aware of any plugins that do anything with such scripts, so I don't think there is a prescribed location. Perhaps src/main/scripts or something like that would be a reasonable choice. How do these scripts become a part of an artifact produced by the maven build? You will likely have to configure a plugin with the path that you choose. -Max EJ Ciramella wrote: According to the following document http://maven.apache.org/guides/introduction/introduction-to-the-standard -directory-layout.html Where are scripts supposed to be located (and where is this mentioned on the site)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: scripts/bin directory
EJ Ciramella wrote: According to the following document http://maven.apache.org/guides/introduction/introduction-to-the-standard -directory-layout.html Where are scripts supposed to be located (and where is this mentioned on the site)? The scripts for Maven 2 itself is in src/bin/ See: http://svn.apache.org/viewvc/maven/components/trunk/maven-cli/src/bin/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: scripts/bin directory
What is the lifecycle to use to have these copied over to the target directory? I have this: build scriptSourceDirectorybin/scriptSourceDirectory plugins plugin artifactIdmaven-assembly-plugin/artifactId configuration descriptorsrc/main/assembly/dep.xml/descriptor /configuration /plugin /plugins /build But I can't get them copied over... -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 4:59 PM To: Maven Users List Subject: Re: scripts/bin directory EJ Ciramella wrote: According to the following document http://maven.apache.org/guides/introduction/introduction-to-the-standard -directory-layout.html Where are scripts supposed to be located (and where is this mentioned on the site)? The scripts for Maven 2 itself is in src/bin/ See: http://svn.apache.org/viewvc/maven/components/trunk/maven-cli/src/bin/ -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Compiling sub-modules/artifacts in different jdks...
Thank you, both - will try and let you know. I was hoping there was a way to compile the EJB in 1.5 but fork the process to compile the client with a different JDK (1.4) within the generateClient portion of the EJB plugin (vs. a separate custom module for the EJB client), though. Thanks, Daryl -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 8:38 AM To: Maven Users List Subject: Re: Compiling sub-modules/artifacts in different jdks... On 5/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is anyone aware of a way to compile artifacts or even sub-modules under different JDKs? I have an EJB that I compile under 1.5 but I want to generate the ejb-client compiled under 1.4 (there's nothing in the interfaces or DTOs that are 1.4-incompatible) so that 1.4-based clients can call it. Any thoughts? I assume you've configured the compiler plugin to target 1.5 at the top level of your project [1], so (as Tim mentioned) you can override the configuration to target 1.4 in the sub-module. Something that Jakarta Commons does (with Maven 1) is add X-Compile-Target: 1.4 to the manifest, to reassure people since it will otherwise just say Build-Jdk: 1.5.0_06. I haven't figured out how to do this with m2 yet. [1] http://maven.apache.org/plugins/maven-compiler-plugin/howto.html -- 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: Free book on maven 2.0
If you find any errors in the book, that are not covered on the errata page [1], please send them to Mergere. The adress is on the errata page. [1] http://www.mergere.com/m2book_errata.jsp Piéroni Raphaël wrote: There are some typo remaining like the the 2006/6/2, Carlos Sanchez [EMAIL PROTECTED]: Not yet, I hope it will be soon. On 6/1/06, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 6/1/06, Brett Porter [EMAIL PROTECTED] wrote: Well, then - the users have spoken! http://maven.apache.org/articles.html Btw, is the printed book available for sales somewhere? Have found no pointer on the Mergere site and Amazon doesn't know it. -- Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain) - 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] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multiple passes of filtering
Is there a way to do multiple passes of filtering? I have one property file that I want filtered 4 times to 4 different target directories from 4 different filter files since I have to deal with creating property files for 4 different Server environments. It would be nice to do this in one swoop so I'm not having to recompile the base code each time. --Rudy
