On Sat, Aug 2, 2008 at 6:48 AM, Benjamin Bentmann
<[EMAIL PROTECTED]> wrote:
> So, I assume your local POM states 2.4 as the version, right?
Perhaps when it failed during the release, but not when I was just
building the snapshot locally. Whatever you changed seems to have
fixed it, though. Tha
Hi,
This release is to prepare for the release of Maven Invoker Plugin,
which is needed by many projects.
We solved 1 issue:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=14369
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/
It's time to release the Deploy plugin.
We solved 3 issues and added 1 new feature:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13110&styleName=Text&projectId=11131&Create=Create
* [MDEPLOY-45] - Classifier not supported by deploy:deploy
* [MDEPLOY-56] - Parent version ignore
2008/8/2 Benjamin Bentmann <[EMAIL PROTECTED]>:
> Vincent Siveton wrote:
>
>> Definitely. I think each plugins should have a faq/page about encoding
>> and of course in the general site.
>
> I assume a user looking for configuration documentation is first checking
> the mojo documentation, so we sh
Vincent Siveton wrote:
Definitely. I think each plugins should have a faq/page about encoding
and of course in the general site.
I assume a user looking for configuration documentation is first
checking the mojo documentation, so we should aim at proper javadocs
directly at the mojo paramete
2008/8/2 Benjamin Bentmann <[EMAIL PROTECTED]>:
> Hervé BOUTEMY wrote:
>
>> from a user point of view, why not: it will require more code from us to
>> mimic this, but the logic seems ok for me
>
> You're right, the logic itself is not that bad. My remaining concern is the
> minimal POM where we do
Hi Benjamin,
2008/8/2 Benjamin Bentmann <[EMAIL PROTECTED]>:
> Vincent Siveton wrote:
>
>> Nope. The code passed the encoding parameter *only* if it was not empty.
>
> You're right, I forgot that the Maven JVM might be running with a different
> default encoding than the system default that would
http://jira.codehaus.org/browse/MRESOURCES-56
"use (and release) the maven-filtering component"
Stephane Nicoll wrote:
My mistake, it works with the war plugin. I think I need more coffee! The
bug is still there in the resources plugin though so we might need to
migrate it to the maven-filtering
Hervé BOUTEMY wrote:
from a user point of view, why not: it will require more code from us to mimic
this, but the logic seems ok for me
You're right, the logic itself is not that bad. My remaining concern is
the minimal POM where we don't have a fixed source encoding, causing
platform-depend
On Sat, Aug 2, 2008 at 5:36 AM, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> MWAR-133 (Filtering issue: wrong replacement of properties by values
> from MavenProject object) was mentioned when I asked about releasing
> the war plugin. It has 11 votes and there is a patch attached. Does
> anyone have
My mistake, it works with the war plugin. I think I need more coffee! The
bug is still there in the resources plugin though so we might need to
migrate it to the maven-filtering component.
Olivier, is this scheduled?
S.
On Sat, Aug 2, 2008 at 3:43 PM, Stephane Nicoll
<[EMAIL PROTECTED]>wrote:
>
Le samedi 02 août 2008, Benjamin Bentmann a écrit :
> The Javadoc plugin is currently breaking with the proposal. As a matter
> of consistency, we might need to adjust the proposal if the community
> doesn't accept it's current form. But I wonder how the alternative would
> look like? Have all repo
Wendy Smoak wrote:
Strangely, the integration test for MDEPLOY-45 is now failing for me,
complaining that it can't find maven-deploy-plugin 2.4-SNAPSHOT
[...]
I'd swear it worked initially, then
failed when I tried to release, and now it's failing just with 'mvn
install'.
So, I assume your loc
OK, it is still broken and we really need to have a look to this. I am
pretty sure we will break the backward compat if we want to have a
consistent behavior. The related issues are MRESOURCES-20 and MWAR-133. I
have an IT for MWAR-133 and it uses the maven filtering component. I will
have a look n
Dennis Lundberg wrote:
This MINVOKER-43 issue seems to be hitting a lot of our projects. Is
there something that's stopping us from releasing Maven Invoker 2.0.9
and Maven Invoker Plugin 1.2.1?
In JIRA there are only requests for new features left:
http://jira.codehaus.org/browse/MSHARED/compo
Le samedi 02 août 2008, Vincent Siveton a écrit :
> >> -docencoding "If you omit this option but use -encoding, then the
> >> encoding of the generated HTML files is determined by -encoding."
> >> We need to reflect this logic and NOT using UTF-8 which is actually the
> >> default.
> >
> > But usin
Vincent Siveton wrote:
Nope. The code passed the encoding parameter *only* if it was not empty.
You're right, I forgot that the Maven JVM might be running with a
different default encoding than the system default that would be picked
by javadoc if "encoding" wasn't specified.
Yes but I th
Le samedi 02 août 2008, Benjamin Bentmann a écrit :
> Vincent Siveton wrote:
> > So by default, we have now:
> > - encoding = ${project.build.sourceEncoding}
> > - docencoding = ${project.reporting.outputEncoding}
> > - charset = null
> >
> > And if charset == null, charset = docencoding
>
> Yes, a
On Sat, Aug 2, 2008 at 2:09 AM, Benjamin Bentmann
<[EMAIL PROTECTED]> wrote:
> The "small change" is to switch back to using the Install Plugin to stage
> the artifact under test into the IT repo. I hope Oliver doesn't mind that I
> went for this ;-)
Thanks!
Strangely, the integration test for M
No reason at all, as far as I can see.
I didn't change the properties when I renamed the files, they were set
like that before the rename too. All files in the project seems to have
the executable flag set.
Vincent Siveton wrote:
Hi Dennis,
2008/7/31 <[EMAIL PROTECTED]>:
Author: dennisl
D
Hi Dennis,
2008/7/31 <[EMAIL PROTECTED]>:
> Author: dennisl
> Date: Thu Jul 31 14:14:19 2008
> New Revision: 681499
>
> URL: http://svn.apache.org/viewvc?rev=681499&view=rev
> Log:
> o Fix spelling of file names.
>
[SNIP]
> Propchange:
> maven/sandbox/trunk/shared/maven-filtering/src/main/java/
2008/8/2 Benjamin Bentmann <[EMAIL PROTECTED]>:
> Vincent Siveton wrote:
>
>> So by default, we have now:
>> - encoding = ${project.build.sourceEncoding}
>> - docencoding = ${project.reporting.outputEncoding}
>> - charset = null
>>
>> And if charset == null, charset = docencoding
>
> Yes, as per MJ
Vincent Siveton wrote:
So by default, we have now:
- encoding = ${project.build.sourceEncoding}
- docencoding = ${project.reporting.outputEncoding}
- charset = null
And if charset == null, charset = docencoding
Yes, as per MJAVADOC-182 and MJAVADOC-206, i.e. setting "docencoding" is
usually
Dennis Lundberg wrote:
Is there something that's stopping us from releasing Maven Invoker 2.0.9
and Maven Invoker Plugin 1.2.1?
Not that I know of. I know Oliver had similar plans, so you two should
probably sync.
Benjamin
--
Hi Benjamin,
Thanks to spot it! I will revert the release and call a new one.
So by default, we have now:
- encoding = ${project.build.sourceEncoding}
- docencoding = ${project.reporting.outputEncoding}
- charset = null
And if charset == null, charset = docencoding
I will add a faq about this l
This MINVOKER-43 issue seems to be hitting a lot of our projects. Is
there something that's stopping us from releasing Maven Invoker 2.0.9
and Maven Invoker Plugin 1.2.1?
In JIRA there are only requests for new features left:
http://jira.codehaus.org/browse/MSHARED/component/13271?selected=com.
Hi Wendy,
Olivier, would you be able to make the change you describe below on
the deploy plugin trunk?
The "small change" is to switch back to using the Install Plugin to
stage the artifact under test into the IT repo. I hope Oliver doesn't
mind that I went for this ;-)
Or can you explain
Hi Vincent,
We solved around 30 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14120&styleName=Text&projectId=11138
The handling of the charset parameter I proposed to Hervé in
MJAVADOC-206 gives rise to misbehavior. Imagine the following plugin
configuration:
ISO-
28 matches
Mail list logo
