perfsonar development work

["Jeff W. Boote" <>]

Roman Lapacz wrote:
> > This causes much more work for each new service.
>
>
> Really? This is the same amount of work. It just requires copy operation 
> for existing import entries to separate build files. In case of new 
> service it is just creating new build file instead of using one main 
> build file (content for a service is the same).

Ok, after hearing more of your explanation and going through the files more 
closely I agree new services are not really a problem.

> > It duplicates code in each one. 
>
>
> It's not a problem here. These new build files will have some of the 
> same import entries. (Most of our class files have the same import 
> packages and we don't say that's the duplication).  Benefit I see here 
> is that each service may have different definition of classpath (but I 
> suspect most of them will be the same).

I am still a little concerned about this. As long as the only thing in the 
service specific file is the import statements, you are right. But, this could 
easily end up promoting specific changes in each file. And we could end up 
having changes that have to be propagated across each and every file.

My main concern is that I think we should be unifying the configuration of the 
services more and more to make them more simple for end users trying to install 
multiple services. (I realize there are other problems there at this point, but 
I don't want to add additional problems.) I see this as a step in the other 
direction - it makes each service more independent.

I'm not saying this is the wrong approach, but I am concerned with the 
implications.

> > I would like to know why you think this is a good thing.
>
>
>
> Another benefit of having separate build file for each service is that 
> mistakes in Ant file of one service  will not block running Ant targets 
> of other services.

Bugs happen. This kind of interdependence is part of working on a large project 
with many developers. That is why using tools like svn to minimize the impact of 
others mistakes on your current work is useful. I actually see this part of your 
change not as a benefit, but as a disadvantage. I would prefer other developers 
saw a mistake as early as possible and made sure it was corrected quickly 
instead of having it only tested by the main developer.

> I do believe that we should check our exiting code from time to time 
> trying to improve it. This is the way to make it better and better. I 
> think that Ant build environment (and other pS stuff) needs work and I'm 
> quite sure that I or someone else will do more changes in the future 
> (maybe even removing all and replacing it with something new, maybe Maven)

I absolutely agree that we should continue to try and improve. However, it is 
still not clear to me that this is really an improvement.

My main concern here is that if each service has its own build file, the build 
and configuration environment of each service can diverge substantially. This 
will complicate creating a 'unified' configuration/installation tool for end 
users. As long as these individual build files do not diverge too much, I'm 
content to leave things as you have changed them. Hopefully you understand my 
concern.

I am not against improving things, but I am against having each service diverge 
from the others.

jeff