Vincent Siveton wrote:
I tried to fix the IT since Hudson was unhappy. I specified svn
properties for UTF-16 file.
Vincent, I reverted part of your changes: In principle, the encoding of
the Java sources (input) and the HTML pages (output) is independent.
Also, the IT doesn't compile the
+1
-Lukas
Jason van Zyl wrote:
Hi,
Shane has been been working on NMaven for a couple years now, he's
worked on the new maven-toolchain, has recently done a huge amount of
work on cleaning up the project builder in the sandbox, and has some
PGP tools that he would like to contribute.
+1
-Lukas
Vincent Siveton wrote:
Hi,
We solved less than 70 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142styleName=Htmlversion=12621
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11142status=1
+1
--
Olivier
2008/7/25 Vincent Siveton [EMAIL PROTECTED]:
Hi,
We solved less than 70 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142styleName=Htmlversion=12621
There are still a couple of issues left in JIRA:
Ping.. can anyone share some insight on this please?
Mark
2008/7/22 Mark Hobson [EMAIL PROTECTED]:
Hi there,
I've encountered an issue with the scope resolution for nearest test
and farthest provided scenario. Consider the following projects:
a - commons-lang
b - commons-lang
c
AFAIK, provided is not transitive, so a provided dependency is assumed to be
provided by any consumer of b
On Mon, Jul 28, 2008 at 10:48 AM, Mark Hobson [EMAIL PROTECTED] wrote:
Ping.. can anyone share some insight on this please?
Mark
2008/7/22 Mark Hobson [EMAIL PROTECTED]:
Hi there,
Hi,
This may sound silly but I can't get this to work:
parent
groupIdch.globus/groupId
artifactIdglobus-parent-pom/artifactId
version${version.globus-parent-pom}/version
/parent
I tried to define the property via settings.xml,
Thanks Benjamin to take care of this.
Unfortunately, Huson is always unhappy...
Cheers,
Vincent
http://ci.sonatype.org/job/Maven-Plugins/org.apache.maven.plugins$maven-javadoc-plugin/112/changes
2008/7/28 Benjamin Bentmann [EMAIL PROTECTED]:
Vincent Siveton wrote:
I tried to fix the IT
The vote has passed with the following votes:
+1 Fabrice, Hervé, Lukas, Olivier, Vincent
I'll move the artifacts over.
Cheers,
Vincent
2008/7/25 Vincent Siveton [EMAIL PROTECTED]:
Hi,
We solved less than 70 issues:
Vincent Siveton wrote:
Unfortunately, Huson is always unhappy...
Yep, but this time it left us some nice debug infos [0]: The generated
options file specifies -charset 'ISO-8859-1' but misses
docencoding. This is an indication that the IT build is using an
outdated version of the plugin
It is currently working as designed. Maven won't resolve properties for
any of the items in the parent section. The pom below would be a problem
if it was actually installed into a repository as it would require that
the property be specified even if the artifact was a transitive dependency.
The separate builds are using separate local repos. Everything should
be built and deployed to nexus so that should have the latest
Sent from my iPhone
On Jul 28, 2008, at 8:02 AM, Benjamin Bentmann [EMAIL PROTECTED]
wrote:
Vincent Siveton wrote:
Unfortunately, Huson is always
Quoting Ralph Goers [EMAIL PROTECTED]:
It is currently working as designed. Maven won't resolve properties for
any of the items in the parent section. The pom below would be a
problem if it was actually installed into a repository as it would
require that the property be specified even if the
2008/7/28 Stephen Connolly [EMAIL PROTECTED]:
AFAIK, provided is not transitive, so a provided dependency is assumed to be
provided by any consumer of b
You're right that provided is not transitive, although this example
relates to scope resolution which occurs when an artifacts has two
Brian Fox wrote:
The separate builds are using separate local repos. Everything should be
built and deployed to nexus so that should have the latest
Hm, not sure I understand you correctly. The log file of the first IT
build [0] reads
[INFO] snapshot
The URL
http://localhost:8081/content/groups/public
is the Nexus facade for central, isn't it? I mean it looks like it's
neither using the artifact from the plugin's IT repo nor from the local
repo of the Hudson job but getting it from remote which is not
intended.
This is a logical grouping of
I think moving back to -beta-2 will be much less risky. We can try again
for -beta-3 in 2.0.11 or when it's ready.
-john
Brett Porter wrote:
Hi John,
Unfortunately, I've found that HTTP proxies don't work. I added an
integration test which passes on 2.0.9. I've already fixed the problem
on
Dear Developers,
I have a problem using maven. I tried
to build a Web project with maven installed on linux environment, but
fails. The problem is that the resource files(*.properties, *.xml,
*.xsd, *.txt) are not copied in the target directory, and so they are
not part of the output ear file.
Brian E. Fox wrote:
The URL
http://localhost:8081/content/groups/public
is the Nexus facade for central, isn't it?
This is a logical grouping of all the repos on there, including the
snapshot repo that everything is deployed to.
OK, thanks!
Benjamin
On Mon, Jul 28, 2008 at 2:23 PM, Aaron Digulla [EMAIL PROTECTED] wrote:
Quoting Ralph Goers [EMAIL PROTECTED]:
It is currently working as designed. Maven won't resolve properties for
any of the items in the parent section. The pom below would be a
problem if it was actually installed into a
On 29/07/2008, at 12:40 AM, John Casey wrote:
I think moving back to -beta-2 will be much less risky. We can try
again for -beta-3 in 2.0.11 or when it's ready.
I'll leave it up to you. I still think it is worth the upgrade, if
only to get proper scp group permission setting available
Do we have a list of exactly what would have to be rolled back?
Brett Porter wrote:
On 29/07/2008, at 12:40 AM, John Casey wrote:
I think moving back to -beta-2 will be much less risky. We can try
again for -beta-3 in 2.0.11 or when it's ready.
I'll leave it up to you. I still think it is
Quoting Stephen Connolly [EMAIL PROTECTED]:
What is the most simple way to include common dependencies, plugin configs
and properties in many POMs?
[...]
please vote for http://jira.codehaus.org/browse/MOJO-1178
This has a goal called update-parent that will update the parent version in
the
What really concerns me is that this release has been in the wild for
quite awhile now, and this issue is just coming to light. Plenty of
people use proxies, so it's not like it's that shady a corner of the
implementation.
I guess what I'm getting at is I wonder if the test suite for wagon is
I don't think the speed with with beta-3 and beta-4 were done are in
sync with the rigor that's been going into the 2.0.x releases.
I think beta-2 should have been cut as 1.0 and then moved one. Applied
real bug fixes but we did a bunch of things to the API and sweep
changes to
Same here. I think that before we go ahead and put out beta-4, we should
have significant coverage in Maven Its to capture the integration. Since
the .10 is on a branch, you can put out a snapshot of beta-4, bump the
.11 branch to use it and add some Its that cover everything like proxies
etc. I
I tested RC3 on several projects with success.
Note : I don't use http proxy in this environment
cheers
Arnaud
On Fri, Jul 25, 2008 at 11:20 PM, John Casey [EMAIL PROTECTED] wrote:
Hi again,
We've solved all of the issues brought up in response to the 2.0.10-RC2
release candidate, minus
On 28-Jul-08, at 9:04 AM, Jason van Zyl wrote:
I don't think the speed with with beta-3 and beta-4 were done are in
sync with the rigor that's been going into the 2.0.x releases.
Sorry, switched timezones and without coffee. Let me say that again:
I don't think the speed with which
On 28-Jul-08, at 9:09 AM, Arnaud HERITIER wrote:
I tested RC3 on several projects with success.
Note : I don't use http proxy in this environment
Right, changing the functionality of something the vast majority of
people don't use logically means that demographic gets nailed. I think
the trick at this point is to figure out what rolling back to -beta-2
will undo in terms of our JIRA count for the release, and where the
associated code is. I'll get started on this today.
-john
Jason van Zyl wrote:
On 28-Jul-08, at 9:04 AM, Jason van Zyl wrote:
I don't think the speed
(reposted from issues@ once I realized that was for the issue tracker,
sorry about that)
Hi, I'm using 2.0-beta-7 of the maven release plugin, but I could
really use the new support for accepting releaseVersion,
developmentVersion, etc... from -D properties.
Is the release of 2.0-beta-8
I confirm everything is ok :)
thanks for your help, guys
Hervé
Le lundi 28 juillet 2008, Benjamin Bentmann a écrit :
Brian E. Fox wrote:
The URL
http://localhost:8081/content/groups/public
is the Nexus facade for central, isn't it?
This is a logical grouping of all the repos on
you can use -DparentVersion=[1.3.4]
to force a specific version and it rewrites the pom without changing
any formatting or comments
Sent from my iPod
On 28 Jul 2008, at 16:51, Aaron Digulla [EMAIL PROTECTED] wrote:
Quoting Stephen Connolly [EMAIL PROTECTED]:
What is the most simple way
Hi,
It seems like nexus index of central has not been updated since 2008-07-03.
See http://repo1.maven.org/maven2/.index/
File rotation is done weekly, but file content hasn't changed:
#Thu Jul 03 12:09:13 CDT 2008
nexus.index.time=20080703120913.652 -0500
nexus.index.id=central
How is this
Hi
I think that we need to change the setup in Hudson for Maven Plugins.
Currently there is a job [1] called Maven-Plugins which has a large
number of plugins as Modules. This has benefits and drawbacks.
Benefits:
+ Only one configuration is needed per job, I think, totaling 1 in this
case.
I'll check the cron job, it should be done weekly.
On 28-Jul-08, at 2:21 PM, Hervé BOUTEMY wrote:
Hi,
It seems like nexus index of central has not been updated since
2008-07-03.
See http://repo1.maven.org/maven2/.index/
File rotation is done weekly, but file content hasn't changed:
#Thu
On 28-Jul-08, at 3:42 PM, Dennis Lundberg wrote:
Hi
I think that we need to change the setup in Hudson for Maven
Plugins. Currently there is a job [1] called Maven-Plugins which
has a large number of plugins as Modules. This has benefits and
drawbacks.
Benefits:
+ Only one
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11310styleName=Htmlversion=13182
There are just one issue left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11310status=1
Staging repo:
Hi everyone (and maybe especially Brett),
I took some time today and rolled back the 2.0.10-RC branch to using
1.0-beta-2 of wagon, including the user-agent changes. I also tried to
enable (and make work) the IT for MNG-3599 using wagon 1.0-beta-2 and
wagon-webdav (instead of the jackrabbit
FWIW, I'm attaching the diff of the code/config I changed to try
enabling the IT in question. I don't like the idea of enabling this
stuff without knowing more about it.
-john
John Casey wrote:
Hi everyone (and maybe especially Brett),
I took some time today and rolled back the 2.0.10-RC
It is cron'd, but the property file was not being overwritten. Fixed
and updated.
On 28-Jul-08, at 4:27 PM, Jason van Zyl wrote:
I'll check the cron job, it should be done weekly.
On 28-Jul-08, at 2:21 PM, Hervé BOUTEMY wrote:
Hi,
It seems like nexus index of central has not been updated
DAV-with-proxy was broken in 2.0.9, which is why MNG-3599 is still open.
The test case has a condition in it to check that it's running on
2.0.10 for the second part - you should bump that to 2.0.11 if you are
going to rollback. No other changes should be needed. Keep the test
included
On 29/07/2008, at 11:19 AM, Brett Porter wrote:
DAV-with-proxy was broken in 2.0.9, which is why MNG-3599 is still
open.
The test case has a condition in it to check that it's running on
2.0.10 for the second part - you should bump that to 2.0.11 if you
are going to rollback. No other
On 29/07/2008, at 2:05 AM, Brian E. Fox wrote:
Same here. I think that before we go ahead and put out beta-4, we
should
have significant coverage in Maven Its to capture the integration.
I had already added a number of tests over recent times related to
this. The touch points with Maven
I understand the concerns, but let me try and explain where I'm coming
from.
On 29/07/2008, at 1:58 AM, John Casey wrote:
What really concerns me is that this release has been in the wild
for quite awhile now, and this issue is just coming to light. Plenty
of people use proxies, so it's
Sorry for not answering sooner. I was travelling today. Comments are below.
Aaron Digulla wrote:
Quoting Ralph Goers [EMAIL PROTECTED]:
It is currently working as designed. Maven won't resolve properties for
any of the items in the parent section. The pom below would be a
problem if it was
46 matches
Mail list logo
