Mailing-List: contact archiva-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: archiva-dev@maven.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <47161E0B.7020909@erdfelt.com>
References: <adba96190710161914i5f1627e7i4cae97065c044f2c@mail.gmail.com>
 <47158B1C.40301@erdfelt.com>
 <DBFBF194-E83F-4411-9D5D-DD68ED9BF65B@apache.org>
 <47161E0B.7020909@erdfelt.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AC1B05AD-F1DC-4D05-B6C3-E3550ECCD8F3@apache.org>
Content-Transfer-Encoding: 7bit
From: Brett Porter <brett@apache.org>
Subject: Re: Archiva Consumers question
Date: Thu, 18 Oct 2007 06:30:36 +1000
To: archiva-dev@maven.apache.org


On 18/10/2007, at 12:36 AM, Joakim Erdfelt wrote:

>> I know you're somewhat kidding here, but I'm not quite sure how  
>> much, so I'll say it anyway :)
>
> I am not kidding, make this change now.
> I'll do it. It's no big deal.

Then try a single sentence statement instead of what appears to be  
quoting a song which looks like a joke :)

>
> This statement contradicts your previous one.
> What we now want to change now is a public API.

No, it doesn't. The problem is that the actual public API is way  
overexposed. As I suggested later:

>> Let's just define what the acceptable extension points for Archiva  
>> 1.0 are (probably consumers, so maybe you've found the one example  
>> where it might be difficult!), document them, and commit to  
>> maintaining them and move forward in that way.


> I do not want to fall into the same trap that maven fell into when  
> it comes to "maintaining compatibility", we have far too much in  
> maven that exists solely for "maintaining compatibility" that is  
> complete and utter cruft.

Maven is in a trap because of maintaining runtime behaviour  
compatibility, not API compatibility. But yes, it's public API is  
another example of being overexposed, and it would accumulate cruft  
because of it when changes are made. But hiding the old API behind a  
new, simpler one is the right approach. Archiva isn't going to suffer  
from this problem.

>
> We are in that situation because of 2 major factors.
> 1) A hurry up and get a release out mindset.
> 2) A fear of changing the new APIs before a final (non-beta, non- 
> RC, release)
>
> Now is the perfect time to correct this.
> Lets do it now.

I don't have a problem renaming once the discussion on what the names  
should actually be is completed.

I do have a problem with the general attitude that we have to fix  
every imperfected API right now. Especially when I can't get a  
response to what is essentially a veto on a commit and the drive to a  
release... please take a look at these.

> Lets put it up for a vote now.

Put what up for a vote now? The rename? I don't see any need.

Cheers,
Brett


--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/