commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From A Leg <hale_in...@yahoo.com>
Subject Re: commons development practises (was maven : why marmalade ?)
Date Fri, 24 Jun 2005 12:21:06 GMT
Hi Simon


Simon Kitching wrote:

>On Fri, 2005-06-24 at 10:50 +0000, A Leg wrote:
>
>  
>
>>That is why I sent my feedback, to try to explain that backward 
>>compatibility with maven 1 tags is important.
>>    
>>
>
>No, you moaned about the fact that software changes in general. CVS to
>subversion and ant to maven were two of your complaints. And my response
>was that in the software world things always change. Live with it. Learn
>to love it. Remember that it keeps us employed.
>
>  
>
I did'nt moaned and I tried to be polite. I was talking about subversion 
too, because maven project is thinking also to change from cvs, and for 
ant I suppose that you understand the link with maven. So I was talking 
about specific maven case.

>A polite question *to the maven list* asking whether they are intending
>to support maven1 plugins in maven2, and if not whether the problem is
>technical (cannot be done), or motivational (too much effort) would have
>been the appropriate move. 
>  
>
I think hat my question here was polite. I am not sure about your last 
answer.

>If the answer is the latter, then you have to seriously consider how
>many people actually care about compatibility. If it's only you and your
>dog then you have to accept you're out of luck - it's no-one's
>responsibility to work for you for free. If there are many people, then
>it's time to politely request support for it - or gather the affected
>people and work together to create a patch that implements the feature
>*you* need. And remember no-one is going to take away the version you're
>using right now.
>
>  
>
I have no dogs, but I am working with many It managers of large and 
small companies and they all care a lot about backward compatibility.
I personnaly spend a lot of time for open source projects for free 
(about 10 hours a days 6 days a week from 3 years) and I am happy to do it.
I beleive that is is the case for most of open source developers, 
probably you also ?

>Under no circumstance do you have the right to demand that new
>development on the project is halted and all APIs are frozen just to
>suit you.
>
>
>In any case, are you
>a) using Maven to build your own project, or
>b) a supplier of Maven plugins which wrap your project?
>
>If (a) then what's the problem? Maven1 will continue to exist. If you
>are using it then clearly there aren't any bugs that bother you. And
>anyway I believe the Maven team are intending to provide bugfixes for
>maven1. And if they don't, you can fix it yourself and still be way
>ahead of having built your own solution.
>
>If (b), then creating wrappers for maven2 is likely to be a very small
>amount of work. From what I can see, the maven2 team have given some
>thought to how people can structure their custom maven plugins so that
>the work to support both is reduced.
>  
>
I didn't demand any thing specific for me. I was just asking questions 
to be able to choose.
Nobody is obliged to answer me, any answer should be correct.
I have no problem with maven.
My problem was about support around jelly and I got a nice and clear 
answer from jelly team and I will keep using it.

>And none of this is really relevant to this commons list.
>
>  
>
I made a mistake, I was looking to send it to maven list. I personally 
will not go ahead with this discussion on this list.
But all this discussion is relevant for any open source project.
You cannot ask for feed back and have this kind of answer if feed back 
is not 100% ok for you.
Once again I am happy to use some jakarta commons api.

Best regards

Andre

>Regards,
>
>SImon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>  
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message