But one standard for everyone, please. You checked in a more significant
contribution without discussion *at all* just a few days ago
(http://svn.apache.org/viewvc?view=rev&revision=653572).
Apart from the discussion why and who has committed it I feel a bit strange as committer having signed
I didn't even see the commit until after my first reply (for some
reason it appeared in my mailbox late), and I've had no discussion
with James about this that you haven't seen. I was kind of surprised
too, and I think it was just a miscommunication.
I would like to apologise for the mi
On 10/05/2008, at 12:28 AM, Jason van Zyl wrote:
The difference was that the GIT provider was discussed and
contributed via JIRA, like all other contributions. The other
provider appeared, on trunk, completely unannounced. It's clearly a
double standard to then turn around and say things
Vincent Siveton wrote:
Actually, end users could control the output with -Ddetail parameter,
so why not the formatting ?
Well, alright.
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [
>BTW I tried help plugin on the javadoc plugin, which is a plugin with
>a ton of parameters, and the build takes 2 seconds. IMHO it is a
>reasonable time...
Good point. If you're itching for stuff to fix, take a look at the
2.0.10 issues list ;-)
2008/5/9, Benjamin Bentmann <[EMAIL PROTECTED]>:
> Vincent Siveton wrote:
>
>
> > IIRC the main reason to have toLines() in the generated class is to
> > control the ouput, ie getting user configuration like max buffer or
> > indentation and providing the specific output.
> >
>
> You mean to suppo
Hi again,
2008/5/9, Benjamin Bentmann <[EMAIL PROTECTED]>:
> Hi,
>
> The help goal that gets generated by the Maven Plugin Tools 2.4 contains
> various internal utility methods (e.g. toLines()) that do some pretty
> printing of long descriptions at execution time of the help goal.
BTW I tried he
Vincent Siveton wrote:
IIRC the main reason to have toLines() in the generated class is to
control the ouput, ie getting user configuration like max buffer or
indentation and providing the specific output.
You mean to support something like this:
mvn foo:help -Dindent=4 -Dmax=120
Do I under
Hi Benjamin,
2008/5/9, Benjamin Bentmann <[EMAIL PROTECTED]>:
> Hi,
>
> The help goal that gets generated by the Maven Plugin Tools 2.4 contains
> various internal utility methods (e.g. toLines()) that do some pretty
> printing of long descriptions at execution time of the help goal.
>
> Any rea
It was called alpha-1 because there were big changes, however i think
we should go ahead with 2.1 since
everyone seems very happy about it.
-D
On Fri, May 9, 2008 at 1:38 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote:
> Hi,
> No objections.
> But currently the war plugin trunk depends on other snap
Hi,
No objections.
But currently the war plugin trunk depends on other snapshots :
- org.apache.maven.plugins:maven-invoker-plugin:1.2-SNAPSHOT
- org.apache.maven.shared:maven-filtering:1.0-alpha-1-SNAPSHOT
The first one has one issue open.
The second one is a new shared component which IMHO can b
Any objections to releasing maven-war-plugin and maven-deploy-plugin soon?
War Plugin
---
Version 2.1-alpha-2 is complete in JIRA:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13804&styleName=Html&projectId=11150&Create=Create
Is this really still alpha? Thoughts on call
On 9-May-08, at 12:10 PM, Benjamin Bentmann wrote:
Hi,
The help goal that gets generated by the Maven Plugin Tools 2.4
contains various internal utility methods (e.g. toLines()) that do
some pretty printing of long descriptions at execution time of the
help goal.
Any reason why we coul
Hi,
The help goal that gets generated by the Maven Plugin Tools 2.4 contains
various internal utility methods (e.g. toLines()) that do some pretty
printing of long descriptions at execution time of the help goal.
Any reason why we couldn't do all this line breaking and indentation stuff
righ
On 9-May-08, at 7:28 AM, Jason van Zyl wrote:
On 9-May-08, at 2:41 AM, Brett Porter wrote:
On 09/05/2008, at 6:03 PM, Jason van Zyl wrote:
Ah, hold on there. 1) Since when did accepting new bodies of
code be decided between two people.
It shouldn't be, and IMO this discussion should
On 9-May-08, at 2:41 AM, Brett Porter wrote:
On 09/05/2008, at 6:03 PM, Jason van Zyl wrote:
Ah, hold on there. 1) Since when did accepting new bodies of code
be decided between two people.
It shouldn't be, and IMO this discussion should continue and get
some more opinions (as I said
[snipped]
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kirosawa
[snipped]
That's Akira Kurosawa (not Kirosawa)!
:-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
On 09/05/2008, at 6:03 PM, Jason van Zyl wrote:
Ah, hold on there. 1) Since when did accepting new bodies of code
be decided between two people.
It shouldn't be, and IMO this discussion should continue and get
some more opinions (as I said "if there is support here"). After
that, the s
On Fri, May 9, 2008 at 12:01 AM, Jan Nielsen <[EMAIL PROTECTED]>
wrote:
> FWIW, IMO introducing Spring and OSGI to replace a number of the
> choices in Maven is a good start; these are excellent frameworks with
> excellent documentation, excellent communities, and a lot of
> experienced developers
Hi,
For those not at JavaOne I just wanted to mention that Kohsuke along
with the Hudson community won a Duke award. I think Hudson is awesome
and Kohsuke has done a great job supporting the community (just read
the mailing list to see how supportive he is) and Hudson as a tool is
just fa
On 8-May-08, at 11:00 PM, Brett Porter wrote:
On 09/05/2008, at 3:06 PM, Jason van Zyl wrote:
How does this differ from the remote-resources plugin? Could it be
combined with that?
Remote resources plugin simply bundles resources together as a
different
artifact to allow other builds t
21 matches
Mail list logo
