On 08/09/2007, at 10:52 AM, Jason van Zyl wrote:
I want to take the aggregate uber jar in 2.0.x and start comparing
it with with the uber jar for 2.1.x.
Anyone have a preference for JarDiff or Clirr and have a good setup
for it?
I've been happy with clirr when I've used it, and the check
On 7 Sep 07, at 5:43 PM 7 Sep 07, Brett Porter wrote:
On 08/09/2007, at 10:37 AM, Jason van Zyl wrote:
On 7 Sep 07, at 5:16 PM 7 Sep 07, Brett Porter wrote:
file:// ?
I also know of some wagon-scm + SVN uses (though they could
download over HTTP).
Right, deployment is a different s
I want to take the aggregate uber jar in 2.0.x and start comparing it
with with the uber jar for 2.1.x.
Anyone have a preference for JarDiff or Clirr and have a good setup
for it?
I would like to set this up to catch anything. I can be rather
radical in refactoring but I think that's fine
On 7 Sep 07, at 5:20 PM 7 Sep 07, Brian E. Fox wrote:
I don't currently, but have in the past used file:// for remote.
For deploying or actually pulling? Deploying is a totally different
story. I know tons of people who use file, dav, scp, and ftp.
Strictly for pulling I'm saying. And I'
On 08/09/2007, at 10:37 AM, Jason van Zyl wrote:
On 7 Sep 07, at 5:16 PM 7 Sep 07, Brett Porter wrote:
file:// ?
I also know of some wagon-scm + SVN uses (though they could
download over HTTP).
Right, deployment is a different story. I use the wagon-scm stuff
for audit trail and dep
On 7 Sep 07, at 5:16 PM 7 Sep 07, Brett Porter wrote:
file:// ?
I also know of some wagon-scm + SVN uses (though they could
download over HTTP).
Right, deployment is a different story. I use the wagon-scm stuff for
audit trail and deploy there. I'm talking strictly about pulling.
I'd
On 7 Sep 07, at 5:03 PM 7 Sep 07, Brett Porter wrote:
On 08/09/2007, at 12:24 AM, Jason van Zyl wrote:
On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote:
Just curious - will there be any issues with these APIs changing
for plugins that may have come to rely on it, or are these all
I think it's also a reasonable goal to allow people to use projects
that refer to embedded remote repositories to build...that way, the
build is totally self-contained. This is one of the things that the
assembly plugin tries to do with its section (though
it doesn't work very well so far.
I don't currently, but have in the past used file:// for remote.
The use case was that we had to mirror our internal repo to another corp
network. We essentially zipped up the repo and transferred it to their
machine (regularly and automatically via scm), which set a mirror entry
pointing to the
file:// ?
I also know of some wagon-scm + SVN uses (though they could download
over HTTP).
I'd be hesitant to remove this without doing some decent polling of
users (and probably a deprecation cycle).
- Brett
On 08/09/2007, at 8:55 AM, Jason van Zyl wrote:
After thinking about Greg's co
Also, I'm not prepared to release 2.3.1 until the things that have
regressed since previous releases are fixed.
I keep working on it when I have spare time - others are welcome and
we just got a new volunteer last week...
On 08/09/2007, at 2:06 AM, Carlos Sanchez wrote:
the changelog is e
If it works with 2.0.7, I think that's ok.
On 07/09/2007, at 8:59 PM, Johan Kindgren wrote:
Hi
I've fixed the mjar-30 and possibly the mjar-80 (by accident), and
while I was at it I created a couple of integrationtests using the
maven-embedder.
I could not get the embedder to run without upgra
urg, sorry. I see you already started a separate thread on this.
Please ignore me.
On 08/09/2007, at 10:03 AM, Brett Porter wrote:
On 08/09/2007, at 12:24 AM, Jason van Zyl wrote:
On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote:
Just curious - will there be any issues with these AP
On 08/09/2007, at 12:24 AM, Jason van Zyl wrote:
On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote:
Just curious - will there be any issues with these APIs changing
for plugins that may have come to rely on it, or are these all
purely internal? (I haven't had a chance to dig through t
On 08/09/2007, at 12:25 AM, Jason van Zyl wrote:
On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote:
I guess you're out for the night now... anyway, until we get the
direct nag happening I'll just pass it on :)
I just checked again, no changes for me locally, bootstrapped again
and
If anyone else is going to be working on 2.1 over the weekend then I
will work on a branch, otherwise I will continue tracking down the
release plugin problem, starting the error reporting based on
feedback of what can go wrong, and documenting the front-end
populating of the execution requ
Results:
+12 Brian, Stephane, Emmanuel, Vincent, Fabrice, Maria, Raphael, Lukas,
Olivier, Jason vZ, Arnaud, Brett
This vote has passed. Jason, since Mauro is already an Apache committer,
I believe only granting of Karma is required.
Please join me in welcoming Mauro!
--Brian
-Original Messag
Results:
+7 (Binding) Brian, Jason, Brett, Stephane, Lukas, Dennis, Arnaud
+2 (Non Binding) Rafale, Andy,
This vote has passed. I will wrap up the move most likely over the
weekend. It will first go to the sandbox where we will perform the
refactoring of packages and to include apache headers.
Si
On 7 Sep 07, at 3:46 PM 7 Sep 07, John Casey wrote:
Hell, I'd settle for being able to bootstrap at all.
It's really not cool to respond that CI is broken and not respond
at all to someone saying the build breaks on their machine
I have 4 machines going, I'm not trying to intentionally bre
I thought we'd all agreed to use branches as a measure for preserving
stability in the trunk as much as was reasonable. This was awhile
back, but I'm sure I can find that thread if I need to.
FWIW, major refactorings are no different from new features in my
book, and if the tables had been
On 7 Sep 07, at 3:52 PM 7 Sep 07, John Casey wrote:
I thought we'd agreed awhile back to do this, but apparently that's
not the case.
For big features sure. I wasn't adding any new features. I'm getting
rid of the ton of crap lying around to prepare for more people being
able to unders
On 7 Sep 07, at 3:48 PM 7 Sep 07, Vincent Siveton wrote:
Hi,
I noticed that we have two artifactId with the same name, ie doxia-
site:
* doxia/doxia-sitetools/trunk/pom.xml [1]
* doxia/site/pom.xml [2]
I proposed to rename the first one in doxia-sitetools. WDYT?
+1
Cheers,
Vincent
After thinking about Greg's comments I think it would be interesting
to ask people who actually uses anything but HTTP repositories for
consumption?
Deployment is a totally different story, but to radically simplify
the core what if we only allowed HTTP repositories for consumption in
2.1
I thought we'd agreed awhile back to do this, but apparently that's
not the case.
When I updated from Subversion today, I got a nasty surprise. Lo and
behold, it would not bootstrap! I didn't find much discussion on the
dev list about a massive reorganization (none, in fact), and the
numb
Hi,
I noticed that we have two artifactId with the same name, ie doxia-site:
* doxia/doxia-sitetools/trunk/pom.xml [1]
* doxia/site/pom.xml [2]
I proposed to rename the first one in doxia-sitetools. WDYT?
Cheers,
Vincent
[1] http://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/trunk/pom
Hell, I'd settle for being able to bootstrap at all.
It's really not cool to respond that CI is broken and not respond at
all to someone saying the build breaks on their machine...without
even taking more time trying to replicate their results. This has put
a HUGE crimp in my own plans for
On 7 Sep 07, at 2:20 PM 7 Sep 07, Paul Gier wrote:
Jason van Zyl wrote:
On 7 Sep 07, at 9:43 AM 7 Sep 07, Paul Gier wrote:
Hi Everyone,
I noticed that transitive dependencies seem to precede direct
dependencies on the test classpath. I created this issue related
to this:
http://jira.c
Jason van Zyl wrote:
On 7 Sep 07, at 9:43 AM 7 Sep 07, Paul Gier wrote:
Hi Everyone,
I noticed that transitive dependencies seem to precede direct
dependencies on the test classpath. I created this issue related to
this:
http://jira.codehaus.org/browse/MNG-3197
Is this behaviour by desi
On 7 Sep 07, at 1:58 PM 7 Sep 07, [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Fri Sep 7 13:58:21 2007
New Revision: 573699
URL: http://svn.apache.org/viewvc?rev=573699&view=rev
Log:
Fixing core-it-plugins so they won't bomb on surefire:test with NPE
if there is nothing under src/test/jav
I started testing many of our standard plugins and we have more then
a few problems. So don't be alarmed if you bootstrap and try to run
things like the release plugin, or the site plugin because they won't
work. I'm making a compatibility layer and tracking down problems
this weekend to st
Mark, can you merge your changes into the trunk of maven-artifact?
I'm willing to try them out with 2.1.x.
If we can work in tandem there to validate and test that would be
great. Thanks for taking the time to test 2.0.x. I really, really
hope we can get this to work as it means that people
On 7 Sep 07, at 9:43 AM 7 Sep 07, Paul Gier wrote:
Hi Everyone,
I noticed that transitive dependencies seem to precede direct
dependencies on the test classpath. I created this issue related
to this:
http://jira.codehaus.org/browse/MNG-3197
Is this behaviour by design?
No. This is no
On 7 Sep 07, at 9:31 AM 7 Sep 07, Paul Gier wrote:
I submitted a small patch for this issue:
http://jira.codehaus.org/browse/MNG-3150
The basic idea of it is to be able to use alternate pom.xml files
in a multi-module project. Can someone with commit access take a
look at this? It would
I submitted a small patch for this issue:
http://jira.codehaus.org/browse/MNG-3150
The basic idea of it is to be able to use alternate pom.xml files in a
multi-module project. Can someone with commit access take a look at this? It
would really help with some of our projects if this can be add
Hi Everyone,
I noticed that transitive dependencies seem to precede direct dependencies on
the test classpath. I created this issue related to this:
http://jira.codehaus.org/browse/MNG-3197
Is this behaviour by design? In the current maven, this means that if there is
an older version of o
the changelog is easy to see in jira
ie
http://jira.codehaus.org/browse/SUREFIRE?report=com.atlassian.jira.plugin.system.project:roadmap-panel
it's not a problem of tracking the changes but to say out loud "hey,
release the plugin!"
On 9/7/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
> > If yo
> If you have ideas on how we can do this better, we're all ears.
I've noticed from the hudson way (but maybe this is the wrong way) that they
put a release when 2 or 3 bugs have been fixed.
As maven provides SNAPSHOT support this seems not required to release a
plugin to allow users to get the
Ok, I'll prepare to release this on Monday and then we will have all
release goodies in the set of goods required for ITs. But I'll go
check and see if anything else needs to be released.
On 6 Sep 07, at 11:17 PM 6 Sep 07, Jason van Zyl wrote:
Hi,
I would like to release the maven-verifier
+1
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, September 07, 2007 2:17 AM
To: Maven Developers List
Subject: [vote] release maven-verifier 1.1
Hi,
I would like to release the maven-verifier as it's used as part of
Maven's integration tests and would
On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote:
I guess you're out for the night now... anyway, until we get the
direct nag happening I'll just pass it on :)
I just checked again, no changes for me locally, bootstrapped again
and ran the ITs and it's all fine so we have a discrepan
+1
On 7 Sep 2007, at 07:17, Jason van Zyl wrote:
Hi,
I would like to release the maven-verifier as it's used as part of
Maven's integration tests and would like to stop using the snapshot
in order to prepare for the 2.1-alpha-1.
The staging area is here:
http://people.apache.org/~jvanzy
+1
-john
On Sep 7, 2007, at 2:17 AM, Jason van Zyl wrote:
Hi,
I would like to release the maven-verifier as it's used as part of
Maven's integration tests and would like to stop using the snapshot
in order to prepare for the 2.1-alpha-1.
The staging area is here:
http://people.apache.o
On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote:
Just curious - will there be any issues with these APIs changing
for plugins that may have come to rely on it, or are these all
purely internal? (I haven't had a chance to dig through the changes
yet).
We must absolutely guarantee
I will setup Hudson on a Contegix machine and we'll have two
automated opinions.
On 7 Sep 07, at 2:19 AM 7 Sep 07, Brett Porter wrote:
I guess you're out for the night now... anyway, until we get the
direct nag happening I'll just pass it on :)
(yes, same problem in my checkout as on conti
On 7 Sep 07, at 12:02 AM 7 Sep 07, [EMAIL PROTECTED] wrote:
Author: brett
Revision: 573485
Modified property: svn:log
Modified: svn:log at Fri Sep 7 00:02:24 2007
--
--- svn:log (original)
+++ svn:log Fri Sep 7 00
On 7 Sep 07, at 6:39 AM 7 Sep 07, Mark Hobson wrote:
On 07/09/2007, Mark Hobson <[EMAIL PROTECTED]> wrote:
I started trying to get 2.0.x to use maven-artifact 3.0-SNAPSHOT. It
doesn't seem too bad - no compilation problems - currently just a
linking issue to resolve before the IT tests should
On 7 Sep 07, at 2:36 AM 7 Sep 07, Milos Kleint wrote:
can I assume this proposal is ok with everyone and start some initial
work on it?
The plan was that we collect all the proposals, and give people until
next friday. Then we decide what will be done and in what release.
If you want to
On 05/09/2007, Jörg Schaible <[EMAIL PROTECTED]> wrote:
> You mean something like this?
>
> [EMAIL PROTECTED] ~/src/Codehaus/pico/java-2.x/nano/container-bsh $ mvn
> info:deps-runtime
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'info'.
> WAGON_VERSION: 1.
On 07/09/2007, Mark Hobson <[EMAIL PROTECTED]> wrote:
> I started trying to get 2.0.x to use maven-artifact 3.0-SNAPSHOT. It
> doesn't seem too bad - no compilation problems - currently just a
> linking issue to resolve before the IT tests should hopefully pass.
The linking issue was due to maven
Vincent Siveton wrote:
Hi,
Mainly for Dennis who kindly suggests to do the release, here are some
doc issues:
* publish the site decoration descriptor XSD and the associated doc.
Actually, it is decoration-1.0.0.xsd but I would prefer to name it
decoration-1.0.0-alpha-9.xsd. WDYT?
Moreover, w
Heh, when I first read it, I thought you took the proposal and made a jira
until I saw the date ;-) Freaky.
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Friday, September 07, 2007 12:12 AM
To: Maven Developers List
Subject: Re: [proposal] "Make like" reactor
Hi
I've fixed the mjar-30 and possibly the mjar-80 (by accident), and
while I was at it I created a couple of integrationtests using the
maven-embedder.
I could not get the embedder to run without upgrading the some
dependencies (like maven-core and the maven-artifact), do you have any
general pol
On 04/09/2007, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> On 4 Sep 07, at 8:37 AM 4 Sep 07, Mark Hobson wrote:
> > I haven't had time to test it out in 2.1.x, although that FIXME needs
> > fixing first as detailed in the issue. When are you thinking of
> > releasing maven-artifact? Could be worth
Yeah, go for it - lazy consensus :)
I actually started to flip through this the other day - I'll take
another look. I also started marking JIRA issues that might be
related with [toolchain].
- Brett
On 07/09/2007, at 7:36 PM, Milos Kleint wrote:
can I assume this proposal is ok with ever
can I assume this proposal is ok with everyone and start some initial
work on it?
Milos
On 9/2/07, Milos Kleint <[EMAIL PROTECTED]> wrote:
> Hello,
>
> See: http://docs.codehaus.org/display/MAVEN/Toolchains
>
> Text included below for inline comments (which I'll feed back into
> the document as n
I guess you're out for the night now... anyway, until we get the
direct nag happening I'll just pass it on :)
(yes, same problem in my checkout as on continuum - it's doing it's
job just fine)
Just curious - will there be any issues with these APIs changing for
plugins that may have come
Jason van Zyl <[EMAIL PROTECTED]> writes:
> On 6 Sep 07, at 11:46 PM 6 Sep 07, Insitu wrote:
>
>> Jason van Zyl <[EMAIL PROTECTED]> writes:
>>
>>> Hi,
>>>
>>> I would like to release the maven-verifier as it's used as part of
>>> Maven's integration tests and would like to stop using the snapshot
+1
Stéphane
On 9/7/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would like to release the maven-verifier as it's used as part of
> Maven's integration tests and would like to stop using the snapshot
> in order to prepare for the 2.1-alpha-1.
>
> The staging area is here:
>
> http://peo
Yes :)
Though it's probably a bit dodgy as is. It really is XHTML specific -
you probably want some more general way to include in there.
The JavaScript is for Google Analytics (which btw, seems to have
broken with a recent site deploy... traffic halved suddenly 2 weeks ago)
- Brett
On 0
On 6 Sep 07, at 11:46 PM 6 Sep 07, Insitu wrote:
Jason van Zyl <[EMAIL PROTECTED]> writes:
Hi,
I would like to release the maven-verifier as it's used as part of
Maven's integration tests and would like to stop using the snapshot
in order to prepare for the 2.1-alpha-1.
The staging area is
Jason van Zyl <[EMAIL PROTECTED]> writes:
> Hi,
>
> I would like to release the maven-verifier as it's used as part of
> Maven's integration tests and would like to stop using the snapshot
> in order to prepare for the 2.1-alpha-1.
>
> The staging area is here:
>
> http://people.apache.org/~jvanzy
61 matches
Mail list logo
