On May 1, 2008, at 1:15 AM, Ralph Goers wrote:
The better question is what will it take to get the patches applied?
I took a glance at 3559 and nothing jumped out and bit me.
Well, that's obviously in the back of my mind, but I didn't want to
jump onto the dev list as a newbie and start hol
The better question is what will it take to get the patches applied? I
took a glance at 3559 and nothing jumped out and bit me. However, I'd
like other feedback, plus I'd be hesitant to apply it without the patch
having a test case included to verify the fix. I don't have the
bandwidth right no
I'm fine with the warning, you convinced me.
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 30, 2008 2:22 PM
To: Maven Developers List
Subject: Re: POM Element for Source File Encoding
> I agree and we can do this for 2.1. We can't break the existing
Never mind, for some reason I was expecting to see
MavenProject.getTestCompileClasspathElements(), and it took a while to
find MavenProject.getTestClasspathElements().
On Apr 30, 2008, at 1:42 PM, Joshua ChaitinPollak wrote:
Hi,
When stepping through Maven with a debugger, I can't seem to
> I agree and we can do this for 2.1. We can't break the existing contract
> which can potentially screw a lot of people.
No one is proposing changing things for 2.0. If no encoding is
declared, it will use the system default, as it has always done.
We're just talking about INFO vs WARNING for in
On 30-Apr-08, at 11:02 AM, Wayne Fay wrote:
This idea with the warning was also proposed by two or three users
on the
list, especially Hervé put it nicely [0]. I took this happily up
because I
(still) believe that having builds out there which implicitly rely
on the
platform encoding and
> This idea with the warning was also proposed by two or three users on the
> list, especially Hervé put it nicely [0]. I took this happily up because I
> (still) believe that having builds out there which implicitly rely on the
> platform encoding and as such just break with the ideals of
> platfo
Hi,
When stepping through Maven with a debugger, I can't seem to figure
out how the test classpathElements object is constructed.
The patch I submitted to this bug:
http://jira.codehaus.org/browse/MNG-3559
Works fine when moduleC's test scope only depends on moduleA's test-
jar, but if I a
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 that doesn't care isn't a great
>I would like to start adopting the plugin sources to
>- have their encoding parameter default to null, meaning platform encoding
> as before
Yep.
>- output a warning message if the encoding is unspecified
Is a warning really needed? Perhaps just an INFO that says "using platform
default encod
Brian E. Fox wrote:
I'd say based on the various points brought up by the users that platform
encoding as the default makes the most sense.
Yes, that's the majority's sense. I counted roughly but so far the ratio of
votes is about 3:1 for keeping platform encoding as default vs. Latin-1,
takin
as for standard versioning in this case, its never going to see the
light of day outside your organization so whatever is fine..fwiw I
think maven-2.0.9-kiva-1 is fine.
jesse
On Wed, Apr 30, 2008 at 9:27 AM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> Change all the 2.0.9's you find in there...ther
Change all the 2.0.9's you find in there...there is also a property in
the root pom that has 2.0.9.
-Original Message-
From: Luke Patterson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 30, 2008 10:20 AM
To: Maven Developers List
Subject: Re: How to build custom inhouse maven release?
I'd like to know too. I'm also using a custom version.
I am waiting on:
http://jira.codehaus.org/browse/MNG-3380
On 4/30/08, Joshua ChaitinPollak <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I just submitted a patch for this bug:
>
> http://jira.codehaus.org/browse/MNG-3559
>
> I don't know if it
Hello,
I just submitted a patch for this bug:
http://jira.codehaus.org/browse/MNG-3559
I don't know if it is the 'correct' fix, but it does the job for my
issue.
Unfortunately, I can't want for a new Maven release, so I need to
build an in-house version with this patch to deploy to my dev
I've been following the responses on the user list. I'd say based on the
various points brought up by the users that platform encoding as the default
makes the most sense. Most people aren't having issues with this currently and
teams that are dealing with encoding issues across their developers
Great,
Count on me for flexbuilder support.
VELO
On Wed, Apr 30, 2008 at 10:58 AM, Arnaud HERITIER <[EMAIL PROTECTED]>
wrote:
> both of them.
> If you specify your workspace location, the plugin will try to auto-detect
> your features plugins and if it find contributors compatible with them it
both of them.
If you specify your workspace location, the plugin will try to auto-detect
your features plugins and if it find contributors compatible with them it
will generate appropriate settings.
If not, you'll have to specify them (like is actually with properties like
wtpversion or custom goal
Question:
The extensions, will auto-actived according with installed eclipse (don't
like this idea) or I will declared on pom.xml my extensions?
VELO
On Wed, Apr 30, 2008 at 10:45 AM, nicolas de loof <[EMAIL PROTECTED]>
wrote:
> I've created an inital proposal for this on wiki :
>
>
> http://do
I've created an inital proposal for this on wiki :
http://docs.codehaus.org/display/MAVEN/Eclipse+plugin+refactored+for+extensibility
2008/4/24 VELO <[EMAIL PROTECTED]>:
> Flex / Flex builder
>
> I created a flexbuilder-mojo, who inherit from maven-eclipse-plugin
>
> If this goes on, I can cre
2008/4/30 Mark Hobson <[EMAIL PROTECTED]>:
> Hi Olivier,
>
> 2008/4/30 Olivier Lamy <[EMAIL PROTECTED]>:
>
> > Hi,
> > This component is very helpfull.
> > But I can't build it with jdk 1.4
> >
> > [INFO] Compilation failure
> >
> /local/olamy/open-source/maven-svn/tags/maven-runtime-1.0
Hi Olivier,
2008/4/30 Olivier Lamy <[EMAIL PROTECTED]>:
> Hi,
> This component is very helpfull.
> But I can't build it with jdk 1.4
>
> [INFO] Compilation failure
>
> /local/olamy/open-source/maven-svn/tags/maven-runtime-1.0-alpha-1/src/test/java/org/apache/maven/shared/runtime/MavenRuntimeV
Hi,
This component is very helpfull.
But I can't build it with jdk 1.4
[INFO] Compilation failure
/local/olamy/open-source/maven-svn/tags/maven-runtime-1.0-alpha-1/src/test/java/org/apache/maven/shared/runtime/MavenRuntimeVisitorUtilsTest.java:[29,-1]
cannot access org.easymock.EasyMock
bad class
23 matches
Mail list logo