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
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 source
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,
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
* * * * * * * * * * * * * * * * * * * * * * * * * *
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
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
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
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
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
the
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
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
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 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
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 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
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
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.
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
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
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:
Hi
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
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) clean
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/
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
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:
+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
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 Zyl
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
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:
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.
Examples are the war plugin and resource plugins.
http://maven.apache.org/plugins/index.html is the site I'm referring to.
Jpl
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
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
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.
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
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
On
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]
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=417827view=rev
Log:
Add plugin report to the site
Added:
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
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
+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
+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
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,
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:
I am also
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
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 thought
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
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 modules
Now that we're starting to *properly* document plugins and
prerequisites is now a required pom element, I think that it a default
should be placed in the plugin-parent pom.xml.
However, prerequisites is not an inherited pom element so I'd like to
ask if allowing prerequisites to be
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
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 at
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).
-
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 (filtersfilter vs just filter).
(Aside: Now, it is. Apparently,
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
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] wrote:
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
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:
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
Hi,
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
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:
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
On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote:
Hi,
I started to define the roadmap of continuum 1.1. It will be done
normally tomorrow.
Are we deciding that these are the things are going to be in 1.1 and
take as long as we need? I would prefer that myself. Looking below
Jason van Zyl a écrit :
On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote:
Hi,
I started to define the roadmap of continuum 1.1. It will be done
normally tomorrow.
Are we deciding that these are the things are going to be in 1.1 and
take as long as we need? I would prefer
- Remove JDO (at least jpox) because it the source of lot of our
issues
+1
My only opinion on this is to think about it, but save the work until we
bump into the next big problem that is going to require a lot of effort
to fix. It seems stable enough in 1.0.3 and if it remains that way
- customization of the add project feature. In this part, I think
to add a multi-project as a multiple projects or as a single
project, scm connection string to use, add with a scm url, add all
modules by a scm connection instead of an url contruction based on
project url provided in the add
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 define the roadmap of continuum 1.1. It will be done
normally tomorrow.
The major first things to do in this roadmap
hi,
how could I help here?
I am currently trying to understand the problems already mentioned.
What could be the next step?
I am new to maven dev.
best regards
Bernd
67 matches
Mail list logo
