On 29/06/2006 4:14 PM, Wendy Smoak wrote:
On 6/28/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Sorry, but I don't really understand what you are asking here.
A plugin attribute of 'filters' that is of type 'List' did not suggest
to me that I ought to type . If anything, I would
have thought i
On 6/29/06, dan tran <[EMAIL PROTECTED]> wrote:
I believe maven depends heavily on dependencies list to determine the
correct order of the build
with out that, you will need to setup that order via parent's modules
elements.
Is that as you say? I am thinking for examples like the
maven-scm-plug
On 6/28/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Sorry, but I don't really understand what you are asking here.
A plugin attribute of 'filters' that is of type 'List' did not suggest
to me that I ought to type . If anything, I would
have thought it meant a comma-delimited list on the coman
Wendy,
Sorry, but I don't really understand what you are asking here. And
thanks for correcting my embarrassing typo :)
- Brett
On 29/06/2006 1:39 PM, Wendy Smoak wrote:
On 6/28/06, Brett Porter <[EMAIL PROTECTED]> wrote:
[Isn't it] helpful, like the default value, to know what the constra
Hi
That is what I thought too, but I have a very simple mojo (that does no have
@requiresProject set) that when run complains that:
[INFO] Cannot execute mojo: generate. It requires a project with an existing pom
.xml, but the build is not using one.
Hermod
-Original Message-
From: Jas
Hmm... good point. This only deals with parameters.
- Brett
On 29/06/2006 2:13 PM, Mike Perham wrote:
I assume it handles @since on both goals and individual parameters
within a goal?
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 28, 2006 11:05
I assume it handles @since on both goals and individual parameters
within a goal?
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 28, 2006 11:05 PM
> To: Maven Developers List
> Subject: [vote] apply MNG-2406 (r417931) to maven-2.0.x branch
>
>
Yes I have seen it many times, but still dont know how to override it .
Could you be more specific? ( sorry i am not well versed wht plexus either)
a snippet is good
-D
On 6/28/06, Eric Redmond <[EMAIL PROTECTED]> wrote:
Similar to how maven-core declares them, you can overwrite them:
htt
Hi,
This is a new feature, so I think it's a good idea to vote on these things.
It adds @since to the plugin descriptor and reads it from the javadoc of
a plugin. It's mostly for informational purposes at the moment.
Note that we have already ported the @parameter implementation="" to the
br
Similar to how maven-core declares them, you can overwrite them:
http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml
Eric
On 6/28/06, dan tran <[EMAIL PROTECTED]> wrote:
how?
-D
On 6/28/06, Eric Redmond <[EMAIL PROTECTED]> wrot
That's a handy page and I've never even seen it before. It is a bit
much for a plugin user - I was thinking something a little more centered
around how to configure a plugin within the POM and a list of POM
variables they can use. It's not terribly useful to say the default is
"${project.build.di
On 6/28/06, Brett Porter <[EMAIL PROTECTED]> wrote:
[Isn't it] helpful, like the default value, to know what the constraints
are for what you enter? And I'd argue lists are very useful as they
indicate how you have to specify it ( vs just ).
(Aside: Now, it is. Apparently, I missed that page
It's the wrapping we're trying to avoid:
http://maven.apache.org/plugins/maven-site-plugin/stage-deploy-mojo.html
The default will always be pulled out in the list of the verbose
description, I tink it was just suggested that it be in the description
in the top table (always at the end).
- Br
I just wanted to point out that this effectively makes the testng support in
surefire "broken" for a good number of users.
Anyone hoping to use testng tests with annotations at least...
On 6/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
NevermindFixed and attached patch. That wasn't hard
I think default values should be in their own column so it is easier to
see/read/find. I find other plugins that have done this much nicer to use.
I very much dislike pages that have buried the defaults somewhere in the
description (front, middle, end - doesn't matter). I also found that when
bur
Now that we're starting to *properly* document plugins and
is now a required pom element, I think that it a default
should be placed in the plugin-parent pom.xml.
However, is not an inherited pom element so I'd like to
ask if allowing to be inherited is also a good idea?
-
Yep. This would be a worthwhile addition to JIRA for a later Maven
roadmap - we could have a tighter way of declaring dependencies for
plugins such that they can be taken into account. The current plugin >
dependencies is a bit of a hack.
So what you can do:
- use the order of the element to
Should the page below suffice for a cheat sheet?
http://maven.apache.org/developers/mojo-api-specification.html
I think its too much info for a beginner since its meant for a plugin
developer... maybe someone here knows of a similar page meant for a user?
Mike Perham wrote:
For required
I believe maven depends heavily on dependencies list to determine the
correct order of the build
with out that, you will need to setup that order via parent's modules
elements.
-D
On 6/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
As I haven't gotten any response in a few days, I though
I agree with copying the default value into the end of the description.
The reason it isn't in the table as a column is that it is too wide,
usually.
I would leave the expression as just the expression in the latter part
as it is now. We've already agreed this is unclear and will deprecate it
how?
-D
On 6/28/06, Eric Redmond <[EMAIL PROTECTED]> wrote:
Can't you override the clean lifecycle as a plexus component, adding your
plugin to it?
Eric
On 6/28/06, dan tran <[EMAIL PROTECTED]> wrote:
>
> any suggestion?
>
> -D
>
>
> On 6/26/06, dan tran <[EMAIL PROTECTED]> wrote:
> >
> >
On 29/06/2006 3:52 AM, Wendy Smoak wrote:
On 6/28/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Edwin has come up with this:
http://jira.codehaus.org/secure/attachment/21233/assembly-mojo.html
Any feedback before I apply it?
Thanks, Edwin! I'd probably drop 'type' from the table at the top,
a
+1 for moving the default value. A lot of the other comments want the
default value at the top of the page. Showing the default value in a
sentence is nice too.
It just somehow becomes complicated because expressions functions
somewhat like a default value, too. Any suggestions on how to
+1
I see no generated pages showing these anywhere... ( or am I blind? ^_^ )
Jesse McConnell wrote:
could it show the class lvl phase and goal settings and perhaps if it
requiresDependencyResolution and that sort of thing?
nice improvement though :)
jesse
On 6/28/06, Brett Porter <[EMAIL P
Issue Subscription
Filter: Outstanding Repository Maintenance: Uploads (7 issues)
Subscriber: mavendevlist
Key Summary
MAVENUPLOAD-963nekodtd 0.1.11
http://jira.codehaus.org/browse/MAVENUPLOAD-963
MAVENUPLOAD-962JasperReports 1.2.4
http://jira.codehaus.org/browse/M
Issue Subscription
Filter: Outstanding Repository Maintenance: Evangelism (37 issues)
Subscriber: mavendevlist
Key Summary
MEV-406 XMLBeans pom is missing dependency
http://jira.codehaus.org/browse/MEV-406
MEV-416 tapestry-contrib 4.0.2 is missing a pom
htt
Isn't it inherited from the plugin parent?
- Brett
On 29/06/2006 3:51 AM, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Wed Jun 28 10:51:12 2006
New Revision: 417827
URL: http://svn.apache.org/viewvc?rev=417827&view=rev
Log:
Add plugin report to the site
Added:
maven/scm/trunk/maven-scm-p
As I haven't gotten any response in a few days, I thought it might help to
repost this.
I'm not sure if this is something that has already been accounted
for, or if I should submit a feature enchancement JIRA issue.
Sincerely,
James Carpenter
desk: 713-374-4374
email: [EMAIL PROTECTED]
Can't you override the clean lifecycle as a plexus component, adding your
plugin to it?
Eric
On 6/28/06, dan tran <[EMAIL PROTECTED]> wrote:
any suggestion?
-D
On 6/26/06, dan tran <[EMAIL PROTECTED]> wrote:
>
> I am also interested on how to do this as well? any suggestion?
>
> -Dan
>
>
Dan,
the concept of classifiers is new to me. I ran into it some days ago
and was thinking about the idea behind it. So, my intention was to
gain a better understanding what it is or what it is intended for.
I think I'll follow your suggestion to raise an issue. But before
that, I'm going to ask
Definitely a big improvement :)
I agree that it'd be nice to see the default value for optional
parameters in the table. Perhaps append it to the description, e.g.
appendAssemblyIdboolean Set to false to exclude the assembly id
from the assembly final name. (Default value is tr
For required parameters, it would be nice to know what the default value
is right there at the top instead of having to navigate down to the
details. Also as a new user, I would think it would be unclear how
"expression" maps to the default value. A cheat sheet or glossary might
be nice at the bo
Examples are the war plugin and resource plugins.
http://maven.apache.org/plugins/index.html is the site I'm referring to.
Jpl
On 6/28/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Edwin has come up with this:
http://jira.codehaus.org/secure/attachment/21233/assembly-mojo.html
Any feedback before I apply it?
Thanks, Edwin! I'd probably drop 'type' from the table at the top,
and just have attribute name and description
could it show the class lvl phase and goal settings and perhaps if it
requiresDependencyResolution and that sort of thing?
nice improvement though :)
jesse
On 6/28/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Hi,
Edwin has come up with this:
http://jira.codehaus.org/secure/attachment/21233/ass
We are pleased to announce the Maven Console Plugin 1.2 release!
http://maven.apache.org/maven-1.x/plugins/console/
===
Changes in this version include:
New Features:
o New property maven.console.completor.goals. F
> On 28/06/2006 8:01 PM, Jason van Zyl wrote:
> > I assume for this we are going to release a series of alphas? How
> > about for each major feature implemented we release an alpha?
>
> When we last discussed it on the development process, we
> talked about instead doing regular promotion of
I had started some documentation based on the Trails idea :
http://docs.codehaus.org/display/MAVENUSER/The+Maven+2+tutorial
but stopped since "Better Builds with Maven" was exactly what I wanted
to produce. Feel to use anything.
On 6/25/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Jason van Z
+1 to most stuff, comments inline.
Emmanuel Venisse wrote:
Hi,
I started to define the roadmap of continuum 1.1. It will be done
normally tomorrow.
The major first things to do in this roadmap are:
- Reimplementation of authentication/authorization management
(CONTINUUM-542 and CONTINUUM-5
most of classier artifacts are deployed by custom plugin ( ie
native-maven-plugin
can deploy .dll and .lib. ) it has access to maven project model
Anyway, if you think this is a needed feature, please file a JIRA against
maven core
-D
On 6/28/06, Stefan Hübner <[EMAIL PROTECTED]> wrote:
But shouldn't my classified artifacts end up in repository the same
way, classified 3rd-party artifacts do? Why should it be easy to
deploy classified 3rd-parties but hard to deploy own classifieds from
a user's point of view?
Since lots of artifacts are developed like this (I'd reckon), how will
Hi,
Edwin has come up with this:
http://jira.codehaus.org/secure/attachment/21233/assembly-mojo.html
Any feedback before I apply it?
- Brett
--
Brett Porter <[EMAIL PROTECTED]>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
-
any suggestion?
-D
On 6/26/06, dan tran <[EMAIL PROTECTED]> wrote:
I am also interested on how to do this as well? any suggestion?
-Dan
On 6/26/06, Marcin Maciukiewicz <[EMAIL PROTECTED]> wrote:
>
> Hi!
>
> My plugin is using my own packaging. I need to overwrite (not only
> customize)
yes, deploy:deploy-file is used to deploy thirdary artifacts.
In your case, you want to deploy your artifact dynamically depending on env
( profile) during build
-D
On 6/28/06, Stefan Hübner <[EMAIL PROTECTED]> wrote:
Is this use case that different from deploying "classified"
3rd-party-libr
Is this use case that different from deploying "classified" 3rd-party-libraries?
-Stefan
2006/6/28, dan tran <[EMAIL PROTECTED]>:
in that case, the closest i can think of is build-helper-maven-plugin, not
sure
that will solve your issue
-D
On 6/28/06, Stefan Hübner <[EMAIL PROTECTED]> wrote:
Emmanuel Venisse wrote:
ok, I think the roadmap is done now. We have 159 issues.
Dude, it has only been 5 hours. I have a few comments that I would like
to express but I won't have time until later tonight.
--
Trygve
in that case, the closest i can think of is build-helper-maven-plugin, not
sure
that will solve your issue
-D
On 6/28/06, Stefan Hübner <[EMAIL PROTECTED]> wrote:
Hi Dan,
I've got some artifacts, whose resources get filtered regarding to the
environment they'll be running in. So applying cla
Thanks for fixing that Brett - do you think you'll release 2.0.2
straight away or wait for other fixes to be incorporated?
Cheers,
Mark
On 28/06/06, Mark Hobson <[EMAIL PROTECTED]> wrote:
Okay, attachments aren't allowed on this list then :)
See http://jira.codehaus.org/browse/MWAR-55.
Cheer
How about building without Sun JARs? Is that an achievable goal for 1.1?
On 29/06/2006 12:40 AM, Emmanuel Venisse wrote:
ok, I think the roadmap is done now. We have 159 issues.
I'll be happy if we can include all these issues in 1.1 :-)
Emmanuel
Emmanuel Venisse a écrit :
Hi,
I started to
Hi Dan,
I've got some artifacts, whose resources get filtered regarding to the
environment they'll be running in. So applying classifiers would be
the way to distinguish between those differently modified artifacts, I
guess. I don't know of a way to apply classifiers to the final
artifacts to be
NevermindFixed and attached patch. That wasn't hard at all! (grins
imagining 20 other things potentially broken by simple patch )
On 6/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
Hi guys,
Before I go spinning my wheels in the surefire source too much I was
wondering if anyone here
Hi guys,
Before I go spinning my wheels in the surefire source too much I was
wondering if anyone here was more familiar than myself with the classloading
semantics involved with the surefire -plugin -> Surefire Booter execution?
I've made comments on what I've discovered so far but if anyone ha
what is your use case?
-D
On 6/28/06, Stefan Hübner <[EMAIL PROTECTED]> wrote:
Hi all,
I'm not sure, if you keep track of closed jira issues. So I forward my
question on MDEPLOY-19 to this list:
"Was there any particular reason, to issue this only for the
deploy-file goal? Doesn't this also
Hi all,
I'm not sure, if you keep track of closed jira issues. So I forward my
question on MDEPLOY-19 to this list:
"Was there any particular reason, to issue this only for the
deploy-file goal? Doesn't this also make sense for the deploy-goal?"
If closed issues don't get off your radar, I'm so
Brett Porter wrote:
yah, we can change the name, I was just making it consistent with the
repository manager one I had already set up.
Continuum still forks all the builds, so I'm not sure why using the
system property would be harder, it's just an additional property you
can use instead of -
On 28 Jun 06, at 11:18 AM 28 Jun 06, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
Hi
As part of a an initial project setup, I want to execute a mojo
that I have written (sort of like archetyep:create). At this stage
the pom is not available, so I was wondering how to specify that
th
Okay, attachments aren't allowed on this list then :)
See http://jira.codehaus.org/browse/MWAR-55.
Cheers,
Mark
On 28/06/06, Mail Delivery Subsystem <[EMAIL PROTECTED]> wrote:
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanent
On 28 Jun 06, at 11:25 AM 28 Jun 06, Brett Porter wrote:
On 28/06/2006 8:01 PM, Jason van Zyl wrote:
I assume for this we are going to release a series of alphas? How
about for each major feature implemented we release an alpha?
When we last discussed it on the development process, we talke
There's a test to explicitly test this. Do you have a test case?
- Brett
On 28/06/2006 7:47 PM, Mark Hobson wrote:
Looks like a regression has crept into 2.0.1 regarding web.xml when
overlaying wars - it is subject to the normal if-newer timestamp
checks for war overlay resources rather than th
On 28/06/2006 8:01 PM, Jason van Zyl wrote:
I assume for this we are going to release a series of alphas? How about
for each major feature implemented we release an alpha?
When we last discussed it on the development process, we talked about
instead doing regular promotion of the automated bui
Hi
As part of a an initial project setup, I want to execute a mojo that I have
written (sort of like archetyep:create). At this stage the pom is not
available, so I was wondering how to specify that the mojo does not require a
pom.
Hermod
* * * * * * * * * * * * * * * * * * * * * * * * * * *
Looks like a regression has crept into 2.0.1 regarding web.xml when
overlaying wars - it is subject to the normal if-newer timestamp
checks for war overlay resources rather than the main project web.xml
always taking precedence. I assume this is not intended behaviour?
Mark
On 27/06/06, Thierry
yep, in Maven 2 layout with sha1 and md5 checksums.
Thanks
On 6/28/06, Nicolas De Loof <[EMAIL PROTECTED]> wrote:
Hello guys,
I've posted this on users list with no reply:
I'd like to contribute to maven2 repo by addind some missing "*-sources.jar"
I've created
in my corporate repo (for sou
Hello guys,
I've posted this on users list with no reply:
I'd like to contribute to maven2 repo by addind some missing "*-sources.jar" I've created
in my corporate repo (for source attachement in Eclipse IDE)
I'd like to avoid creating a hundred upload-bundles for Jira upload request.
Would y
64 matches
Mail list logo
