Brian E. Fox a écrit :
Currently only plugins get a nice looking skin that matches the main
maven.apache.org page because the site.xml exists in the plugin project.
Other things like shared get a homely looking default skin. I see two
options here:
1. Move the site.xml up to the
On 4/3/07, Jerome Lacoste [EMAIL PROTECTED] wrote:
On 4/3/07, Brian E. Fox [EMAIL PROTECTED] wrote:
Ok, a little more refactoring. The Custom rules can now get to the
ExpressionEvaluator so they can get pretty much anything a plugin could
get. The sites are updated to contain info about the
+1 [ X ] Move to Maven Pom
On 4/3/07, Brian E. Fox [EMAIL PROTECTED] wrote:
Currently only plugins get a nice looking skin that matches the main
maven.apache.org page because the site.xml exists in the plugin project.
Other things like shared get a homely looking default skin. I see two
options
some more feedback:
* Is that useful ?
[WARNING]None
I'll remove that, not sure where it's from.
* enforce-one mojo attached to verify phase. I would have preferred
the build to fail as early as possible if it is to tell me that I am
using the wrong JDK/maven version... Shouldn't we let the
On 4/3/07, Brian E. Fox [EMAIL PROTECTED] wrote:
some more feedback:
* Is that useful ?
[WARNING]None
I'll remove that, not sure where it's from.
More explicitly:
[INFO] Used undeclared dependencies:
[WARNING]None
* enforce-one mojo attached to verify phase. I would have
More explicitly:
[INFO] Used undeclared dependencies:
[WARNING]None
Ah, that's the dependency plugin. Yes I already fixed that but not
before it was staged and a vote called.
I confused verify with validate so I'll change that. I thought you
could
bind it to another phase if you want, but
Ok, I'll release these tonight and document the stage copying utility.
Jason.
On 2 Apr 07, at 11:22 PM 2 Apr 07, John Tolentino wrote:
+1
On 4/3/07, John Casey [EMAIL PROTECTED] wrote:
+1
On 4/2/07, Jason Dillon [EMAIL PROTECTED] wrote:
+1
--jason
On Apr 1, 2007, at 10:36 AM, Jason
Ok, I've fixed MASSEMBLY-194, and put a new test in place to verify it.
However, I cannot get Continuum to build from trunk, so I'm unable to build
your attached test project. I'm currently merging the fix over to the
2.2-beta-1 tag, then I'll push up a new RC to my people.a.o account. I
should
Hi,
now that Maria has applied MSOURCES-14, can this release proceed?
Thanks,
Jochen
--
My cats know that I am a loser who goes out for hunting every day
without ever returning as much as a single mouse. Fortunately, I've
got a wife who's a real champ: She leaves the house and returns within
Wendy Smoak [EMAIL PROTECTED] writes:
Congrats, you just found the reason why for the Velocity site, I added
an extra directory where the filtered templates are located.
Is there any documentation on how to use these filters? Is it just
all files pass through Velocity or can one control it?
On 3 Apr 07, at 1:39 PM 3 Apr 07, Jochen Wiedmann wrote:
Hi,
now that Maria has applied MSOURCES-14, can this release proceed?
I'll check it with the embedder and a few other projects before I
give it a thumbs up.
jason.
Thanks,
Jochen
--
My cats know that I am a loser who goes
The Require OS Version rules docs is using goalos/goal instead of
goalrequire/goal (or goalrequire-once/goal).
* * *
Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
--jason
On Apr 2, 2007, at 7:31 PM, Brian E. Fox wrote:
Ok, a little more refactoring. The Custom
I had this working for a while... maybe I changed something in the
plugin locally... will look at it again, I need this to work for my
integration test muck.
--jason
On Apr 2, 2007, at 7:59 PM, Brian E. Fox wrote:
Rahul was having this problem with the achetypeNG with groupId, even
The Require OS Version rules docs is using goalos/goal instead of
goalrequire/goal (or goalrequire-once/goal).
Good catch. I'll make that change.
Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
Getting there. I want to explore Jerome's comments about reports and a
vistor
Hi,
I'd like to release maven-skins pom 3.
This is in preparation of a patch release of maven-stylus-skin. Since it
is not possible to use the release-plugin to release a parent pom like
this one, I'm offering you a diff between the last release and the
proposed new release, instead of
Hi Jason,
My problem was the usage of properties $(project.version} ${project.groupId}
in the depMan of the parent pom. I now enforce manual resolution.
The depMan defined the modules version and groupId for other modules.
Regards,
Raphaël
2007/4/3, Jason Dillon [EMAIL PROTECTED]:
I had
http://maven.apache.org/team-list.html
Emmanuel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Emmanuel Venisse wrote:
http://maven.apache.org/team-list.html
Emmanuel
Hey, that's published on April 2. not April 1. ;-)
--
Dennis Lundberg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
I need this to get a list of versions available for an artifact. I
want to do it the same way maven does to avoid inconsistencies, so the
index is not an option.
On 4/2/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 2 Apr 07, at 8:22 PM 2 Apr 07, Carlos Sanchez wrote:
I haven't found a direct
On Apr 3, 2007, at 1:24 PM, Brian E. Fox wrote:
Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
Getting there. I want to explore Jerome's comments about reports and a
vistor pattern. I haven't spent a lot of time thinking about it,
but I'm
not sure how a visitor would
There are no developers working on this project.
I guess we all quit ;-)
-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 4:46 PM
To: Maven Developers List
Subject: The team list is empty on maven.apache.org
+1 Move to Maven Pom
On 4/3/07, John Tolentino [EMAIL PROTECTED] wrote:
+1 [ X ] Move to Maven Pom
On 4/3/07, Brian E. Fox [EMAIL PROTECTED] wrote:
Currently only plugins get a nice looking skin that matches the main
maven.apache.org page because the site.xml exists in the plugin project.
Brian E. Fox wrote:
Currently only plugins get a nice looking skin that matches the main
maven.apache.org page because the site.xml exists in the plugin project.
Other things like shared get a homely looking default skin. I see two
options here:
1. Move the site.xml up to the maven
Aighty I figured this out... the tag for maven-install-plugin-2.1 has
groupId, artifactId, version, packaging and file all marked with
'@readonly'. The latest trunk of maven-install-plugin does not have
these tags.
So, with 2.1 you can only `mvn install:install-file` from the command-
On 4/3/07, Brian E. Fox [EMAIL PROTECTED] wrote:
The Require OS Version rules docs is using goalos/goal instead of
goalrequire/goal (or goalrequire-once/goal).
Good catch. I'll make that change.
Is it close to time for a release of 1.0-alpha-1 of this puppy yet?
Getting there. I want to
On 04/04/2007, at 9:19 AM, [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Tue Apr 3 16:19:29 2007
New Revision: 525327
Shouldn't the tag be deleted and recreated by the release plugin
instead of merging changes around in this fashion?
- Brett
Why does dependency:analyze need target dirs? This barfs all over
the place for modules of type pom... making this goal unusable.
snip
[INFO] Preparing dependency:analyze
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO]
we can do that, but what's the difference? I'm really hoping that this last
fix is enough to at least call this a beta, and that we won't be continuing
down this path indefinitely.
BTW, the last regression was actually a bug in the way the 2.1 version
handled transitive dependencies...there is
On 04/04/2007, at 10:54 AM, John Casey wrote:
we can do that, but what's the difference? I'm really hoping that
this last
fix is enough to at least call this a beta, and that we won't be
continuing
down this path indefinitely.
Sure - just as a general process for the future :)
BTW,
+1 (remember to remove the -SNAPSHOT from the rev)
-Original Message-
From: Dennis Lundberg [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 4:37 PM
To: Maven Developers List
Subject: [VOTE] Release maven-skins pom 3
Hi,
I'd like to release maven-skins pom 3.
This is in
I was viewing the commit log for
http://jira.codehaus.org/browse/MDEP-73?page=com.atlassian.jira.plugin.e
xt.subversion:subversion-commits-tabpanel
and got this url:
http://svn.apache.org/viewvc/maven/maven/plugins/trunk/maven-dependency-
Ok I understand now. Lets punt alpha-1 and then we can play around with
various options to get this information. It will probably represent an
addition to the rule interface so it won't be intrusive (and if it is,
well it's alpha-1 ;-) )
-Original Message-
From: Jerome Lacoste
+1
On 3 Apr 07, at 4:36 PM 3 Apr 07, Dennis Lundberg wrote:
Hi,
I'd like to release maven-skins pom 3.
This is in preparation of a patch release of maven-stylus-skin.
Since it is not possible to use the release-plugin to release a
parent pom like this one, I'm offering you a diff between
On 3 Apr 07, at 4:55 PM 3 Apr 07, Carlos Sanchez wrote:
I need this to get a list of versions available for an artifact. I
want to do it the same way maven does to avoid inconsistencies, so the
index is not an option.
If this is for releases which is probably what the you want there are
no
As Jerome pointed out earlier today on the enforcer thread, it would be
nice to be able to bind some plugins like the enforcer to a phase that
affects both default and site. After all, if you don't want to support
some Maven/Jdk/Os/other version, chances are that applies to sites and
reports as
I'm not aware of any. If it's not here, it doesn't exist.
http://svn.apache.org/viewvc/maven/scm/trunk/maven-scm-providers/
On 4/3/07, Tim Reilly [EMAIL PROTECTED] wrote:
Can anyone tell me what the state of PVCS integration is.
I recall some discussions a while ago that a provider for PVCS
I think pre-site is the site lifecycle's initialize phase ( as is
pre-clean for the clean lifecycle ).
On 4/3/07, Brian E. Fox [EMAIL PROTECTED] wrote:
As Jerome pointed out earlier today on the enforcer thread, it would be
nice to be able to bind some plugins like the enforcer to a phase that
That's right. What I'm asking for though is a phase that is common
between both lifecycles so a plugin can be bound to run in both cases
without having to duplicate executions. In the case of enforcer, it
would be the default as specified in the mojo annotation.
-Original Message-
From:
The maven-enforcer-plugin picks up where prerequisites leaves off and
allows control over the maven, jdk and os versions of a build, as well
as injection of custom rules.
The deployments are staged here:
http://people.apache.org/~brianf/staging-repository
The sites are deployed here:
+1
--jason
On Apr 3, 2007, at 7:54 PM, Brian E. Fox wrote:
The maven-enforcer-plugin picks up where prerequisites leaves off
and
allows control over the maven, jdk and os versions of a build, as well
as injection of custom rules.
The deployments are staged here:
Only 1? I figured you'd be +1000 at least by now ;-)
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dillon
Sent: Tuesday, April 03, 2007 11:13 PM
To: Maven Developers List
Subject: Re: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and
I was just looking through my open reported issues and found this one:
http://jira.codehaus.org/browse/MNG-2570 add your ideas here.
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dillon
Sent: Monday, April 02, 2007 11:49 PM
To: Maven Developers List
42 matches
Mail list logo
