Id also like to see these patches merged in.
Thanks
James
On Wed, 2008-02-27 at 10:04 -0600, Paul Gier wrote:
> Hi Everyone,
>
> The resources plugin seems be a bit neglected lately ;), so I took a look
> through the current open issues.
> These issues have relatively simple patches attached:
>
Ok got it. Then +1 to fixing it.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Wednesday, February 27, 2008 11:40 AM
To: Maven Developers List
Subject: Re: [MNG-3410] Plugin managed versions are ignored
On Tue, Feb 26, 2008 at 9:37
Right for rsync, I just asked for the correct format.
2008/2/27, Carlos Sanchez <[EMAIL PROTECTED]>:
>
> In the repo they should have same groupId/artifactId/version and
> change the type
>
> But dont do a bundle. Why don't you put that and the other uploads
> that you usually do in a repo and I'
I just committed partial support for PlexusConfiguration :
- as XML validation is disabled the XML configuration doesn't require to be
in a CDATA section
- the namespaceHandler detects structured configuration and creates a
DomPlexusConfiguration for it.
- Still have to implement DomPlexusConfigur
In the repo they should have same groupId/artifactId/version and
change the type
But dont do a bundle. Why don't you put that and the other uploads
that you usually do in a repo and I'll setup an automatic sync from
there for the groups you contribute
On Wed, Feb 27, 2008 at 1:20 AM, nicolas de l
On Tue, Feb 26, 2008 at 9:37 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
> >I didnt quite understand this. depMngmt in plugins you use is ignored,
> >so how could you override a plugin dependency using this bug?
>
> My understanding of the bug is that if you specify depMgt in _your_
> project
Hi Everyone,
The resources plugin seems be a bit neglected lately ;), so I took a look
through the current open issues.
These issues have relatively simple patches attached:
http://jira.codehaus.org/browse/MRESOURCES-39
http://jira.codehaus.org/browse/MRESOURCES-20
http://jira.codehaus.org/brow
I've solved the main issues, added some tiny doc and unit tests.
Still early alpha code but now stable and ready for review if you want to
test it on Continuum.
Some tests (like DefaultPathParserTest) migrate succesfully to spring
context execution using the PlexusInSpringTestCase without any cha
On Wed, 2008-02-27 at 12:51 +0100, Fabian Christ wrote:
> The problem with the pattern groupId="org.apache.maven.archiva" artifactId= are the missing line
> breaks and spaces. Your can't find the information of interest in such
> a string. So people will start adding line breaks and you get near
Hi there,
I read through this discussion as a Maven user and (sometimes) plugin
developer and also like the idea of more readable POMs. But I also
agree with Jörg's opinion:
> +1 for more readable POMs
>
> I personally like the idea of the attributes because it makes
> it a lot easier to write
I think there could be one not yet discussed drawback of attribute
based pom content.
Most (or all?) xml parsers will not keep track of spacing between
attributes, so any tool that writes the pom (release plugin?) might
mess up formatting..
Disclaimer: I haven't actually checked..
Milos
On Mon,
I have a requirement to add a LGPL lib to our corporate repo.
I'd like to make it also available in maven central.
The lib is jNative (http://sourceforge.net/projects/jNative,
http://jnative.free.fr/SPIP-v1-8-3/)
This is a JNI base library with both a JAR and a dll + so
What is the best-practice
On 26/02/2008, at 9:21 PM, Fabrice Bellingard wrote:
On Mon, Feb 25, 2008 at 3:04 AM, Brett Porter <[EMAIL PROTECTED]>
wrote:
Ok, seems there is some interest in putting together a proposal. I'm
going to follow the same format we used at Continuum last month.
Before we continue to vote on
Brett Porter schrieb:
>
> On 27/02/2008, at 7:13 PM, [EMAIL PROTECTED] wrote:
>
>>
>
> The reason for this is that commons-logging in the root
> classloader makes plugins unhappy (and the error reporting seems
> to be swallowed now)
>> Just out of curiosity, what ver
On 27/02/2008, at 7:13 PM, [EMAIL PROTECTED] wrote:
The reason for this is that commons-logging in the root
classloader makes plugins unhappy (and the error reporting
seems
to be swallowed now)
Just out of curiosity, what version of commons-logging was in use?
Version 1.1 and above shoul
Thanks for the rationale, Jason. My intent was to understand from a
classloading and modularity perspective.
Cheers,
Rahul
Jason van Zyl wrote:
On 26-Feb-08, at 6:29 PM, Rahul Thakur wrote:
On a related note, I have always wondered why Maven was not using
OSGi underneath?
Because i
>>>
>>> The reason for this is that commons-logging in the root
>>> classloader makes plugins unhappy (and the error reporting seems
>>> to be swallowed now)
Just out of curiosity, what version of commons-logging was in use?
Version 1.1 and above should not throw an exception unde
17 matches
Mail list logo
