Hi,
I have start a proposal [1]
Thanks for comments,
--
Olivier
[1]
http://docs.codehaus.org/display/MAVEN/Resources+Handling+(common+component+maven-filtering)
2008/3/1, Jason van Zyl <[EMAIL PROTECTED]>:
> I'll write something up about the ordering of processing in the wiki
> so that we don'
It should throw a message with a range that would allow the build to
work. So the user can cut and paste that and try that. Picking the
RELEASE in the case of a conflict just doesn't make any sense.
On 3-Mar-08, at 3:05 PM, William Ferguson wrote:
If 3.2 where (sic) expressed as a hard requi
> If 3.2 where (sic) expressed as a hard requirement, it should throw an
exception.
Yes, but not a NullPointer.
The reason for the failure needs to be clear and unambiguous.
William
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 4 March 2008 7:52
Can you create an issue for this in JIRA:
http://jira.codehaus.org/browse/MANT
There you can attach your patch. We use JIRA to track all fixes and
enhancements.
Thank you!
MadVet wrote:
Hi
I have found and fix one problem with Maven Ant plugin. I had worked with
multi-module maven proj
Hey Brian,
On 04/03/2008, at 6:48 AM, [EMAIL PROTECTED] wrote:
Author: brianf
Date: Mon Mar 3 11:48:31 2008
New Revision: 633248
URL: http://svn.apache.org/viewvc?rev=633248&view=rev
Log:
added IT for MNG-2123 provided by Martin Goldhahn
Can we set this to (2.0.9-SNAPSHOT,) and disable unti
On 04/03/2008, at 6:22 AM, Brian E. Fox wrote:
As I understand your proposal, the don't-append-marker would vanish
after
the first inheritance step, re-enabling the default behavior for all
descendant POMs?
You're right, it probably won't work that way. I was thinking the
behavior info wo
On 04/03/2008, at 5:46 AM, Milos Kleint wrote:
yes, adding it to settings.xml would be nice.
Unfortunately as I understand it (correct me if I'm wrong), once you
need toolchains for one project, you need to put it into settings.xml,
thus you cannot build *any* project with old (up to 3.0.8 now)
The test case provided at the end seems like a different issue to the
one Carlos originally described. I would suggest cloning the issue for
that and it looks like the original report is either already fixed or
easy to come up with a test case. Carlos?
For the example given below, I believe
Thanks.
2008/3/3, Vincent Siveton <[EMAIL PROTECTED]>:
> Hi Raphael,
>
> I plan to call a vote this week.
>
> Cheers,
>
> Vincent
>
> 2008/3/3, Raphaël Piéroni <[EMAIL PROTECTED]>:
>
> > Hi,
> >
> > Is there any plan to release the Maven Plugin Plugin 2.4?
> >
> > I would it released to
+1
Dan
On Saturday 01 March 2008, Brett Porter wrote:
> Hi,
>
> The Shade plugin is ready to be released. This is needed for the 2.0.9
> release as well.
>
> We solved 6 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11540&style
>Name=Html&version=13994
>
> The remaining
Hi Raphael,
I plan to call a vote this week.
Cheers,
Vincent
2008/3/3, Raphaël Piéroni <[EMAIL PROTECTED]>:
> Hi,
>
> Is there any plan to release the Maven Plugin Plugin 2.4?
>
> I would it released to close the issue
> http://jira.codehaus.org/browse/ARCHETYPE-109
>
> Regards,
>
>
> Raph
Hi,
Is there any plan to release the Maven Plugin Plugin 2.4?
I would it released to close the issue
http://jira.codehaus.org/browse/ARCHETYPE-109
Regards,
Raphaël
>As I understand your proposal, the don't-append-marker would vanish
after
>the first inheritance step, re-enabling the default behavior for all
>descendant POMs?
You're right, it probably won't work that way. I was thinking the
behavior info would be available throughout the inheritance proces
>Another question: How would the special don't-append-marker behave in
>context of multiple parent POMs? I'm not fully familar with the project
>builder but wouldn't the following sequence apply:
>- grandfather POM defines "url/##"
>- parent POM inherits "url/##" and fixes it to "url/"
>- child PO
On Mon, Mar 3, 2008 at 1:40 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> Hi,
>
> In reviewing the toolchain I had some thoughts about the
> implementation and some questions to ask.
>
> Firstly - the toolchains.xml file being separate is handy for working
> with current versions of Maven. Howe
>The docs at [0] got updated to say the artifact id will always be
appended,
>regardless of a trailing slash or not. Are there any other docs handing
>around from which people might be fooled?
Probably not, but we changed the docs because of this issue.
>Also note that this unconditional appendi
Ok, the 72h is up (and then some), and we've got quite a few votes.
The breakdown is as follows:
PMC: John C., Jesse M., Brian F., Lukas T., Arnaud H., Brett P.,
Stephane N., Olivier L., Maria C., Dennis L., Vincent S.
Committers: Benjamin B., Fabrice B., Raphael P.
Welcome Paul!
-john
[...] as documented says that only urls ending in / will be inherited in
the normal way by appending the artifactid to the end of the url.
The docs at [0] got updated to say the artifact id will always be appended,
regardless of a trailing slash or not. Are there any other docs handing
around fr
http://jira.codehaus.org/browse/MNG-2123
The proposed fix is to return RELEASE as the version if two dependencies
at the same level specify incompatible versions (ie 3.2 and
(2.0,3.1.99]). Clearly we shouldn't throw an NPE, but returning the
RELEASE version feels wrong. First that totally break
Yeah, I was mistaken. I'm working on clearing up the confusion, but
basically it got changed somewhere between 2.0.x branch and today in
trunk.
-john
On Mar 3, 2008, at 12:19 PM, Benjamin Bentmann wrote:
I'd like to know how many people are using ${plugin.artifacts} in
their plugins.
One
All I can say is, OOPS!
I wasn't completely aware of this, but the plugin-classloader
construction logic changed in the trunk of maven from 2.0.x. It seems
that during the course of these changes the plugin manager stopped
managing the PluginDescriptor's artifacts collection as closely.
i've merged just equals and hashcode, I don't know if the other
changes should be merged or not.
On Mon, Mar 3, 2008 at 5:41 AM, John Casey <[EMAIL PROTECTED]> wrote:
> none that I know of.
>
>
>
>
>
> On Mar 3, 2008, at 2:28 AM, Carlos Sanchez wrote:
>
> Any reason why revision 614706 from John
I'd like to know how many people are using ${plugin.artifacts} in
their plugins.
One here, basically for a use-case similar to MANTRUN-41 on some in-house
plugin.
This would mean that all of a sudden things like maven-plugin-api and
maven-project will start appearing in the result of $
{plugin
MNG-3244 is one of the most popular issues in the queue for 2.0.9 (was
also in 2.0.8 but got bumped). The issue is that url inheritance as
documented says that only urls ending in / will be inherited in the
normal way by appending the artifactid to the end of the url. The
trouble is that fixing it
I'd like to know how many people are using ${plugin.artifacts} in
their plugins.
I just came across a use case for plugin development, where the
developer needs access to the full dependency list for the plugin
using ${plugin.artifacts}. This is a problem because Maven currently
applies a
+1
--
Olivier
2008/3/2, Brett Porter <[EMAIL PROTECTED]>:
> Hi,
>
> The Shade plugin is ready to be released. This is needed for the 2.0.9
> release as well.
>
> We solved 6 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11540&styleName=Html&version=13994
>
> The rem
I follow the directory dev list and help out when I see issues, but haven't
poked through their artifacts like you have been...:)
jesse
On Sun, Mar 2, 2008 at 3:42 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> I'm helping out in Commons.
>
> Wendy Smoak wrote:
> > I've been monitoring the [EM
Hi,
In reviewing the toolchain I had some thoughts about the
implementation and some questions to ask.
Firstly - the toolchains.xml file being separate is handy for working
with current versions of Maven. However, I wonder if this should be
deprecated in future versions and inserted direc
+1 to the currently released artifacts and tag.
I reviewed the code, checked for license headers and checked the
artifact contents.
The only issue I noticed was the missing license inside the JAR - this
is not desirable but not unprecedented. Note that it does have an
embedded POM with th
Hi guys,
where can I find a list of all the official Maven Remote Repositories. I
know there is one on java.net and also on the Ibiblio.org, and, of course,
the repo1.maven.org. I am thinking of making another mirror in Bugaria, but
I am not sure if there is already one.
Thank you.
--
View this
Hi
I have found and fix one problem with Maven Ant plugin. I had worked with
multi-module maven projects and found that Maven Ant plugin generate absolute
path for referenced projects (another modules). Ant doesn't find them during
compilation. So I have fix plugin - it calculates relative path
31 matches
Mail list logo
