Re: release:perform fails
Be sure to issue svn update before the "mvn release:perform". This can fix some types of errors, even though it prints nothing and an "svn status" command appears to show the project up to date. -Ken Chris Graham wrote: Ok, it is attempting to check out this: http://svn.warpspeed.com.au/svn/repos/FireDragon/tags/FireDragon-1.0.8/ which does not have the complete contents of all of the projects in it (but I guess that it should...) so, release:prepare may not be working after all... -Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Having trouble with Maven release plugin using SubVersion
I think I found a solution: Before issuing the 'mvn release:prepare' command, an 'svn update' on the parent directory of the directory renamed (or at the top level) will update the SubVersion metadata. The update command doesn't print anything so it appears like it doesn't do anything, but it's required nonetheless. Would there be any harm in having the release plugin perform an 'svn update' at the start of the release:prepare goal? Also found a few flaws with my earlier perl script. Should have issued a 'mvn clean' at line 87 so the target directory is not added to version control. Forgot to add a tags directory: mkdir aProject/tags, after line 106 Could have left out the creation of a sample configuration file (myconf.xml) lines 88 to 100, it wasn't needed to reproduce the problem. The directory name could have been "foo" and renamed to "bar", so this has nothing to do with the standard maven 2 naming convention of src/main/config. If I created a FILE, not a directory, then there would be no error, even without the 'svn update'. -Ken Dennis Lundberg wrote: Did you use the 'svn move ...' command to rename the directory or did you do it directly on the file system for your working copy? If you did the second your working copy will not have correct subversion metadata. Ken Tanaka wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Having trouble with Maven release plugin using SubVersion
I did use 'svn move src/main/conf src/main/config' for the rename. (Although I have been caught by using the regular mv before.) -Ken Dennis Lundberg wrote: Did you use the 'svn move ...' command to rename the directory or did you do it directly on the file system for your working copy? If you did the second your working copy will not have correct subversion metadata. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Having trouble with Maven release plugin using SubVersion
Hi,
I had an error using mvn release:prepare after I had created a
src/main/conf directory under SubVersion, then renamed it
src/main/config to match the Maven 2 convention. I'm not sure if I'm not
following a Maven or SubVersion convention, or if this is a bug.
The workaround, noted in the following perl script loses the revision
history. The rest of this post is a perl script to replicate the problem
for a unix-like system. The header comment provides a number of details.
(I'm hoping line wrap doesn't mess this up ;-) Run this script in clean
disposable directory.
If anyone has a suggestion on avoiding the error, please post.
Thanks,
Ken
=== start of testMvnRelease.pl ===
#!/usr/bin/perl -w
##
## File: testMvnRelease.pl
##
## I had an error using mvn release:prepare after I had
## created a src/main/conf directory under SubVersion,
## then renamed it src/main/config to match the Maven 2
## convention. I'm not sure if I'm not following a Maven
## or SubVersion convention, or if this is a bug.
##
## I'm seeing this error:
##
## [INFO]
## [ERROR] BUILD FAILURE
## [INFO]
## [INFO] Unable to tag SCM
## Provider message:
## The svn tag command failed.
## Command output:
## svn: Commit failed (details follow):
## svn: Directory
'/extra/data/src/java/testMvnRelease/myProject/trunk/target/.svn'
## containing working copy admin area is missing
##
## My workaround was to create a copy of the project,
## wipe out all the revision history (.svn directories),
## and enter it into SubVersion as a new project as if the
## configuration directory had been named src/main/config
## from the start. Is there a better way to correct this
## category of error without losing the revision history?
##
## This script is a self-contained way to explore reproducing
## this behavior. There's a lot of setup, so I wanted to make
## it easy for others to see what I'm doing.
##
## Versions: Maven version: 2.0.9
##Java version: 1.6.0_03
##OS name: "linux" version: "2.6.18-92.1.10.el5" arch: "amd64"
Family: "unix"
##svn, version 1.4.2 (r22196)
##
## For reference I'm going by:
## http://maven.apache.org/plugins/maven-release-plugin/
##
## Summary of the standard Maven directory layout:
## myProject
## +- trunk
## +- src
## +- main
## +- config<-- area of concern
## +- java
##
## If you don't have perl, but are using a unix-like system,
## then the commands between backticks can be executed on the comand
## line. For this reason I've mimmicked the command line, e.g. using
## the system "rm" rather than the perl built-in "unlink" command.
## The chdir commands are used in Perl since the 'cd' commands
## would otherwise be transient. To excecute outside Perl, the "chdir"
## commands should be converted as
##chdir 'aProject' --> cd aProject
## Cleanup code for subsequent runs.
## Not needed the first time through.
if (-e 'aProject') {
## existing directory is removed recursively (-r)
print `rm -r aProject`;
}
if (-e 'myProject') {
## use force (-f) option to override any svn permissions
print `rm -rf myProject`;
}
if (-e '/tmp/repos') {
print `rm -rf /tmp/repos`;
}
## Create the standard maven project
print "Create a maven project\n";
print `mkdir aProject`;
chdir 'aProject';
print `mvn archetype:create -DgroupId=com.mycompany.app
-DartifactId=my-app`;
## There should be no errors. Compile and run to test.
## The following commands should work
chdir 'my-app';
print `mvn package`;
print `java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App`;
## Standard project prints "Hello World!" Pause 3 seconds to see result
print `sleep 3`;
## create a directory with wrong name "conf", then correct it later
print `mkdir src/main/conf`;
## create a config file
open CONF, ">src/main/conf/myconf.xml"
or die "couldn't create config file\n";
print CONF '
';
close CONF;
## Add project to SubVersion version control
## Go back up two directory levels
chdir '../..';
## change my-app to trunk (a subversion convention)
print `mv aProject/my-app aProject/trunk`;
## create a new (disposable) repository on local disk
print `svnadmin create /tmp/repos`;
## Put aProject under version control as myProject
print `svn import aProject file:///tmp/repos/myProject -m "initial import"`;
## Now pull out a version-controlled copy of the project: myProject
## (aProject is not needed and ignored from now on)
print `svn checkout file:///tmp/repos/myProject myProject`;
## Change src/main/conf to src/main/config to match the standard
## maven directory naming convention
chdir 'myProject/trunk';
print `svn move src/main/conf src/main/config`;
print `svn status`;
print `svn commit -m "comply with mvn convention, conf renamed to config"`;
## Add scm info
Re: Porpuse of src/main/config
Geoffrey Wiseman wrote: On Fri, Aug 1, 2008 at 11:00 AM, DOMINGUEZ Felipe < [EMAIL PROTECTED]> wrote: I am new to Maven, and I am a bit confuse about the porpuse of directory src/main/config porpuse ... Can any body clarify the usage of src/main/config and what is maven approach for using configuration files such as hibernate.cfg.xml or other config files that need to be modified on the live environment? What about this? http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html I think that page is a bit sparse, it's a good list of what should be in the directory structure, but doesn't explain differences, provide examples of use or problems solved, version control interaction or best practices. I think the books are a good place ( http://maven.apache.org/articles.html ) for detail, but beware that "A Developer's Notebook" is for version 1.0.2 which is significantly different. The version 2.0 references I've looked into from here are good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Date and time processing
I was thinking the same thing myself. I searched at the archive
http://www.nabble.com/Maven---Users-f178.html
for "timestamp" and the one of the better threads seems to be
http://www.nabble.com/Can-I-get-a-timestamp--tf3183791s177.html#a8836362
-Ken
Wayne Fay wrote:
This comes up pretty often, in fact, it has come up at least once a week lately.
Search the list archives for "timestamp".
Wayne
On 8/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Does Maven or one of it's plugins support date/time stamping? In
particular, I'd like to add the build date to my Manifests with something
like
org.apache.maven.plugins
maven-jar-plugin
...
${now}
...
Thanks
Robert Egan
This email message and any attachments may contain confidential,
proprietary or non-public information. The information is intended solely
for the designated recipient(s). If an addressing or transmission error
has misdirected this email, please notify the sender immediately and
destroy this email. Any review, dissemination, use or reliance upon this
information by unintended recipients is prohibited. Any opinions
expressed in this email are those of the author personally.
-
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: Specifying/Installing dependencies
I recommend installing with a version number. If the jar is version 2.3, but they released it as just "useful.jar", I would install it as "useful-2.3.jar" If their website or documentation doesn't give a version, but a release date, you might use "useful-2006.01.23.jar". Failing all that, you can make up a version, prefixed or suffixed by your initials, or company initials, to cue you in later that the version is not official. For example, installed as "useful-jm-0.1.jar" and entered into the pom.xml as: org.third.party useful jm-0.1 If anyone has better advice, please enlighten me. -Ken Jeff Mutonho wrote: > But ,can one install non versioned jars , if you wish/ prefer to do so? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- = Enterprise Data Services Division === | CIRES, National Geophysical Data Center / NOAA | = [EMAIL PROTECTED] = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2]Does bestpractices.html apply to maven 2?
Thanks for the response. I'm sure a lot of people new to Maven are wondering what applies to Maven2 on the website. I recommend to the documentation maintainers to add more version notices to the website where content only applies to a particular version of Maven. -Ken Napoleon Esmundo Ramirez wrote: > Hello, > > Yes, it is indeed written for Maven 1 but most concepts apply too in Maven > 2. I think the ideas that are common to Maven 1 & 2 include: using > conventions (which I think is one of the points of using best practices), > following the project development cycle and the use of plugins for > extensibility. For all other stuff I missed, just consult 'em here in the > mailing list. :) > > Cheers! > Nap > > On 3/1/06, Ken Tanaka <[EMAIL PROTECTED]> wrote: > >> I have a documentation question: >> >> At the bottom of the page >> http://maven.apache.org/using/bestpractices.html >> is a section called "Getting ready for Maven 2." I take this to mean >> that the page above is for Maven 1. Does any of it apply to Maven 2? >> >> Thanks, >> Ken >> >> -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2]Does bestpractices.html apply to maven 2?
I have a documentation question: At the bottom of the page http://maven.apache.org/using/bestpractices.html is a section called "Getting ready for Maven 2." I take this to mean that the page above is for Maven 1. Does any of it apply to Maven 2? Thanks, Ken -- = Enterprise Data Services Division === | CIRES, National Geophysical Data Center / NOAA | = Ken.Tanaka%noaa.gov = - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
is basedir undocumented?
I'm new to maven and didn't find this in the archive, but it seems that
${basedir} is not documented. It seems to be set to the directory of the
project.xml file. Is this always the case? and are there
reasons/techniques to change basedir?
I eventually tried adding to project.xml:
error
${basedir}
no.match
jar
http://www.maven.org/
I wanted to force a download error that would help me figure out what
${basedir} was. (Less output to wade through than the "-X" option to
maven.) Is there a better way to print out variables when running maven?
Thanks,
-Ken
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
