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
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:
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
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
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 a
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 specification
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. version${maven.version}/version
Also you may want to force all one set of components to the same suite
release... so blah-core may be only available
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,
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
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
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-
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
Hi guys, I start this discussion on IRC
velohi folks, I'm planning add support on
maven-integration-test-helper to emma http://emma.sourceforge.net/
veloso I will be able to run IT tests on flex-mojos and get code
coverage results
veloit will be done using offline instrumentation
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
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
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
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
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
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
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
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
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:
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 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
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
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.
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
Would it require a lot changes to make this more in line with the
syntax[1] used by Maven Archiver?
manifestEntries
keyvalue/key
/manifestEntries
[1] http://maven.apache.org/shared/maven-archiver/
[EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Thu Jul 17 13:59:51 2008
New Revision:
Jason van Zyl wrote:
Author: jvanzyl
Date: Thu Jul 17 13:48:21 2008
New Revision: 677718
URL: http://svn.apache.org/viewvc?rev=677718view=rev
Log:
MSHADE-39: add a resource transformer that takes care of MANIFEST.MF files
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?
manifestEntries
keyvalue/key
/manifestEntries
[1]
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=677718view=rev
Log:
MSHADE-39: add a resource transformer that takes care of
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
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
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.
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
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.
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
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
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
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
+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:
41 matches
Mail list logo
