On 09/04/2007, at 3:15 PM, Jason van Zyl wrote:
I do. Myself, John T, and John C.
/me wonders where his mail client stashed the other ones. Sorry John C!
I can't see the problem right off as I have the build previous the
stage, and what I just built now and they container all the wagon
On 9 Apr 07, at 1:06 AM 9 Apr 07, Brett Porter wrote:
On 09/04/2007, at 3:01 PM, Jason van Zyl wrote:
On 8 Apr 07, at 11:39 PM 8 Apr 07, Brett Porter wrote:
-1
You missed the window by a long shot but I haven't copied the
staging directory over, but please try and check things before
On 09/04/2007, at 3:01 PM, Jason van Zyl wrote:
On 8 Apr 07, at 11:39 PM 8 Apr 07, Brett Porter wrote:
-1
You missed the window by a long shot but I haven't copied the
staging directory over, but please try and check things before the
window elapses.
I tried, but I've been swamped a
On 8 Apr 07, at 11:39 PM 8 Apr 07, Brett Porter wrote:
-1
You missed the window by a long shot but I haven't copied the staging
directory over, but please try and check things before the window
elapses.
I left to others to check and there are no tests and the sample is
hardwired to t
-1
The uberjar does not work equivalently to the last release, as it
does not contain the lightweight http wagon. I've filed this as
MANTTASKS-64. I also noticed that the uberjar is larger than the
previous one, despite omitting some things - I wonder if something
was unnecessarily includ
With the current archetype version - no. But feel free to file a jira issue
( if one hasn't already been ) :)
On 4/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
Looks like the current archetype stuff isn't happy making files in
src/main/groovy, it pukes this up when trying:
[INFO] Error creat
On 8 Apr 07, at 10:41 PM 8 Apr 07, Brett Porter wrote:
It seems apparent now that we should push forward with the ng
stuff. I was going to test if it is at least equivalent to trunk
and then propose bringing it in to replace trunk and start to plan
out 1.0 from there.
It doesn't work t
On 4/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
Is there anyways to get custom archetype handling for files which
should really be in src/main/groovy, not src/main/java?
If you just want them directly in 'src/main/groovy' then add them as
and not as source files.
What's currently broken
I think we should continue to use ARCHETYPE and start planning
towards a 1.0 with the new code base. The current JIRA will need a
clean up to see what issues are still relevant in the new code base,
of course.
- Brett
On 09/04/2007, at 5:02 AM, Franz Allan Valencia See wrote:
Curious,..
It seems apparent now that we should push forward with the ng stuff.
I was going to test if it is at least equivalent to trunk and then
propose bringing it in to replace trunk and start to plan out 1.0
from there.
Does anyone have any bandwidth to help with that?
Thanks,
Brett
On 09/04/20
On 3/4/07, Wendy Smoak <[EMAIL PROTECTED]> wrote:
The Archetype plugin has lost the ability to "package" non-Java
resources. It looks like this happened with the addition of 'sub
packages' for Java sources.
ping. Any thoughts on whether the problem with "packaging" resources
should be fixed i
Sure thing.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 08, 2007 6:33 PM
To: dev@maven.apache.org
Subject: Re: svn commit: r526562 - /maven/pom/trunk/maven/pom.xml
Brian,
Thanks for doing this. Would you mind setting your editor to use 2
spaces
Looks like the current archetype stuff isn't happy making files in
src/main/groovy, it pukes this up when trying:
[INFO] Error creating from archetype
Embedded error: Template 'src/main/groovy/MyMojo.groovy' not in
directory 'src/main/java'
Probably has something to do with package handl
Brian,
Thanks for doing this. Would you mind setting your editor to use 2
spaces for XML indentation for consistency with the rest of the
codebase?
Cheers,
Brett
On 09/04/2007, at 12:10 AM, [EMAIL PROTECTED] wrote:
Author: brianf
Date: Sun Apr 8 07:10:45 2007
New Revision: 526562
URL:
WEB-INF/lib sorry.
Just back from vacation, hope ApacheCon was good. I've worked on it
during the week and I'll send a mail later, probably tomorrow.
Stéphane.
On 3/30/07, Andrew Williams <[EMAIL PROTECTED]> wrote:
On 21 Mar 2007, at 07:04, Stephane Nicoll wrote:
> Hi,
>
> On 3/21/07, Brian
Curious,..
Where is the jira issue(s) for this? ..Can't seem to find them :-)
Thanks,
Franz
On 4/1/07, Milos Kleint <[EMAIL PROTECTED]> wrote:
On 4/1/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 1 Apr 07, at 6:49 AM 1 Apr 07, Milos Kleint wrote:
>
> >>
> >
> > exactly this is a showsto
Ahh, I see
still, assuming not all users will be aware of this (I wasn't) and will
probably attribute it to a site-mess, a link back would definitely help.
cheers and keep up the good work :)
On 4/8/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
Thanks Arik. The custom rule site is actually
Thanks Arik. The custom rule site is actually part of the shared component not
the plugin. That's why the plugin left menu doesn't show up. I guess I can add
a link back to the plugin page from there. I made this separate because the
rules could in theory be executed by things other than the plu
Hi,
Cool idea - congratz.
Also wanted to note that there's a slight problem in the site, at:
http://maven.apache.org/shared/maven-enforcer-rule-api/writing-a-custom-rule.html
This page's left menu does not show the full menu shown when viewing the
plugin's other pages.
cheers,
Arik.
apart from the css glitch it seems good.
Andy
On 8 Apr 2007, at 04:12, Brian E. Fox wrote:
I moved the site stuff up to the main maven pom. I staged the maven
main
site here: http://people.apache.org/~brianf/maven/
I think this is pretty good. I also staged a shared component to
see how
-1 (just a vote, not a veto)
I've found 2 backwards incompatibilities that affect its usability in
my build:
- dependencies are unpacked into a subdirectory with their artifactId
where they weren't before (this may be correct behaviour where before
it was a bug, just needs to be checked)
-
21 matches
Mail list logo