Brett Porter wrote:
I thought I had commented on this at some point, but I don't really remember.
You're plan of action sounds correct if there's no way around it. You might
however look into the changes John made in 2.0.9 to separate CLI properties
from existing system properties - maybe we
I thought I had commented on this at some point, but I don't really
remember.
You're plan of action sounds correct if there's no way around it. You
might however look into the changes John made in 2.0.9 to separate CLI
properties from existing system properties - maybe we can just support
The sad tale of SUREFIRE-491 began when I tried to fix SUREFIRE-121.
http://jira.codehaus.org/browse/SUREFIRE-491
http://jira.codehaus.org/browse/SUREFIRE-121
The request seemed innocent enough. Wouldn't it be cool if you could pass
system properties to your tests, like this?
mvn clean te
Issue Subscription
Filter: Design & Best Practices (29 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-3313NetBeans projects, more than ant project, more than fre
What's the impact to existing builds. My initial reaction is no-way in 2.0.x.
-Original Message-
From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 01, 2008 4:07 PM
To: Maven Developers List
Subject: Artifact Version Comparison
Kenney started a proposal http://docs.codehau
On 1-May-08, at 1:07 PM, Hervé BOUTEMY wrote:
Kenney started a proposal http://docs.codehaus.org/display/MAVEN/Versioning
with a implementation of a comparator.
I took his implementation, updated it to support comparison between
more
version schemes and integrated it to DefaultArtifactVersio
That's way too much magic. I'd rather have an explicit
true\false flag.
dependency:analyze could check this if desired.
On Wed, Apr 30, 2008 at 4:31 AM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> It seems like we would need an ASM based post processor to analyze it before
> generating the pom that
On Mittwoch, 30. April 2008, William Ferguson wrote:
> As Benjamin points out at the end of that Jira, the current behaviour is
there to deal with use of libraries containing classes that extend classes in
other libraries.
>
> Seems to me that we need a way to differentiate in our projects which
> The JBoss Product Versioning [0] suggests the following additional
> well-known qualifiers:
> - CR
> - FINAL
How is CR different from RC? One is Candidate Release, the other is
Release Candidate. I think I'd pick one and forget about the other.
Wayne
---
Hervé BOUTEMY wrote:
Kenney started a proposal
http://docs.codehaus.org/display/MAVEN/Versioning
with a implementation of a comparator.
The JBoss Product Versioning [0] suggests the following additional
well-known qualifiers:
- CR
- FINAL
Benjamin
[0] http://wiki.jboss.org/wiki/JBossProduc
Kenney started a proposal http://docs.codehaus.org/display/MAVEN/Versioning
with a implementation of a comparator.
I took his implementation, updated it to support comparison between more
version schemes and integrated it to DefaultArtifactVersion class. The code
is here http://svn.apache.org/v
On 1-May-08, at 2:13 AM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
> and as such warning is most appropriate
> rather than simply info. I could be talked into accepting an info
that
> has "build not fully reproducible etc" text in it, but this is
> splitting hairs.
>
It can in no way
Yep that's all I needed. Thanks for the pointer! ;-)
w
On Thu, May 1, 2008 at 12:16 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> If what you are after, is to add extra source directories to your build,
> you should have a look at the build helper plugin:
>
> http://mojo.codehaus.org/build-he
2008/5/1 Dennis Lundberg <[EMAIL PROTECTED]>:
> That might be the case, but it's something that we need to change. I've
> written docs for some of the shared components, and the shared parent now
> includes a site.xml including the necessary navigational and presentational
> aids.
>
> In my opini
Mark Hobson wrote:
2008/4/29 Wendy Smoak <[EMAIL PROTECTED]>:
On Mon, Apr 28, 2008 at 5:40 PM, Mark Hobson <[EMAIL PROTECTED]> wrote:
> 4hrs to go.. anyone?
Does it have docs? How would I test it?
It has Javadoc but no site doc. I figured that since only a handful
of shared components ha
Dennis Lundberg wrote:
As long as there is an easy way for users to get rid of the warning, which
seems to be the case here.
Yes, simply setting the POM property ${project.build.sourceEncoding} to some
value, either XYZ or if users really want ${file.encoding}, will disable the
warning.
B
Benjamin Bentmann wrote:
Brian E. Fox wrote:
Is a warning really needed? Perhaps just an INFO that says "using
platform
default encoding: [value]". Again going under the theory that someone
that
needs to worry about the encoding will be looking for it, shoving a
warning in everyone's face tha
If what you are after, is to add extra source directories to your build,
you should have a look at the build helper plugin:
http://mojo.codehaus.org/build-helper-maven-plugin/
walid joseph Gedeon wrote:
Hello all,
After failing to customize the compiler pluging (by passing
in the maven-c
Jason van Zyl wrote:
> and as such warning is most appropriate
> rather than simply info. I could be talked into accepting an info that
> has "build not fully reproducible etc" text in it, but this is
> splitting hairs.
>
It can in no way effect what currently happens even if it's not 100%
opi
19 matches
Mail list logo
