+1
--jason
On Jul 18, 2008, at 8:58 AM, Oleg Gusakov wrote:
Hi,
16 issues fixed, no outstanding
Staging repo:
http://repository.sonatype.org:8081/nexus/content/repositories/staged-releases/maven-artifact/org/apache/maven/artifact/maven-artifact/3.0-alpha-1/
Staging site:
http://maven.apach
I gather this is the reason that the commits (r677787 to r677789) for
the Maven Artifact release that Oleg just called a vote on look like
they were done by Jason?
I'm really not comfortable with svn credentials being shared like that.
FWIW, Continuum lets you enter your svn credentials when you
Issue Subscription
Filter: Design & Best Practices (28 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
htt
Ralph Goers wrote:
Michael McCallum wrote:
why not just specify the dependencies with version ranges, if you do
there is no need to rewrite anything it just works...
My builds never use version ranges. We require that builds be
reproduceable at any time in the future. Version ranges d
Hi,
16 issues fixed, no outstanding
Staging repo:
http://repository.sonatype.org:8081/nexus/content/repositories/staged-releases/maven-artifact/org/apache/maven/artifact/maven-artifact/3.0-alpha-1/
Staging site:
http://maven.apache.org/ref/maven-artifact-3.0-alpha-1/
Guide to testing staged re
On 18/07/2008, at 10:11 AM, Jason van Zyl wrote:
I'll sync up with Oleg and takes the notes out of SVN and put them
in a proposal. At this point Greg, Jan, Jesse, myself, Oleg and soon
Shane will have their fingers in the pie. This is a pretty
significant effort and should be documented. I
I'll sync up with Oleg and takes the notes out of SVN and put them in
a proposal. At this point Greg, Jan, Jesse, myself, Oleg and soon
Shane will have their fingers in the pie. This is a pretty significant
effort and should be documented. It's mostly the processes and
algorithms that need
Michael McCallum wrote:
why not just specify the dependencies with version ranges, if you do there is
no need to rewrite anything it just works...
My builds never use version ranges. We require that builds be
reproduceable at any time in the future. Version ranges don't guarantee
that.
hey all,
I have been working on the jetty-client in the jetty project over in
codehaus which is the library mercury uses that is doing the
asynchronous retrieval and deployment of artifacts. Greg Wilkins and
I have recently been increasing the functionality of the jetty-client
and we are getting
I worked on it last night, I am able to reproduce it, but I haven't finished
the code yet. I will work on it some more tonight.
-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 4:54 PM
To: Maven Developers List
Subject: Re: releasing the en
There you go. Old habits die hard.
On 17-Jul-08, at 5:41 PM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
Author: jvanzyl
Date: Thu Jul 17 13:48:21 2008
New Revision: 677718
URL: http://svn.apache.org/viewvc?rev=677718&view=rev
Log:
MSHADE-39: add a resource transformer that takes care of
Sure, I can do that. Just need to rewire the configurator.
On 17-Jul-08, at 5:10 PM, Dennis Lundberg wrote:
Would it require a lot changes to make this more in line with the
syntax[1] used by Maven Archiver?
value
[1] http://maven.apache.org/shared/maven-archiver/
[EMAIL PROTECTED]
Jason van Zyl wrote:
Author: jvanzyl
Date: Thu Jul 17 13:48:21 2008
New Revision: 677718
URL: http://svn.apache.org/viewvc?rev=677718&view=rev
Log:
MSHADE-39: add a resource transformer that takes care of MANIFEST.MF files
maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/p
Would it require a lot changes to make this more in line with the
syntax[1] used by Maven Archiver?
value
[1] http://maven.apache.org/shared/maven-archiver/
[EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Thu Jul 17 13:59:51 2008
New Revision: 677723
URL: http://svn.apache.org/view
Hi Brian,
Did you find the time to solve this one ?
Arnaud
On Mon, Jul 14, 2008 at 4:53 PM, Brian E. Fox <[EMAIL PROTECTED]>
wrote:
> Thanks Herve, that looks like the problem I saw before. I'll check this out
> and get it into the Its.
>
> -Original Message-
> From: Hervé BOUTEMY [m
On 18/07/2008, at 4:55 AM, Brett Porter wrote:
On 18/07/2008, at 2:08 AM, John Casey wrote:
Found the jira: http://jira.codehaus.org/browse/MNG-3652
But is there a test to verify that it works?
No, I couldn't think of a simple way to do that a the time, but one
has occurred to me now. I
On 18/07/2008, at 2:08 AM, John Casey wrote:
Found the jira: http://jira.codehaus.org/browse/MNG-3652
But is there a test to verify that it works?
No, I couldn't think of a simple way to do that a the time, but one
has occurred to me now. I'll try and whip one up.
- Brett
Brett Porte
Found it and fixed it. Thanks for testing!
Henrique Prange wrote:
Hi John,
I've tried Maven 2.0.10-RC1 with one of my projects and got a
NullPointerException while resolving dependencies (below is the stack
trace). It works using Maven 2.0.9.
Should I file a bug on Jira with fix-for 2.0.10?
Hi John,
I've tried Maven 2.0.10-RC1 with one of my projects and got a
NullPointerException while resolving dependencies (below is the stack
trace). It works using Maven 2.0.9.
Should I file a bug on Jira with fix-for 2.0.10?
Cheers,
Henrique
hprange:pas-human-resources-model hprange$ mvn
Found the jira: http://jira.codehaus.org/browse/MNG-3652
But is there a test to verify that it works?
Brett Porter wrote:
On 16/07/2008, at 7:32 AM, [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Tue Jul 15 14:32:01 2008
New Revision: 677049
URL: http://svn.apache.org/viewvc?rev=677049&view
BTW, do we have a JIRA for this feature? What about integration tests?
I was just wondering since nothing failed as a result of rolling back to
shade-plugin v. 1.0.
-john
Brett Porter wrote:
On 16/07/2008, at 7:32 AM, [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Tue Jul 15 14:32:01 2008
On Jul 17, 2008, at 11:33 AM, Jason van Zyl wrote:
On 17-Jul-08, at 11:27 AM, Daniel Kulp wrote:
On Jul 17, 2008, at 11:23 AM, Jason van Zyl wrote:
I'll make sure, but that would work by default as if you knew the
manifest in one of your JARs had the main-class entry you wouldn't
be sp
On 17-Jul-08, at 11:27 AM, Daniel Kulp wrote:
On Jul 17, 2008, at 11:23 AM, Jason van Zyl wrote:
I'll make sure, but that would work by default as if you knew the
manifest in one of your JARs had the main-class entry you wouldn't
be specifying it in the shade plugin.
Right, but if manif
On Jul 17, 2008, at 11:23 AM, Jason van Zyl wrote:
I'll make sure, but that would work by default as if you knew the
manifest in one of your JARs had the main-class entry you wouldn't
be specifying it in the shade plugin.
Right, but if manifest entries can come from two places, we need to
Maybe I'll make the transformers like the enforcers where they are
components that can be configured.
I could see just specifying the main-class ignoring everything else,
or allowing merging or selectively looking for an artifact which
contained the MANIFEST you wanted to win.
On 17-Jul-0
I'll make sure, but that would work by default as if you knew the
manifest in one of your JARs had the main-class entry you wouldn't be
specifying it in the shade plugin.
On 17-Jul-08, at 11:17 AM, Daniel Kulp wrote:
In general, we let the stuff that executes prior to the Shade plugin
ha
In general, we let the stuff that executes prior to the Shade plugin
handle the manifest.That might be the jar plugin, but it could be
something else like the felix bundle plugin.
I guess that would be the important thing: make sure the above
scenario still works correctly.
On Jul 1
I was just thinking about wiring in the shade plugin for the
jetty-runner (starts up wars, etc from the cli) this morning and that
would definitely require this ability...trying to remember how I did
it in the past I think I just added it manually and managed the
MANIFEST.MF but that is a nasty fil
Hi guys, I start this discussion on IRC
hi folks, I'm planning add support on
maven-integration-test-helper to emma http://emma.sourceforge.net/
so I will be able to run IT tests on flex-mojos and get code
coverage results
it will be done using offline instrumentation
http://emma.sourceforge.net/i
Hi,
I was looking through JIRA and the source and there doesn't seem to be
an easy way to create an executable JAR. I don't want to add JAR
plugin configuration to set the class I want to use for "java -jar
pooky.jar".
Anyone else thought about this?
I want to add a simple configuration
OK, so... i'll give that a shot once I reformat it to the Maven code style!
On Thu, Jul 17, 2008 at 3:04 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> You would attach it to a jira at the mojo.codehaus.org project and then
> try to get some mojo committer to pick it up.
>
> -Original Message--
You would attach it to a jira at the mojo.codehaus.org project and then
try to get some mojo committer to pick it up.
-Original Message-
From: Stephen Connolly [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 10:02 AM
To: Maven Developers List
Subject: Re: How do I go about contrib
Anyway, my question is how do I go about contributing this?
On Thu, Jul 17, 2008 at 3:01 PM, Stephen Connolly
<[EMAIL PROTECTED]> wrote:
> one use case for this is when you have a suite of components and you
> want to force _all_ of them to the same version.
>
> Perhaps you have several suites of
one use case for this is when you have a suite of components and you
want to force _all_ of them to the same version.
Perhaps you have several suites of components and you want to force
all the components in each suite to the same versions across the
suite.
On Thu, Jul 17, 2008 at 2:56 PM, Stephe
And then when you want to roll a release?
Anyway, if that was the case why is it that most of the maven plugins
themselves use this pattern?
e.g. ${maven.version}
Also you may want to force all one set of components to the same suite
release... so blah-core may be only available at 1.3.5 while
b
why not just specify the dependencies with version ranges, if you do there is
no need to rewrite anything it just works...
On Fri, 18 Jul 2008 00:35:17 Stephen Connolly wrote:
>
> Oh... and if you want to prevent jumping too high in versions or too
> low, it supports adding a version specificatio
Oh and -Dproperties=blah.version,foo.version will only do the update
check for ${blah.version} and ${foo.version}
On Thu, Jul 17, 2008 at 1:35 PM, Stephen Connolly
<[EMAIL PROTECTED]> wrote:
> I have developed a plugin that makes keeping versions of related but
> not quite tightly coupled in sync
couldn't agree more. I think we'll do fine with a date filter if we
really want to know how many things broke after the first RC was cut.
I've fixed two issues since then, and we're waiting to see what happens
with the shade plugin to fix a third...not a huge list to justify a
whole new version
On 17-Jul-08, at 3:35 AM, Brett Porter wrote:
I've checked in my work so far on this. It's a pretty small and
straightforward set of changes and it works for a project using
signed artifacts and plugins. Of course, it gets very unhappy about
the distinct lack of signatures in central on mo
I have developed a plugin that makes keeping versions of related but
not quite tightly coupled in sync a lot easier.
How do I go about contributing this to mojo?
-Stephen
FYI here's how it works...
In your pom you probably have a property used to define the version in
one place, for example:
I've checked in my work so far on this. It's a pretty small and
straightforward set of changes and it works for a project using signed
artifacts and plugins. Of course, it gets very unhappy about the
distinct lack of signatures in central on most projects.
I am going to look at creating a s
41 matches
Mail list logo
