Hi Brian!
I've added a new flag to the Assembly plugin that will tell the
plugin to only run in the Execution Root folder and skip everything else.
I'm not sure if this solution will work. I know of a few projects using the
assembly plugin in submodules for other things than
Le mardi 05 mai 2009 00:12:55, Brian Fox a écrit :
Why would you have a symlink in your target folder to someplace important?
Here is a quick example that came to my mind : Imagine you package a tarball
containing such a symlink and that during the build you have to extract it to
change
Maven parses scm output. I don't remember details, but I've had the same
problem.
My solution was permanent setting LC_MESSAGES to C.
Greetings
Grzegorz Slowikowski
Paul MERLIN wrote:
Hey,
I'm facing weird problems with the maven-release-plugin and friends.
I use
Hi,
There is an implementation of svn only in java (using svnkit) which is
available here [1].
You can use that with adding a dependency in the maven-release-plugin :
dependency
groupIdcom.google.code.maven-scm-provider-svnjava/groupId
Symlinks are needed by some frameworks we use and that need some shared
directories between several webapp.
/home was just a sample, in our case we have symlink to a share /DATA
repository.
When you run mvn clean and that you loose all your /DATA (many gigabytes of
data), I can say you that you
Daniel Kulp wrote:
This is just a warning that the Maven team has just discovered an interaction
problem between Maven 2.1 and the maven-gpg-plugin that CAN result in the
signatures for the installed/deployed poms being invalid. Signatures for the
other artifacts (jars, wars, etc..) are
Mark Struberg wrote:
Hi Brian!
I've added a new flag to the Assembly plugin that will tell the
plugin to only run in the Execution Root folder and skip everything else.
I'm not sure if this solution will work. I know of a few projects using the
assembly plugin in submodules for
Fair enough. I personally don't have the bandwidth to look into this
again now (i'm already looking at some release, assembly, and gpg issues
that are blockers). The last time I checked I wasn't able to reproduce
it. If someone wants to supply a patch with tests, then I can apply it.
Bouiaw
Hello,
I am using the Maven Project jar 2.1.0.
I get the following exception when I use it:
Exception in thread main java.lang.NullPointerException
at
org
.apache
.maven.project.ProjectUtils.buildArtifactRepository(ProjectUtils.java:
115)
at
org
.apache
.maven
Hey,
I had no issue building my projects.
release:prepare is working but release:perform is not (see the trace below).
I switched to 2.1.0 right after that and the release:perform went well.
I'm using the javasvn scm provider here but I get the same error using the
native one.
/Paul
Hi Paul,
Author: pgier
Date: Tue May 5 16:34:00 2009
New Revision: 771907
URL: http://svn.apache.org/viewvc?rev=771907view=rev
Log:
[MANTTASKS-142] Improve default remote repository id.
Added:
On Tue May 5 2009 7:47:04 am Benjamin Bentmann wrote:
Daniel Kulp wrote:
This is just a warning that the Maven team has just discovered an
interaction problem between Maven 2.1 and the maven-gpg-plugin that CAN
result in the signatures for the installed/deployed poms being invalid.
Thanks,
I've tried with a svn:// url without any problem (releasing branching).
/Paul
Le mardi 05 mai 2009 11:41:15, Olivier Lamy a écrit :
Hi,
There is an implementation of svn only in java (using svnkit) which is
available here [1].
You can use that with adding a dependency in the
What options are being passed to the release invocation? It's using -f
which seems to be invalid.
Paul MERLIN wrote:
Hey,
I had no issue building my projects.
release:prepare is working but release:perform is not (see the trace below).
I switched to 2.1.0 right after that and the
Ok, it's done.
Thanks for the suggestions!
Benjamin Bentmann wrote:
Hi Paul,
Author: pgier
Date: Tue May 5 16:34:00 2009
New Revision: 771907
URL: http://svn.apache.org/viewvc?rev=771907view=rev
Log:
[MANTTASKS-142] Improve default remote repository id.
Added:
15 matches
Mail list logo
