Re: https://jira.codehaus.org/browse/MNG-1304

[Mark Hobson]

+1

Standardisation on version semantics is key to dependency management.

Mark

On 13 Nov 2012, at 20:38, Jason van Zyl  wrote:

> This is a long-standing issue, but I think a document and standard has 
> emerged that I think is reasonable. How do people feel about trying to adhere 
> to:
> 
> http://semver.org
> 
> and moving toward using this as our standard versioning documentation?
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
> 
> To do two things at once is to do neither.
> 
> -- Publilius Syrus, Roman slave, first century B.C.
> 
> 
> 
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: fixing transfer listener in trunk

[Hervé BOUTEMY]

Le mardi 13 novembre 2012 10:09:51 Jason van Zyl a écrit :
> But again really, I believe the decision is to determine whether all this
> really necessary. I think the order of operations that folks think is
> reasonable is:
> 
> 1) Get the release out with SLF4J
> 2) Determine whether we need logging framework features
> 3) Pick one
> 
> That's what I've gathered from the discussion so I think if we plan that
> route then we can do 3.1.0, and then have the discussions and if we get to
> 3) maybe integrate that into 3.1.1 or 3.1.2.
with 6-weeks releases, this seems reasonable: I personnally need some time to 
test and make a decision based on my experience
now that there is doc about changing implementation, I can start to learn

Regards,

Hervé

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5356 Make encrypt/decrypt logic pluggable

[Anders Hammar]

Ok. I'll see to that she signs a cla.

/Anders (mobile)
Den 13 nov 2012 17:28 skrev "Stephen Connolly" <
stephen.alan.conno...@gmail.com>:

> On 13 November 2012 15:04, Olivier Lamy  wrote:
>
> > 2012/11/13 Anders Hammar :
> > >> Changes looks good for me.
> > >>
> > >
> > > Thanks for having a look!
> > > One specific thing I'm not sure about is the maven-security artifactId.
> > Is
> > > it good, or should we maybe use maven-crypto. maven-security could in
> the
> > > future contain more than the crypto things.
> > >
> > > Most of the large changes has been done Karin Karlsson (can we have cla
> > ?)
> > >>
> > >
> > > I realized that as well. I will get a CLA for Devoteam Sweden in place
> as
> > > she's been doing this as part of her work with Devoteam. I believe
> that's
> > > the proper level of CLA in this case, right?
> >
> > iCLA is mandatory but not CCLA that's only optional (see
> > http://markmail.org/message/4fit2o33yjj5pxyt )
> >
>
> Technically correct, though *Karin* may want the CCLA or at least something
> from Devoteam to say she is ok contributing it under an ICLA that she has
> signed.
>
> We only need the ICLA on file... but the contributor may want to cover
> their own ass... hence they may want the CCLA ;-)
>
>
> >
> > >
> > > Any special reason to use a package org.maven ?
> > >>
> > >> New files doesn't have license header but " //TODO: add copyright "
> > >>
> > >
> > > Yes, there's still some polishing to do here. It's still work in
> > progress.
> > >
> > > /Anders
> > >
> > >
> > >>
> > >> Thanks
> > >> --
> > >> Olivier Lamy
> > >> Talend: http://coders.talend.com
> > >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >>
> > >> --
> > >> Olivier Lamy
> > >> Talend: http://coders.talend.com
> > >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: dev-h...@maven.apache.org
> > >>
> > >>
> >
> >
> >
> > --
> > Olivier Lamy
> > Talend: http://coders.talend.com
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: https://jira.codehaus.org/browse/MNG-1304

[Mark Derricutt]

When using ranges (as one should IMHO) you should never use .0 but always start 
with .1.

So that [1.0.0,2.0.0) actually works, otherwise the range picks up the 
2.0.0-SNAPSHOT.

Mark

On 14/11/2012, at 10:35 AM, Dennis Lundberg  wrote:

> We added one exception though, and that is one that we might want to add
> here as well: we don't require Z if Z == 0. So instead of 2.2.0 you are
> allowed to use 2.2. For Maven core we have followed SemVer strictly, but
> most of our other components omit Z if it is 0, which it often if.

Re: https://jira.codehaus.org/browse/MNG-1304

[Jörg Schaible]

Jason van Zyl wrote:

> This is a long-standing issue, but I think a document and standard has
> emerged that I think is reasonable. How do people feel about trying to
> adhere to:
> 
> http://semver.org
> 
> and moving toward using this as our standard versioning documentation?

Well, it sounds nice, but look at Apache commons and you'll see that it 
fails in practice regarding X. If we had gone from 
org.apache.commons:commons-lang:2.2.1 to org.apache.commons:commons-
lang:3.0.0 we would have been all into jar hell. Therefore a change in X in 
Apache commons means new artifactId and new package name (if we cannot 
provide compatible APIs) to allow 2.x and 3.x version to be used side-by-
side (in classpath and as dependency).

Just my 2¢,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: https://jira.codehaus.org/browse/MNG-1304

[Manfred Moser]

True... separate, but closely related. If we state that semver is the
recommended practice (and I believe that to be a good idea) .. the whole
tooling should work nicely with it. And that includes the use case I
mentioned..

And yes.. maybe the version stuff should be part of core ... and then be
used e.g. by the release plugin as well as the versions plugin and
others..

manfred

On Tue, November 13, 2012 2:05 pm, Robert Scholte wrote:
> These are 2 separate issues. As long as the bugfix/patch-part contains
> non-numeric values and Maven (actually Aether) still does a String match
> (apart from those special cases like alpha, beta, RC) we have to be very
> careful with calculating the next version.
> You could question if this kind of logic belongs in the
> maven-release-plugin, since it is more related to how Maven resolves
> versions.
>
> Robert
>
> Op Tue, 13 Nov 2012 22:22:48 +0100 schreef Manfred Moser
> :
>
>> On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:
>>> This is a long-standing issue, but I think a document and standard has
>>> emerged that I think is reasonable. How do people feel about trying to
>>> adhere to:
>>>
>>> http://semver.org
>>>
>>> and moving toward using this as our standard versioning documentation?
>>
>> I think that would be awesome. One of the things we would have to do is
>> fix the release plugin to work with 1.2.3-RC.2 as compared to 1.2.3-RC2.
>> Currently it does not correctly suggest the next version being
>> 1.2.3-RC.3
>> but rather goes to 1.2.4-RC.2
>>
>> This would also make it easier to explain the reasoning for the version
>> numbering since we could just point to the external docs as a best
>> practice.
>>
>> manfred
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: https://jira.codehaus.org/browse/MNG-1304

[Robert Scholte]

These are 2 separate issues. As long as the bugfix/patch-part contains  
non-numeric values and Maven (actually Aether) still does a String match  
(apart from those special cases like alpha, beta, RC) we have to be very  
careful with calculating the next version.
You could question if this kind of logic belongs in the  
maven-release-plugin, since it is more related to how Maven resolves  
versions.


Robert

Op Tue, 13 Nov 2012 22:22:48 +0100 schreef Manfred Moser  
:



On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:

This is a long-standing issue, but I think a document and standard has
emerged that I think is reasonable. How do people feel about trying to
adhere to:

http://semver.org

and moving toward using this as our standard versioning documentation?


I think that would be awesome. One of the things we would have to do is
fix the release plugin to work with 1.2.3-RC.2 as compared to 1.2.3-RC2.
Currently it does not correctly suggest the next version being 1.2.3-RC.3
but rather goes to 1.2.4-RC.2

This would also make it easier to explain the reasoning for the version
numbering since we could just point to the external docs as a best
practice.

manfred

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: https://jira.codehaus.org/browse/MNG-1304

[Dennis Lundberg]

On 2012-11-13 21:38, Jason van Zyl wrote:
> This is a long-standing issue, but I think a document and standard has 
> emerged that I think is reasonable. How do people feel about trying to adhere 
> to:
> 
> http://semver.org
> 
> and moving toward using this as our standard versioning documentation?

SemVer is good. We moved from Apache commons versioning guidelines to
Semver 1.0.0 @work a while back.

We added one exception though, and that is one that we might want to add
here as well: we don't require Z if Z == 0. So instead of 2.2.0 you are
allowed to use 2.2. For Maven core we have followed SemVer strictly, but
most of our other components omit Z if it is 0, which it often if.

SemVer 1.0.0 is simpler than 2.0.0-rc.1 in that it does not cover
pre-releases or build numbers. Our current model sort of covers
pre-releases, but it doesn't cover build numbers very well.

> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
> 
> To do two things at once is to do neither.
>  
>  -- Publilius Syrus, Roman slave, first century B.C.
> 
> 
> 
> 
> 
> 


-- 
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: https://jira.codehaus.org/browse/MNG-1304

[Manfred Moser]

On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:
> This is a long-standing issue, but I think a document and standard has
> emerged that I think is reasonable. How do people feel about trying to
> adhere to:
>
> http://semver.org
>
> and moving toward using this as our standard versioning documentation?

I think that would be awesome. One of the things we would have to do is
fix the release plugin to work with 1.2.3-RC.2 as compared to 1.2.3-RC2.
Currently it does not correctly suggest the next version being 1.2.3-RC.3
but rather goes to 1.2.4-RC.2

This would also make it easier to explain the reasoning for the version
numbering since we could just point to the external docs as a best
practice.

manfred

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: https://jira.codehaus.org/browse/MNG-1304

[Tamás Cservenák]

+1


On Tue, Nov 13, 2012 at 9:38 PM, Jason van Zyl  wrote:

> This is a long-standing issue, but I think a document and standard has
> emerged that I think is reasonable. How do people feel about trying to
> adhere to:
>
> http://semver.org
>
> and moving toward using this as our standard versioning documentation?
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> To do two things at once is to do neither.
>
>  -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>

https://jira.codehaus.org/browse/MNG-1304

[Jason van Zyl]

This is a long-standing issue, but I think a document and standard has emerged 
that I think is reasonable. How do people feel about trying to adhere to:

http://semver.org

and moving toward using this as our standard versioning documentation?

Thanks,

Jason

--
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

To do two things at once is to do neither.
 
 -- Publilius Syrus, Roman slave, first century B.C.

Re: Maven Confluence

[Jason van Zyl]

Cool, I'll sync up with Hervé and one of us will release it.

On Nov 13, 2012, at 3:14 PM, Dennis Lundberg  wrote:

> I've assigned the issue to me.
> The fix on the Maven side is to use a newer Modello Plugin version.
> 
> On 2012-11-13 21:04, Jason van Zyl wrote:
>> Currently that is unassigned which brings up the issue as to whether that 
>> issue should be there.
>> 
>> Anything that is not assigned means no one plans to work on them and we 
>> should push them back in the pool.
>> 
>> If you want to fix that I can work with Hervé to see who wants to push out a 
>> Modello release if necessary.
>> 
>> On Nov 13, 2012, at 2:42 PM, Dennis Lundberg  wrote:
>> 
>>> On 2012-11-13 19:45, Jason van Zyl wrote:
 There, I just added a couple macros and lined out the proposed roadmap 
 given the feedback.
 
 https://cwiki.apache.org/confluence/display/MAVEN/Roadmap
>>> 
>>> Jason,
>>> 
>>> If you have a few cycles, could you have a look at releasing Modello? We
>>> need a new Modello release for
>>> http://jira.codehaus.org/browse/MNG-5336
>>> which is scheduled for 3.1.0.
>>> 
 
 On Nov 13, 2012, at 12:02 PM, Jason van Zyl  wrote:
 
> Dan helped me reset my password so I'm good. I'll work on the roadmap now.
> 
> On Nov 13, 2012, at 10:44 AM, Benson Margulies  
> wrote:
> 
>> On Tue, Nov 13, 2012 at 10:42 AM, Jason van Zyl  wrote:
>> 
>>> Does this instance use for authentication? I tried my LDAP password and
>>> that doesn't seem to work.
>>> 
>> 
>> I don't think it uses ldap. Have you tried password recovery?
>> 
>> 
>>> 
>>> I'm trying to make a roadmap page for the proposed schedule for the next
>>> three releases so people can see it easier than trying to surf JIRA.
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> --
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> -
>>> 
>>> We know what we are, but know not what we may be.
>>> 
>>> -- Shakespeare
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
> 
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
> 
> -- Jakob Burckhardt
> 
> 
> 
> 
> 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder & CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 There's no sense in being precise when you don't even know what you're 
 talking about.
 
 -- John von Neumann
 
 
 
 
 
 
>>> 
>>> 
>>> -- 
>>> Dennis Lundberg
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>> 
>> In short, man creates for himself a new religion of a rational
>> and technical order to justify his work and to be justified in it.
>> 
>>  -- Jacques Ellul, The Technological Society
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Dennis Lundberg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

Release Planning and Roadmap

[Jason van Zyl]

I have put together a simple roadmap using JIRA macros in Confluence to try and 
communicate to users what we're planning to do.

https://cwiki.apache.org/confluence/display/MAVEN/Roadmap

There are several issues in the 3.1.0 list that are unassigned, so as a matter 
of course if you want to work on it just assign it to yourself and the stuff 
that isn't assigned should just get pulled out and pushed back to the 3.1.x 
pool. For the folks who popped up to say they wanted to look at particular 
issues I made the assignment. So take a look and if you do, or don't, want to 
do something then change the assignment. 

I picked a tentative date of November 26th for the 3.1.0 and I think we just 
time box it, get done what we can and move on. I'd like to try and get back to 
making core releases every 6 weeks, if at all possible.

Thanks,

Jason

--
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

There's no sense in being precise when you don't even know what you're talking 
about.

 -- John von Neumann

Re: Maven Confluence

[Dennis Lundberg]

I've assigned the issue to me.
The fix on the Maven side is to use a newer Modello Plugin version.

On 2012-11-13 21:04, Jason van Zyl wrote:
> Currently that is unassigned which brings up the issue as to whether that 
> issue should be there.
> 
> Anything that is not assigned means no one plans to work on them and we 
> should push them back in the pool.
> 
> If you want to fix that I can work with Hervé to see who wants to push out a 
> Modello release if necessary.
> 
> On Nov 13, 2012, at 2:42 PM, Dennis Lundberg  wrote:
> 
>> On 2012-11-13 19:45, Jason van Zyl wrote:
>>> There, I just added a couple macros and lined out the proposed roadmap 
>>> given the feedback.
>>>
>>> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap
>>
>> Jason,
>>
>> If you have a few cycles, could you have a look at releasing Modello? We
>> need a new Modello release for
>> http://jira.codehaus.org/browse/MNG-5336
>> which is scheduled for 3.1.0.
>>
>>>
>>> On Nov 13, 2012, at 12:02 PM, Jason van Zyl  wrote:
>>>
 Dan helped me reset my password so I'm good. I'll work on the roadmap now.

 On Nov 13, 2012, at 10:44 AM, Benson Margulies  
 wrote:

> On Tue, Nov 13, 2012 at 10:42 AM, Jason van Zyl  wrote:
>
>> Does this instance use for authentication? I tried my LDAP password and
>> that doesn't seem to work.
>>
>
> I don't think it uses ldap. Have you tried password recovery?
>
>
>>
>> I'm trying to make a roadmap page for the proposed schedule for the next
>> three releases so people can see it easier than trying to surf JIRA.
>>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>>
>> We know what we are, but know not what we may be.
>>
>> -- Shakespeare
>>
>>
>>
>>
>>
>>

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder & CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 A party which is not afraid of letting culture,
 business, and welfare go to ruin completely can
 be omnipotent for a while.

 -- Jakob Burckhardt





>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> --
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> -
>>>
>>> There's no sense in being precise when you don't even know what you're 
>>> talking about.
>>>
>>> -- John von Neumann
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> -- 
>> Dennis Lundberg
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
> 
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
> 
>   -- Jacques Ellul, The Technological Society
> 
> 
> 
> 
> 
> 


-- 
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Confluence

[Jason van Zyl]

Currently that is unassigned which brings up the issue as to whether that issue 
should be there.

Anything that is not assigned means no one plans to work on them and we should 
push them back in the pool.

If you want to fix that I can work with Hervé to see who wants to push out a 
Modello release if necessary.

On Nov 13, 2012, at 2:42 PM, Dennis Lundberg  wrote:

> On 2012-11-13 19:45, Jason van Zyl wrote:
>> There, I just added a couple macros and lined out the proposed roadmap given 
>> the feedback.
>> 
>> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap
> 
> Jason,
> 
> If you have a few cycles, could you have a look at releasing Modello? We
> need a new Modello release for
> http://jira.codehaus.org/browse/MNG-5336
> which is scheduled for 3.1.0.
> 
>> 
>> On Nov 13, 2012, at 12:02 PM, Jason van Zyl  wrote:
>> 
>>> Dan helped me reset my password so I'm good. I'll work on the roadmap now.
>>> 
>>> On Nov 13, 2012, at 10:44 AM, Benson Margulies  
>>> wrote:
>>> 
 On Tue, Nov 13, 2012 at 10:42 AM, Jason van Zyl  wrote:
 
> Does this instance use for authentication? I tried my LDAP password and
> that doesn't seem to work.
> 
 
 I don't think it uses ldap. Have you tried password recovery?
 
 
> 
> I'm trying to make a roadmap page for the proposed schedule for the next
> three releases so people can see it easier than trying to surf JIRA.
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
> 
> We know what we are, but know not what we may be.
> 
> -- Shakespeare
> 
> 
> 
> 
> 
> 
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> --
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> -
>>> 
>>> A party which is not afraid of letting culture,
>>> business, and welfare go to ruin completely can
>>> be omnipotent for a while.
>>> 
>>> -- Jakob Burckhardt
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>> 
>> There's no sense in being precise when you don't even know what you're 
>> talking about.
>> 
>> -- John von Neumann
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Dennis Lundberg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society

Re: Maven Confluence

[Dennis Lundberg]

On 2012-11-13 19:45, Jason van Zyl wrote:
> There, I just added a couple macros and lined out the proposed roadmap given 
> the feedback.
> 
> https://cwiki.apache.org/confluence/display/MAVEN/Roadmap

Jason,

If you have a few cycles, could you have a look at releasing Modello? We
need a new Modello release for
http://jira.codehaus.org/browse/MNG-5336
which is scheduled for 3.1.0.

> 
> On Nov 13, 2012, at 12:02 PM, Jason van Zyl  wrote:
> 
>> Dan helped me reset my password so I'm good. I'll work on the roadmap now.
>>
>> On Nov 13, 2012, at 10:44 AM, Benson Margulies  wrote:
>>
>>> On Tue, Nov 13, 2012 at 10:42 AM, Jason van Zyl  wrote:
>>>
 Does this instance use for authentication? I tried my LDAP password and
 that doesn't seem to work.

>>>
>>> I don't think it uses ldap. Have you tried password recovery?
>>>
>>>

 I'm trying to make a roadmap page for the proposed schedule for the next
 three releases so people can see it easier than trying to surf JIRA.

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder & CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 We know what we are, but know not what we may be.

 -- Shakespeare






>>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>>
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>>
>>  -- Jakob Burckhardt
>>
>>
>>
>>
>>
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
> 
> There's no sense in being precise when you don't even know what you're 
> talking about.
> 
>  -- John von Neumann
> 
> 
> 
> 
> 
> 


-- 
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Confluence

[Jason van Zyl]

There, I just added a couple macros and lined out the proposed roadmap given 
the feedback.

https://cwiki.apache.org/confluence/display/MAVEN/Roadmap

On Nov 13, 2012, at 12:02 PM, Jason van Zyl  wrote:

> Dan helped me reset my password so I'm good. I'll work on the roadmap now.
> 
> On Nov 13, 2012, at 10:44 AM, Benson Margulies  wrote:
> 
>> On Tue, Nov 13, 2012 at 10:42 AM, Jason van Zyl  wrote:
>> 
>>> Does this instance use for authentication? I tried my LDAP password and
>>> that doesn't seem to work.
>>> 
>> 
>> I don't think it uses ldap. Have you tried password recovery?
>> 
>> 
>>> 
>>> I'm trying to make a roadmap page for the proposed schedule for the next
>>> three releases so people can see it easier than trying to surf JIRA.
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> --
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> -
>>> 
>>> We know what we are, but know not what we may be.
>>> 
>>> -- Shakespeare
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
> 
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
> 
>  -- Jakob Burckhardt
> 
> 
> 
> 
> 

Thanks,

Jason

--
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

There's no sense in being precise when you don't even know what you're talking 
about.

 -- John von Neumann

Re: fixing transfer listener in trunk

[Igor Fedorenko]

On 12-11-12 9:29 AM, Olivier Lamy wrote:

2012/11/12 Igor Fedorenko :



On 12-11-11 6:52 PM, Olivier Lamy wrote:


If the discussion is now transitioning to users want flexible
logging and the choice of a logging framework that's fine. But I
still maintain the CLI use of logging can be limited and
constrained while allowing integrators to make the small changes
necessary to add flexible logging. But if we want to choose a
framework let's look at the options, if people want to go that
route, and select the best option.


Integrators ? Again what do you mean with that ? I don't understand
why the default Apache Maven couldn't be able to propose a default
advanced logging implementation. The size of the jars is around 500K
so frankly I don't see that as a blocking issue as we already
download internet:-). (and perso I'd like  to test some ideas using
jansi for possible colorized logging) And I don't understand why we
must wait folks doing alternate distributions providing this
feature.



m2e uses logback and switching to another slf4j provider will be
extremely expansive if not impossible at this point. I believe
downstream m2e consumers like JBoss Tools and Spring Tool Suite are in
the same position. We already repackage Maven as part of m2e build, so
removing slf4j-simple or log4j will not a problem, at least as long as
Maven core functionality only uses slf4j and does not depend on
specific logging library.

Yup that's the case core will only use slf4j api (except some sys
props) Perso I don't want we go in dependant logging framework model.
So m2e wont' need to change something.

AFAICS I don't see that as a real problem it's just a matter of
removing/replacing some jars (maybe that will be more easy than you do
today)
Maybe I miss something ?



No, no problems as long as maven core only depends on slf4j.

--
Regards,
Igor

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Tentative release planning for 3.1.x

[Larry Shatzer, Jr.]

On Tue, Nov 13, 2012 at 10:02 AM, Jesse Glick  wrote:

> On 11/12/2012 02:00 PM, Dennis Lundberg wrote:
>
>> I had a quick look at the Windows ITs and the problem seems to be that
>> Maven/Jenkins is unable to delete files. This looks like a Windows path
>> length issue, because the path it complain about is 264 chars long.
>>
>
> JENKINS-15418 [1] was fixed in 1.489, FYI.
>
> [1] 
> https://issues.jenkins-ci.org/**browse/JENKINS-15418
>
>
However, JENKINS-15367 [1] is still not fixed, I think the reason Jenkins
is still 1.480 at Apache. (There is a pull request [2] to fix it, just
needs someone with enough karma to apply it)

[1] https://issues.jenkins-ci.org/browse/JENKINS-15367
[2] https://github.com/jenkinsci/jenkins/pull/609

-- Larry

Re: Tentative release planning for 3.1.x

[Jesse Glick]

On 11/12/2012 02:00 PM, Dennis Lundberg wrote:

I had a quick look at the Windows ITs and the problem seems to be that
Maven/Jenkins is unable to delete files. This looks like a Windows path
length issue, because the path it complain about is 264 chars long.


JENKINS-15418 [1] was fixed in 1.489, FYI.

[1] https://issues.jenkins-ci.org/browse/JENKINS-15418


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Confluence

[Jason van Zyl]

Dan helped me reset my password so I'm good. I'll work on the roadmap now.

On Nov 13, 2012, at 10:44 AM, Benson Margulies  wrote:

> On Tue, Nov 13, 2012 at 10:42 AM, Jason van Zyl  wrote:
> 
>> Does this instance use for authentication? I tried my LDAP password and
>> that doesn't seem to work.
>> 
> 
> I don't think it uses ldap. Have you tried password recovery?
> 
> 
>> 
>> I'm trying to make a roadmap page for the proposed schedule for the next
>> three releases so people can see it easier than trying to surf JIRA.
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>> 
>> We know what we are, but know not what we may be.
>> 
>>  -- Shakespeare
>> 
>> 
>> 
>> 
>> 
>> 

Thanks,

Jason

--
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

  -- Jakob Burckhardt

Re: MNG-5356 Make encrypt/decrypt logic pluggable

[Stephen Connolly]

On 13 November 2012 15:04, Olivier Lamy  wrote:

> 2012/11/13 Anders Hammar :
> >> Changes looks good for me.
> >>
> >
> > Thanks for having a look!
> > One specific thing I'm not sure about is the maven-security artifactId.
> Is
> > it good, or should we maybe use maven-crypto. maven-security could in the
> > future contain more than the crypto things.
> >
> > Most of the large changes has been done Karin Karlsson (can we have cla
> ?)
> >>
> >
> > I realized that as well. I will get a CLA for Devoteam Sweden in place as
> > she's been doing this as part of her work with Devoteam. I believe that's
> > the proper level of CLA in this case, right?
>
> iCLA is mandatory but not CCLA that's only optional (see
> http://markmail.org/message/4fit2o33yjj5pxyt )
>

Technically correct, though *Karin* may want the CCLA or at least something
from Devoteam to say she is ok contributing it under an ICLA that she has
signed.

We only need the ICLA on file... but the contributor may want to cover
their own ass... hence they may want the CCLA ;-)


>
> >
> > Any special reason to use a package org.maven ?
> >>
> >> New files doesn't have license header but " //TODO: add copyright "
> >>
> >
> > Yes, there's still some polishing to do here. It's still work in
> progress.
> >
> > /Anders
> >
> >
> >>
> >> Thanks
> >> --
> >> Olivier Lamy
> >> Talend: http://coders.talend.com
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >> --
> >> Olivier Lamy
> >> Talend: http://coders.talend.com
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Markdown in the site plugin

[Olivier Lamy]

2012/11/13 Jason van Zyl :
> I can just checkin the markdown source into svn. Others are using the site 
> plugin from trunk so someone can publish it.
Using markdown doesn't need site plugin trunk.
It's just a matter of adding the doxia module in the site plugin
dependencies (http://maven.apache.org/doxia/references/index.html)
It looks Hervé already did that.

>
> On Nov 12, 2012, at 10:05 PM, Hervé BOUTEMY  wrote:
>
>> Le samedi 10 novembre 2012 14:52:38 Jason van Zyl a écrit :
>>> Ok, I'll just keep using my Github pages for now until it's supported.
>>> Thanks.
>> where do you want it, so we can work together on slf4j docs?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Confluence

[Benson Margulies]

On Tue, Nov 13, 2012 at 10:42 AM, Jason van Zyl  wrote:

> Does this instance use for authentication? I tried my LDAP password and
> that doesn't seem to work.
>

I don't think it uses ldap. Have you tried password recovery?


>
> I'm trying to make a roadmap page for the proposed schedule for the next
> three releases so people can see it easier than trying to surf JIRA.
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> We know what we are, but know not what we may be.
>
>   -- Shakespeare
>
>
>
>
>
>

Maven Confluence

[Jason van Zyl]

Does this instance use for authentication? I tried my LDAP password and that 
doesn't seem to work. 

I'm trying to make a roadmap page for the proposed schedule for the next three 
releases so people can see it easier than trying to surf JIRA.

Thanks,

Jason

--
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

We know what we are, but know not what we may be.

  -- Shakespeare

Re: fixing transfer listener in trunk

[Jason van Zyl]

On Nov 12, 2012, at 9:21 AM, Olivier Lamy  wrote:

> 
> Currently I'm testing integrating jansi to have colorized output, that
> works fine and that's fun :-)
> Again I don't see why we couldn't add a bit or a possibility of fun
> within our distribution (or at least make that easily possible)

Sure, pretty easy with Logback: 
http://logback.qos.ch/manual/layouts.html#coloring

If that is really the only feature then there is another provider that just 
does the coloring: https://github.com/jdillon/gossip

But again really, I believe the decision is to determine whether all this 
really necessary. I think the order of operations that folks think is 
reasonable is:

1) Get the release out with SLF4J
2) Determine whether we need logging framework features
3) Pick one

That's what I've gathered from the discussion so I think if we plan that route 
then we can do 3.1.0, and then have the discussions and if we get to 3) maybe 
integrate that into 3.1.1 or 3.1.2.

Sound reasonable. 

>> 
>> Then we should ship this in its current form, discuss whether we need 
>> advanced logging, and then look at the implementations. I have one using 
>> Logback and I think that solution is more mature, and has a community and 
>> used heavily, even by many other Apache projects. I looked at Log4j2 and 
>> there are 2 people essentially (and one fellow with 2 commits) and I'm not 
>> sure how the project started but I don't think it even passes Apache 
>> Incubator standards. At first blush I don't see log4j2 as a good choice. 
>> Hence, I agree, a discussion is required. But I think we might arrive at the 
>> conclusion a logging framework is not necessary.
>> 

> IMHO the number of contributors is not a good argument.

Let's call it the ecosystem factor then. I consider users and contributors the 
most important there. As a library is nothing without users because a library 
with users generally has developers even if the library has reached maturity. A 
library with only developers and not many users isn't very valuable overall as 
there is really no ecosystem.

> How many people really contributed to sisu

There is only one alternative in the world for Sisu and that's Plexus. But at 
the core of Sisu is Guice which has a vast ecosystem. I don't think anyone will 
disagree it was a good choice to get off Plexus and use Sisu with the emulation 
layer it provides. Guice has had 5-10 developers at any given point in time and 
the technology is evolving in the form of Dagger by Square. So Sisu is unique 
in what it does, but Guice is not. We picked a solid base with a good ecosystem 
to build on. Maven 3.x is actually a testament to how flexible Guice is and how 
responsible they were to absorbing our many changes to make it work. None of 
this would have worked without a lot of work and help from many people. Guice 
is mature, has lots of users, actively developed and evolving.

In this case we are talking about the exact opposite. We have the most mature 
SLF4J provider with a history, users, lots of forks and pull requests and is 
pretty much becoming the de facto standard. On the other side you have a 
logging framework that no one really uses in comparison. There is a completely 
mature alternative.

> or aether ?

Again, what's the alternative to choose from? Both Aether and Sisu required a 
lot of specialized work for Maven. No one else really has time or energy to do 
these things. It's not commodity infrastructure like DI or logging.

> And those
> libraries are more core part of maven than a logging framework.
> What you call integrators can easily change it (as core will only use
> slf4j api and no framework specific except maybe some sys props as
> it's already the case with your changes using slf4j-simple) but AFAIK
> that's not possible for those libraries !
> I just have a look at the impact graphs in github and frankly not a
> lot of people contributed to those libraries.
> 
> At least with log4j2 we will have a framework maintained by the Apache
> community so I think number of contributors will grow..
> 

That's speculation and empirically from the stats that doesn't look to be the 
case:

http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging

Ceki is still the largest contributor in that community and he's not there 
anymore.

I'm personally not in favor of giving an unproven library like log4j2 
undeserved legitimacy by being used in Maven when Logback exists. No one is 
working on log4j really anymore so how can you say that work will continue with 
log4j2? And the only guy really still working on log4j is not really working on 
log4j2?

http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Ftrunk

I just don't see using log4j2 making much sense.

At any rate, can we agree on the plan above and table the discussion of whether 
we need a framework and the possibly selection of one until 3.1.1/2? That gives 
us time to discuss and create example implementations if the outcome of th

Re: MNG-5356 Make encrypt/decrypt logic pluggable

[Olivier Lamy]

2012/11/13 Anders Hammar :
>> Changes looks good for me.
>>
>
> Thanks for having a look!
> One specific thing I'm not sure about is the maven-security artifactId. Is
> it good, or should we maybe use maven-crypto. maven-security could in the
> future contain more than the crypto things.
>
> Most of the large changes has been done Karin Karlsson (can we have cla ?)
>>
>
> I realized that as well. I will get a CLA for Devoteam Sweden in place as
> she's been doing this as part of her work with Devoteam. I believe that's
> the proper level of CLA in this case, right?

iCLA is mandatory but not CCLA that's only optional (see
http://markmail.org/message/4fit2o33yjj5pxyt )

>
> Any special reason to use a package org.maven ?
>>
>> New files doesn't have license header but " //TODO: add copyright "
>>
>
> Yes, there's still some polishing to do here. It's still work in progress.
>
> /Anders
>
>
>>
>> Thanks
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[ANN] Maven Invoker 2.1.1 Released

[Robert Scholte]

The Maven team is pleased to announce the release of the Maven Invoker,  
version 2.1.1


With this component it is possible to programmatically invoke Maven.

http://maven.apache.org/shared/maven-invoker/

To use the Maven Invoker, add the following dependency to your project:

  
org.apache.maven.shared
maven-invoker
2.1.1
  


Release Notes - Maven Shared Components - Version maven-invoker-2.1.1

** Bug
* [MSHARED-259] - maven-invoker-2.1 is missing components.xml



Enjoy,

-The Maven team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

MNG-5356 Make encrypt/decrypt logic pluggable

[Olivier Lamy]

Changes looks good for me.

Most of the large changes has been done Karin Karlsson (can we have cla ?)

Any special reason to use a package org.maven ?

New files doesn't have license header but " //TODO: add copyright "

Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5356 Make encrypt/decrypt logic pluggable

[Stephen Connolly]

On 13 November 2012 11:28, Anders Hammar  wrote:

> > Changes looks good for me.
> >
>
> Thanks for having a look!
> One specific thing I'm not sure about is the maven-security artifactId. Is
> it good, or should we maybe use maven-crypto. maven-security could in the
> future contain more than the crypto things.
>
> Most of the large changes has been done Karin Karlsson (can we have cla ?)
> >
>
> I realized that as well. I will get a CLA for Devoteam Sweden in place as
> she's been doing this as part of her work with Devoteam. I believe that's
> the proper level of CLA in this case, right?
>

I think we'll need a cCLA from Devoteam and an ICLA from her


>
> Any special reason to use a package org.maven ?
> >
> > New files doesn't have license header but " //TODO: add copyright "
> >
>
> Yes, there's still some polishing to do here. It's still work in progress.
>
> /Anders
>
>
> >
> > Thanks
> > --
> > Olivier Lamy
> > Talend: http://coders.talend.com
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
> > --
> > Olivier Lamy
> > Talend: http://coders.talend.com
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Maven Compiler 3.0 plugin release

[Anders Hammar]

> So I need to release too maven-shared-incremental.
> Any issue with that ?
>

No problem. As we're jumping to v3.0 I think it's good if we can get as
much news as possible in this release. As long as we think it's safe that
is. I take it maven-shared-incremental is ready to ship then? Hasn't been
much noise around it but the initial discussion. Haven't been involved so
it's just the view of a bystander.

/Anders


>
> 2012/11/12 Anders Hammar :
> > I'm done. Please go ahead and release it!
> >
> > /Anders
> >
> >
> > On Mon, Nov 12, 2012 at 8:22 AM, Anders Hammar 
> wrote:
> >
> >> Give me some hours, I think there's at least one JIRA ticket that I want
> >> to close as fixed.
> >>
> >> /Anders
> >>
> >>
> >>
> >> On Mon, Nov 12, 2012 at 1:03 AM, Olivier Lamy  wrote:
> >>
> >>> Hi,
> >>> Some improvements has been made for compiler plugin.
> >>> Thanks to all folks who participate !
> >>> So now the compiler will use javax.tools (if available) btw it's
> >>> possible to block this new feature to use the old stuff with javac
> >>>
> >>> As a remember for early testers it's available here:
> >>> https://repository.apache.org/content/repositories/snapshots/
> >>> (3.0-SNAPSHOT)
> >>>
> >>> So I'd like to release it (any objections ?)
> >>>
> >>> Thanks,
> >>> --
> >>> Olivier Lamy
> >>> Talend: http://coders.talend.com
> >>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>>
> >>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [RESULT] [VOTE] Release Maven Invoker version 2.1.1

[Robert Scholte]

Hi,
The vote has passed with the following result :

+1 (binding): Robert Scholte, Olivier Lamy, Hervé BOUTEMY
+1 (non binding): Tony Chemit

I will promote the artifacts to the central repo.


Op Thu, 08 Nov 2012 23:53:00 +0100 schreef Robert Scholte  
:



Hi,

We solved 1 issue:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&version=18927&styleName=Html

There are still 2 issues left in JIRA:
http://jira.codehaus.org/browse/MSHARED/component/13271

Staging repo:
https://repository.apache.org/content/repositories/maven-032/
https://repository.apache.org/content/repositories/maven-032/org/apache/maven/shared/maven-invoker/2.1.1/maven-invoker-2.1.1-source-release.zip

Staging site:
http://maven.apache.org/shared/maven-invoker-2.1.1/ (once synced)

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1


thanks,

Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: fixing transfer listener in trunk

[Olivier Lamy]

2012/11/12 Igor Fedorenko :
>
>
> On 12-11-11 6:52 PM, Olivier Lamy wrote:
>>>
>>> If the discussion is now transitioning to users want flexible
>>> logging and the choice of a logging framework that's fine. But I
>>> still maintain the CLI use of logging can be limited and
>>> constrained while allowing integrators to make the small changes
>>> necessary to add flexible logging. But if we want to choose a
>>> framework let's look at the options, if people want to go that
>>> route, and select the best option.
>>
>> Integrators ? Again what do you mean with that ? I don't understand
>> why the default Apache Maven couldn't be able to propose a default
>> advanced logging implementation. The size of the jars is around 500K
>> so frankly I don't see that as a blocking issue as we already
>> download internet:-). (and perso I'd like  to test some ideas using
>> jansi for possible colorized logging) And I don't understand why we
>> must wait folks doing alternate distributions providing this
>> feature.
>>
>
> m2e uses logback and switching to another slf4j provider will be
> extremely expansive if not impossible at this point. I believe
> downstream m2e consumers like JBoss Tools and Spring Tool Suite are in
> the same position. We already repackage Maven as part of m2e build, so
> removing slf4j-simple or log4j will not a problem, at least as long as
> Maven core functionality only uses slf4j and does not depend on
> specific logging library.
Yup that's the case core will only use slf4j api (except some sys
props) Perso I don't want we go in dependant logging framework model.
So m2e wont' need to change something.

AFAICS I don't see that as a real problem it's just a matter of
removing/replacing some jars (maybe that will be more easy than you do
today)
Maybe I miss something ?

>
> --
> Regards,
> Igor
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: plexus-utils / maven-shared-utils / commons-io

[Karl Heinz Marbaise]

Hi Stephen,

> What is the minimum version of Maven that you are supporting your plugin
> on?
> 
> Maven 2.0.x => JDK 1.4 is the theoretical minimum
> Maven 2.2.x => JDK 1.5 is the theoretical minimum

Currently i would like to keep the support for Maven 2.0.X with the 
appassembler-maven-plugin (for the 1.4 release; I can break it with 2.0 
release).

> >
> > Are there any particular reasons not to to use commons-io package
> directly
> > (as a dependency for a plugin)?
> >
> 
>  In a plugin, no reason at all. In fact it is probably the best idea!

So my decision will be to use commons-io directly instead of plexus-utils nor 
maven-shared-utils.

> > Can someone enlighten me a little bit?
> >
> >
> Hope I have
Thanks very much ...The bulp is very bright ;-)

Kind regards
Karl-Heinz Marbaise
-- 
MfG
Karl Heinz Marbaise
-- 
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: plexus-utils / maven-shared-utils / commons-io

[Gary Gregory]

On Tue, Nov 13, 2012 at 3:23 AM, Karl Heinz Marbaise wrote:

> Hi,
>
> i have a question concerning the plexus-utils/maven-shared-utils. During
> the investigation of a bug in appassembler-plugin (
> http://jira.codehaus.org/browse/MAPPASM-187). I have seen that in
> plexus-utils (3.0.7) the method FileUtils.copyDirectory() seemed to be not
> working. The same as in maven-shared-utils. After checking
> maven-shared-utils (0.1) i have detected that the unit tests which are
> checking the copyDirectory part a currently set to @Ignore.
>
> I have found a solution in using commons-io package (2.4) but this would
> result in a JDK 1.5+ dependency (Does someone know a version of commons-io
> which works with JDK 1.4+?


Commons IO 2.4 requires Java 6
Commons IO 2.0 requires Java 5
Commons IO 1.4 requires Java 1.3

Gary


> . The other question is why we don't use commons-io directly (apart of the
> optional dependency in maven-shared-utils) instead of rewriting things in
> maven-shared-utils or did i misunderstand the intention of
> maven-shared-utils?
>
> Are there any particular reasons not to to use commons-io package directly
> (as a dependency for a plugin)?
>
> Can someone enlighten me a little bit?
>
> Thanks in advance.
>
> Kind regards
> Karl-Heinz Marbaise
> --
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
> Hauptstrasse 177 USt.IdNr: DE191347579
> 52146 Würselen   http://www.soebes.de
>
>
>
> --
> --
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
> Hauptstrasse 177 USt.IdNr: DE191347579
> 52146 Würselen   http://www.soebes.de
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Maven Compiler 3.0 plugin release

[Olivier Lamy]

2012/11/12 Anders Hammar :
> Give me some hours, I think there's at least one JIRA ticket that I want to
> close as fixed.
Sure no problem.
>
> /Anders
>
>
> On Mon, Nov 12, 2012 at 1:03 AM, Olivier Lamy  wrote:
>
>> Hi,
>> Some improvements has been made for compiler plugin.
>> Thanks to all folks who participate !
>> So now the compiler will use javax.tools (if available) btw it's
>> possible to block this new feature to use the old stuff with javac
>>
>> As a remember for early testers it's available here:
>> https://repository.apache.org/content/repositories/snapshots/
>> (3.0-SNAPSHOT)
>>
>> So I'd like to release it (any objections ?)
>>
>> Thanks,
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Compiler 3.0 plugin release

[Olivier Lamy]

So I need to release too maven-shared-incremental.
Any issue with that ?

2012/11/12 Anders Hammar :
> I'm done. Please go ahead and release it!
>
> /Anders
>
>
> On Mon, Nov 12, 2012 at 8:22 AM, Anders Hammar  wrote:
>
>> Give me some hours, I think there's at least one JIRA ticket that I want
>> to close as fixed.
>>
>> /Anders
>>
>>
>>
>> On Mon, Nov 12, 2012 at 1:03 AM, Olivier Lamy  wrote:
>>
>>> Hi,
>>> Some improvements has been made for compiler plugin.
>>> Thanks to all folks who participate !
>>> So now the compiler will use javax.tools (if available) btw it's
>>> possible to block this new feature to use the old stuff with javac
>>>
>>> As a remember for early testers it's available here:
>>> https://repository.apache.org/content/repositories/snapshots/
>>> (3.0-SNAPSHOT)
>>>
>>> So I'd like to release it (any objections ?)
>>>
>>> Thanks,
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

maven-surefire pull request: [SUREFIRE-927] Added support for TestNG config...

[kobikis]

GitHub user kobikis opened a pull request:

https://github.com/apache/maven-surefire/pull/9

[SUREFIRE-927] Added support for TestNG configuration configFailurePolicy

configFailurePolicy - Whether TestNG should continue to execute the 
remaining tests in the suite or skip them if an @Before* method fails.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kobikis/maven-surefire master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/9.patch


commit b2137f25c434cbc468e2aa043ddcfdfaab1693a3
Author: kobikis 
Date:   2012-11-13T11:47:43Z

[SUREFIRE-927] Added support for TestNG configuration configFailurePolicy
configFailurePolicy - Whether TestNG should continue to execute the 
remaining tests in the suite or skip them if an @Before* method fails.




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: fixing transfer listener in trunk

[Olivier Lamy]

2012/11/12 Jason van Zyl :
>
> On Nov 11, 2012, at 6:52 PM, Olivier Lamy  wrote:
>
>> 2012/11/11 Jason van Zyl :
>>>
>>> On Nov 11, 2012, at 2:49 AM, Olivier Lamy  wrote:
>>>

 Perso I propose a change by pointing you (you means other maven dev
 folks too) to a branch I made somewhere but you commit code without
 listening POV from others.
 If you could wait to hear what other thinks that could be lovely
>>>
>>> I believe you do exactly what you accuse me of Olivier. You did not propose 
>>> a change, you pointed to your branch with a terse "fixed" as if it were a 
>>> foregone conclusion.
>> Oh maybe I should have say "possible fix" using log4j2 sorry for using
>> bad word but I'm a coder not a writer and furthermore I'm not a native
>> english speaker so it can happen (I have updated the jira comment).
>> But I have started a discussion here (AFAIK @apache mailing list is
>> the place to discuss rather than jira)
>>>
>>> I started the SLF4J work, I worked with Ceki to try and minimize the 
>>> change, keep the ITs passing while preserving the existing behaviour and 
>>> keeping the dependency size and complexity to a minimum.
>>>
>>> I've been working on restoring the behaviour and my goal, at least, was to 
>>> reduce the possible complication of using a larger framework. The second I 
>>> created the JIRA issue, you point at your branch and say "fixed" without 
>>> any explanation. You used the console transfer listener not working -- and 
>>> I admit that was annoying and I apologize for leaving it like that so long 
>>> -- as a vehicle for adding your preferred logging framework. My goal was to 
>>> introduce SLF4J in a minimal way, at least to start. So if that conflicts 
>>> with your goal then that's fine but jumping in the middle of the work I'm 
>>> doing with a change that proposes to throw away the work I did with SLF4J 
>>> Simple is not fine. Couching it as me not taking into account a wider 
>>> discussion as a response to me finishing what I started with a veto even 
>>> less so.
>>
>> I don't have any issues using slf4j as logging api but we can go
>> (IMHO) a bit forward with proposing a more advanced logging
>> implementation instead of the choice you made for slf4j-simple (users
>> ask a more advanced logging options for a while) so it's probably the
>> time to do it and take the opportunity of the good changes you made
>> introducing slf4j api
>>
>
> I would like to see that from users as I don't believe that's the case. My 
> specific goals were the integration of SLF4J, preserve behaviour and provide 
> a path forward for integrators could actually integrate the log output and 
> possibly for us to pick one if deemed necessary. Honestly, if I thought we 
> needed a logging framework from the start I would have integrated Logback. I 
> don't think we need that, and the use of the transfer listener is really not 
> the concern of the logging system, I shouldn't have tried to use a logger in 
> the first place there really.
>
> But right now if we release it in the form it is, it has the same behaviour 
> and we can figure out whether we want to bring in the logging framework.
>
>>>
>>> I didn't change any of the dependencies, completed the work I started and 
>>> fixed what I broke which I believe is reasonable.
>>>
>>> If the discussion is now transitioning to users want flexible logging and 
>>> the choice of a logging framework that's fine. But I still maintain the CLI 
>>> use of logging can be limited and constrained while allowing integrators to 
>>> make the small changes necessary to add flexible logging. But if we want to 
>>> choose a framework let's look at the options, if people want to go that 
>>> route, and select the best option.
>>
>> Integrators ? Again what do you mean with that ?
>
> IDEs, CI systems and more sophisticated systems that embed Maven in some 
> form. What we do in m2eclipse for example: we need something more than 
> capturing the output from the console and integrating SLF4J in Maven makes 
> that much easier.

Currently I'm testing integrating jansi to have colorized output, that
works fine and that's fun :-)
Again I don't see why we couldn't add a bit or a possibility of fun
within our distribution (or at least make that easily possible)

>
>> I don't understand why the default Apache Maven couldn't be able to
>> propose a default advanced logging implementation.
>
> I think it's perfectly reasonable to talk about it, but I think from the 
> people that commented is that we ship this the way it is and then have that 
> discussion.
>
>> The size of the jars is around 500K so frankly I don't see that as a
>> blocking issue as we already download internet :-). (and perso I'd
>> like  to test some ideas using jansi for possible colorized logging)
>> And I don't understand why we must wait folks doing alternate
>> distributions providing this feature.
>
> But that will be a discussion because I do not believe we should use log4j2

[ANN] Maven Plugin Plugin 3.2 Released

[Kristian Rosenvold]

The Maven team is pleased to announce the release of the Maven Plugin
Plugin, version 3.2.

The Maven Plugin Plugin is used to create a Maven plugin descriptor
for any Mojo's found in the source tree, to include in the JAR. It is
also used to generate report files for the Mojos as well as for
updating the plugin registry, the artifact metadata and generating a
generic help goal.

Upgrading users may want to take note that this version no
longer *requires* plexus-utils to be on the classpath of the
maven plugin (unless the plugin requires it itself)

Upgrading users may also want to make sure to run "clean"
when switching versions.

http://maven.apache.org/plugin-tools/maven-plugin-plugin

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-plugin-plugin
  3.2


Release Notes - Maven 2.x Plugin Tools - Version 3.2



** Bug
* [MPLUGIN-219] - Instantiate spelled wrong in annotation
* [MPLUGIN-220] - Can not use regex in @Parameter(defaultValue)
* [MPLUGIN-222] - 'Since' information is not shown on generated
site (ANT Mojos)
* [MPLUGIN-223] - HelpMojo is not extracted when using
java-annotations extractor
* [MPLUGIN-225] - Make MojoExecution available as Component
compatible with Maven 2
* [MPLUGIN-227] - HelpMojo javadoc generated in "unnamed package"
* [MPLUGIN-232] - java-basic-annotations IT for
maven-plugin-plugin fails with M2.2.1 due to a missing description-tag
in the plugin-help.xml


** Improvement
* [MPLUGIN-229] - don't use Plexus' Xpp3 in generated HelpMojo to
read XML files: XML parser in JDK is sufficient
* [MPLUGIN-230] - sync help-goal with goal-report: Use 'User
property' instead of 'Expression'
* [MPLUGIN-231] - Switch to plugin annotations for the generated
help-mojo if the Maven Plugin depends on maven-plugin-annotations


Enjoy,

-The Maven team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: plexus-utils / maven-shared-utils / commons-io

[Stephen Connolly]

On 13 November 2012 08:23, Karl Heinz Marbaise  wrote:

> Hi,
>
> i have a question concerning the plexus-utils/maven-shared-utils. During
> the investigation of a bug in appassembler-plugin (
> http://jira.codehaus.org/browse/MAPPASM-187). I have seen that in
> plexus-utils (3.0.7) the method FileUtils.copyDirectory() seemed to be not
> working. The same as in maven-shared-utils. After checking
> maven-shared-utils (0.1) i have detected that the unit tests which are
> checking the copyDirectory part a currently set to @Ignore.
>
> I have found a solution in using commons-io package (2.4) but this would
> result in a JDK 1.5+ dependency (Does someone know a version of commons-io
> which works with JDK 1.4+?


What is the minimum version of Maven that you are supporting your plugin on?

Maven 2.0.x => JDK 1.4 is the theoretical minimum
Maven 2.2.x => JDK 1.5 is the theoretical minimum

We have not introduced a higher minimum yet for Maven, but I would suspect
it would be at least Maven 3.2 before that would happen (given the current
roadmap for 3.1)


> . The other question is why we don't use commons-io directly (apart of the
> optional dependency in maven-shared-utils) instead of rewriting things in
> maven-shared-utils or did i misunderstand the intention of
> maven-shared-utils?
>

maven-shared-utils is (as I understand it) for use in the core. We use
commons-io there, but shade it so that plugins will not have classloading
conflicts.

maven-shared-utils is an attempt to wean core off of plexus-utils. So in
some cases features/bugs in p-u have been reproduced in order to retain
current behaviour, but where possible the commons-* libraries have been
used.

m-s-u started out of an effort I started in the sandbox to provide a
rewrite of p-u based off of commons-* so that plugins could wean themselves
off of p-u... however there seems to have been a bit of a morph in that
work (no harm) and that is m-s-u


>
> Are there any particular reasons not to to use commons-io package directly
> (as a dependency for a plugin)?
>

 In a plugin, no reason at all. In fact it is probably the best idea!


> Can someone enlighten me a little bit?
>
>
Hope I have


> Thanks in advance.
>
> Kind regards
> Karl-Heinz Marbaise
> --
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
> Hauptstrasse 177 USt.IdNr: DE191347579
> 52146 Würselen   http://www.soebes.de
>
>
>
> --
> --
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
> Hauptstrasse 177 USt.IdNr: DE191347579
> 52146 Würselen   http://www.soebes.de
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MNG-5356 Make encrypt/decrypt logic pluggable

[Anders Hammar]

> Changes looks good for me.
>

Thanks for having a look!
One specific thing I'm not sure about is the maven-security artifactId. Is
it good, or should we maybe use maven-crypto. maven-security could in the
future contain more than the crypto things.

Most of the large changes has been done Karin Karlsson (can we have cla ?)
>

I realized that as well. I will get a CLA for Devoteam Sweden in place as
she's been doing this as part of her work with Devoteam. I believe that's
the proper level of CLA in this case, right?

Any special reason to use a package org.maven ?
>
> New files doesn't have license header but " //TODO: add copyright "
>

Yes, there's still some polishing to do here. It's still work in progress.

/Anders


>
> Thanks
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Fwd: Checkstyle Plugin: Upgrade dependency to Checkstyle v5.6

[Olivier Lamy]

resend as I have issues with my @apache.o mailbox.


-- Forwarded message --
From: Olivier Lamy 
Date: 2012/11/13
Subject: Re: Checkstyle Plugin: Upgrade dependency to Checkstyle v5.6
To: Maven Users List 


2012/11/13 Brett Walker :
> Hi Thomas,
>
>>> I tried building the plugin myself with an updated dependency. It did not 
>>> work.
>>
>>Have you tried overriding the plugin dependency with checkstyle:5.6?
>>
>>
>>   maven-checkstyle-plugin
>>   2.9.1
>>   
>>  
>> com.puppycrawl.tools
>> checkstyle
>> 5.6
>>  
>>   
>>
>
> This is what I did. It fixed my immediate problem but introduced others. 
> After fiddling around for a while I could not resolve all the new problems.
>
> I'm not familiar with Maven Plugin Architecture nor with how the Checkstyle 
> Plugin links to the Checkstyle Library.
>
> I am hoping someone can point me in the right direction.
You can do it.
But if you use default checktyle rules provided by the plugin it will fail.
The reason is checkstyle folks removed DoubleCheckedLocking rule (see
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-checkstyle-plugin/src/main/resources/config/maven_checks.xml?r1=1178094&r2=1390987&diff_format=h
) and checkstyle release note
(http://checkstyle.sourceforge.net/releasenotes.html)

So if going in this way you must use your own rules file and remove this one.

>
> Brett
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Fwd: MNG-5356 Make encrypt/decrypt logic pluggable

[Olivier Lamy]

resend as I have issues with my @apache.o mailbox.

-- Forwarded message --
From: Olivier Lamy 
Date: 2012/11/12
Subject: MNG-5356 Make encrypt/decrypt logic pluggable
To: Maven Developers List 


Changes looks good for me.

Most of the large changes has been done Karin Karlsson (can we have cla ?)

Any special reason to use a package org.maven ?

New files doesn't have license header but " //TODO: add copyright "

Thanks
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: plexus-utils / maven-shared-utils / commons-io

[Aleksandar Kurtakov]

- Original Message -
> From: "Karl Heinz Marbaise" 
> To: dev@maven.apache.org
> Sent: Tuesday, November 13, 2012 10:23:35 AM
> Subject: plexus-utils / maven-shared-utils / commons-io
> 
> Hi,
> 
> i have a question concerning the plexus-utils/maven-shared-utils.
> During the investigation of a bug in appassembler-plugin
> (http://jira.codehaus.org/browse/MAPPASM-187). I have seen that in
> plexus-utils (3.0.7) the method FileUtils.copyDirectory() seemed to
> be not working. The same as in maven-shared-utils. After checking
> maven-shared-utils (0.1) i have detected that the unit tests which
> are checking the copyDirectory part a currently set to @Ignore.
> 
> I have found a solution in using commons-io package (2.4) but this
> would result in a JDK 1.5+ dependency (Does someone know a version
> of commons-io which works with JDK 1.4+? . The other question is why
> we don't use commons-io directly (apart of the optional dependency
> in maven-shared-utils) instead of rewriting things in
> maven-shared-utils or did i misunderstand the intention of
> maven-shared-utils?

Isn't it really time to give up on 1.4 ? With 1.6 being EOLed recently jumping 
on 1.5 seems resonable enough to me. 
This would open the door for using many things provided by the VM instead of 
relying on some third party libs and even reduce the "downloads the internet" 
problem. Reducing the dependencies makes things a lot easier for a number of 
reasons like:
 - less legal audit and easier approval - yes, many organizations require audit 
of every single version referenced (not project). E.g. at Eclipse foundation if 
your build tool uses 3 maven plugins and they use 3 different plexus-utils 
versions - all 3 has to be reviewed.
 - easier to build - if there is a source only builds policy using old 
libraries complicates things by:
   * old libs not buildable with newer JVM and need heavy patching for this to 
happen
   * build cycles - the lib needs maven to build by maven needs the lib in 
order to be build

I know this might not sound too compelling reasons to many but it's huge time 
consuming effort which prevents many from doing other improvements to the Java 
stack (incl. Maven + plugins).

Alexander Kurtakov
Red Hat Eclipse team

> 
> Are there any particular reasons not to to use commons-io package
> directly (as a dependency for a plugin)?
> 
> Can someone enlighten me a little bit?
> 
> Thanks in advance.
> 
> Kind regards
> Karl-Heinz Marbaise
> --
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
> Hauptstrasse 177 USt.IdNr: DE191347579
> 52146 Würselen   http://www.soebes.de
> 
> 
> 
> --
> --
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
> Hauptstrasse 177 USt.IdNr: DE191347579
> 52146 Würselen   http://www.soebes.de
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

plexus-utils / maven-shared-utils / commons-io

[Karl Heinz Marbaise]

Hi,

i have a question concerning the plexus-utils/maven-shared-utils. During the 
investigation of a bug in appassembler-plugin 
(http://jira.codehaus.org/browse/MAPPASM-187). I have seen that in plexus-utils 
(3.0.7) the method FileUtils.copyDirectory() seemed to be not working. The same 
as in maven-shared-utils. After checking maven-shared-utils (0.1) i have 
detected that the unit tests which are checking the copyDirectory part a 
currently set to @Ignore. 

I have found a solution in using commons-io package (2.4) but this would result 
in a JDK 1.5+ dependency (Does someone know a version of commons-io which works 
with JDK 1.4+? . The other question is why we don't use commons-io directly 
(apart of the optional dependency in maven-shared-utils) instead of rewriting 
things in maven-shared-utils or did i misunderstand the intention of 
maven-shared-utils?

Are there any particular reasons not to to use commons-io package directly (as 
a dependency for a plugin)?

Can someone enlighten me a little bit?

Thanks in advance.

Kind regards
Karl-Heinz Marbaise
-- 
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de



-- 
-- 
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org