geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: no more modules for specs...
Date Sun, 17 Dec 2006 05:45:15 GMT

On 16 Dec 06, at 7:49 PM 16 Dec 06, David Jencks wrote:

> On Dec 16, 2006, at 1:58 PM, Jason Dillon wrote:
>> On Dec 16, 2006, at 9:33 AM, Jason van Zyl wrote:
>>>> IMO, we release source code. Binary distributions and maven  
>>>> artifacts are a convenience. If users can't build our source  
>>>> code, then there's a problem.
>>> You think your users build from sources to make their Geronimo  
>>> servers for production or are you talking about just the specs? I  
>>> would argue that it's rare for users to want to build everything  
>>> from source, but even if they only built the Geronimo sources  
>>> they still need all the binary dependencies at which point the  
>>> quality of the repository matters. I think the discussion is  
>>> germane in the context of your users building production systems  
>>> from source.
>> The *user* that wants to build everything from source is me... for  
>> automated builds.  For our builds, and I had hoped for our  
>> releases too, that use the automated system to produce builds,  
>> which are always built from source (for our components) so that I  
>> can be 100% assured that when I make a build that I know exactly  
>> what code (from our components) was included.
> My understanding is that geronimo (and openejb) are going to be  
> using the latest released specs that we just voted on until someone  
> finds a bug in one of them.
> Why do you want to rebuild released jars?  I certainly think the  
> automated system should be rebuilding all the non-released code we  
> know about, but I don't understand the point of ever rebuilding  
> released code.  Is this because you think the jar in the remote  
> repo will change?  I would think saving the expected hashcode and  
> comparing with the actual hashcode would be more reliable.
> I don't really see rebuilding from source as a defense against the  
> remote repo changing.  Everyone else is going to be using the  
> remote repo, so even if we have a more correct locally built  
> version everyone else will be screwed.  I would think using an svn  
> based repo or keeping our own audit trail (such as the hashes for  
> every released artifact we use) would be more reliable.  If some  
> released artifact changes, I think no automated recovery is  
> possible: someone has to figure out why and figure out what to do  
> about it, since maven allegedly guarantees that it will never happen.
> maybe I'm just being stupid.... but I'm not getting it yet.

You have it exactly. You would do exactly what large enterprises do  
in managing their own repositories. Some do it for security reasons  
and some have to do because metadata for some projects is just crap  
(Spring and Hibernate are great examples of completely hosing users  
by having bad metadata). It's not a trivial problem trying to make  
this work for the all the project using Maven but I still believe it  
is possible and not an intractable problem. Use a repo in SVN if you  
have to and layer that with the use of the central repository for  
thing you know are goods and work toward tapering off the need for a  
custom repo.

Users will eventually be the ones who will be the impetus for  
changing the quality of the repositories. As it will be a great  
indicator that a project who can't get their shit together to do  
something relatively simple like put some signed JARs on a webserver  
in a consistent way probably don't have good test coverage, don't  
have good CI, don't have API stability and don't have good level of  
quality. It will be a clear indicator of control over your processes  
and folks trying to consume various artifacts will really go find  
something that can be immediately absorbed into their system i.e. not  
use your stuff.

I'm definitely practical and I have never advocated using the central  
repository to any enterprise client I've had. I'm the first to admit  
that full audit trail, and absolute levels of security are not in  
effect. But the central repository is still highly useful especially  
when  you use it to populate the repository you do use for your  
production purposes.


> thanks
> david jencks
>> The remote repo is still there for other users that don't need  
>> that assurance or don't have time to go and build everything...  
>> but I do want that... and I believe that it is in the best  
>> interest of the community to get that too.
>> --jason

View raw message