+1
2011/7/30 Dennis Lundberg denn...@apache.org:
Hi,
We solved 46+1 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501
There are still a couple of
Hi!
Most of our plugins have an old parent 20 or 19.
maven-acr-plugin/pom.xml:artifactIdmaven-plugins/artifactId
maven-ant-plugin/pom.xml:artifactIdmaven-plugins/artifactId
maven-antrun-plugin/pom.xml:artifactIdmaven-plugins/artifactId
maven-assembly-plugin/pom.xml:
I committed a fix for MNG-3951's test case that stopped it breaking on Mac (and
passed the first Jenkins ubuntu run).
A later build threw up this:
https://builds.apache.org/job/core-integration-testing-maven-3-trunk-jdk-1.6/7/testReport/
It's full of path related issues, but my change didn't
Looks like they pass on ubuntu1 but fail on ubuntu3 - I'd guess that
/home/jenkins is a symlink on ubuntu3 but not on ubuntu1, and that something
in the tests is resolving the symlink on one side but not resolving it on
the other. Just a guess, from the Jenkins side of things.
A.
On Mon, Aug 1,
On Thu, Jul 28, 2011 at 6:04 AM, Martin Gainty mgai...@hotmail.com wrote:
Larry-
try loading both dependencies in your local repository and running offline
with mvn -o (at least your dependencies will be found)
did you check cobertura for errors?
mvn -e -X cobertura:cobertura
Yup, that was it. I've fixed it for those tests, and it seems to be ok now.
All things going well it may make sense to have the verifier return the
extracted resources as a canonical path so it's consistent across test cases,
since that's what ends up being compared against from maven.
- Brett
+1
Vincent
2011/7/30 Dennis Lundberg denn...@apache.org:
Hi,
We solved 46+1 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501
There are still a
I suspected this was a problem with the length of the path. Seems to be working
after wiping out the working copy, in case anyone else stumbles onto it.
The next problem was the -Dmaven.home property not escaping properly. I removed
the maven.repo.local as it was duplicated (thanks to the
On 02/08/2011, at 4:03 AM, Brett Porter wrote:
I suspected this was a problem with the length of the path. Seems to be
working after wiping out the working copy, in case anyone else stumbles onto
it.
The next problem was the -Dmaven.home property not escaping properly. I
removed the
I'd like to discuss the possibility of Maven automatically looking for a
project specific settings.xml file [1]. The main use case for this is
to eliminate, or at least reduce, the need to add repositories to the
poms. A setting.xml file could simply be added into scm into the root
directory of
hasn't that been the purpose of profiles.xml files back in 2.x before
it was removed for 3.x?
Milos
On Mon, Aug 1, 2011 at 9:00 PM, Paul Gier pg...@redhat.com wrote:
I'd like to discuss the possibility of Maven automatically looking for a
project specific settings.xml file [1]. The main use
What is the point of putting a settings.xml in your SCM next to your pom.xml?
In this case just add the repos in the root pom.
++
Julien
- Mail original -
De : Milos Kleint mkle...@gmail.com
À : Maven Developers List dev@maven.apache.org
Cc :
Envoyé le : Lundi 1 Août 2011 21h02
Hi,
We should use the Editable Email Notification instead of the E-mail
Notification . The default one is very badly done for Maven projects and
will spam you for each errorneous/fixed module. The Editable is more
powerful and will notify you only once per job.
FYI, the Jenkins team was
On 2011-08-01 20:06, Brett Porter wrote:
On 02/08/2011, at 4:03 AM, Brett Porter wrote:
I suspected this was a problem with the length of the path. Seems to be
working after wiping out the working copy, in case anyone else stumbles onto
it.
The next problem was the -Dmaven.home
Using a project local settings allows you to use the repo during build,
but still have a clean pom in the repo when you release. We've
experienced a lot of problems related to repos in the poms.
On 08/01/2011 02:16 PM, Julien HENRY wrote:
What is the point of putting a settings.xml in your SCM
I guess one really nice effect of this would allow you to define a
certain internal-only environment for project developers to use, that
won't pollute the POM once it's in the remote repository...
But what about people checking out your project and trying to build it
if they don't have access
I have several alternative design ideas.
0) If you religiously use a repository manager and mirrorOf *, you
can prevent this rogues from bothering you.
1) How about if the release / deploy process had an option to remove
repositories from the POM?
2) Let's design and implement basic repository
On 08/01/2011 03:09 PM, Benson Margulies wrote:
I have several alternative design ideas.
0) If you religiously use a repository manager and mirrorOf *, you
can prevent this rogues from bothering you.
This only works when all the projects you work on use the same mirror
settings. For me,
The issue to remove profiles.xml was MNG-4060[1] but it doesn't tell the
reason.One of the comments contains a link to a thread I started when I
discovered this removal.(man, that's already more than two years ago...)It
should give some more background. -Robert
Hi
I've done some testing, and as far as site generation all is well.
Unfortunately site:stage-deploy deploys the site to the wrong place.
This is the same issue I saw when releasing, and staging the site for,
Maven Site Plugin 2.3.
Here's what I get when doing 'mvn clean site:site site:deploy'
Greetings,
2011/8/1 Arnaud Héritier aherit...@gmail.com:
FYI, the Jenkins team was working recently into merging a part of the
Editable Email feature into the default one.
This is mostly captured and available via [1] and [2]. While not
strictly related, [3] is quite interesting for people
A bit late, it might arrive after the mail of the release, but anyway:
+1 for me too, just tested it on our main multimodule project.
Thanks for the work, Stephen.
2011/7/29 Lukas Theussl ltheu...@apache.org
+1
-Lukas
On 07/28/2011 04:56 PM, Stephen Connolly wrote:
Hi,
This is a
Dennis Lundberg wrote:
Hi
I've done some testing, and as far as site generation all is well.
Unfortunately site:stage-deploy deploys the site to the wrong place.
This is the same issue I saw when releasing, and staging the site for,
Maven Site Plugin 2.3.
Here's what I get when doing 'mvn
23 matches
Mail list logo
