perfsonar development work

["Jeff W. Boote" <>]

I don't have strong opinions about if we should redistribute external project 
releases from our repository. I generally lean more toward Roman's opinion that 
these external projects are stable enough to rely upon - but it is also not a 
big deal to me if someone wants to put the work in to archive specific versions 
of these packages for perfSONAR.

But, I do think that if we do want to redistribute in this way - we should not 
try and put them inside 'branches' of our project. Things in our SVN project 
should be only those things that are part of our project. For this function I 
don't think it makes sense to use SVN at all (ours, or any other). Each of these 
projects have their own version numbering scheme. To be clear: I think it is 
reasonable for us to 'archive' the versions we use if we are worried about 
making sure these versions are available for us in the future. I just don't 
think our SVN is the place to do it.

The maven/ant scripts could be configured to look in some external project 
archive directory on our web server for specific versions of external packages, 
right?

jeff

Roman Lapacz wrote:
> Loukik Kudarimoti wrote:
> > Roman,
> >
> > This is a good point. Thanks for bringing it up.
> >
> > I think I see this topic under a different light. I am more concerned 
> > about us depending on public repositories maintained by other project 
> > groups. What if this external project is shelved? What if the server 
> > of this external project goes down for maintenance during days which 
> > are crucial for us?
> > Also, these repositories provide more than one version of the same jar 
> > file. How are we going to make sure that our developers use one 
> > version of the same jar file?
> >
> > In my opinion, we should have our own repository. All our source code 
> > should use jar libraries which are present within our repository. If 
> > anybody needs any other jar files or versions, it should be approved 
> > by a named individual/group in charge of maintaining the repository. 
> > (This is how CERN/EGEE does it)
>
> I'm still not convinced we need our repository with all libraries (even 
> if  EGEE has it, btw. what kind of repository? Did they follow us using 
> maven approach?). For stable projects like Tomcat, Axis, Xerces, etc. 
> the public stable repository is enough. Thats is why such repository 
> exists. It's for interested parties like perfsonar project. Of course 
> it's useful to have our own repository but only for specific libraries 
> which are missing in the public repository.  Why we have to collect and 
> maintain everything in one place if we have access to the resources in 
> different locations. Distribution of resources is the right direction (I 
> realize that sometimes there are problems with the connectivity, but I 
> believe this problem is getting smaller. And of course we should try to 
> use libraries of only stable and active projects, but again, I realize 
> this could be a problem sometimes as well).
>
> ....But we already have a repository with all libraries so I stop 
> explaining my concern now :)
>
> > The answer to your question:
> >
> > " For example, if I want to create branch STABLE for RRD MA should I 
> > include also our all jar-repository or just those two directories 
> > created by us? What do you think? "
> >
> > depends on how the installation scripts are written. During the build 
> > process, do your build targets assume that jars are already present in 
> > the lib directory or do they try to download them from somewhere?
> This is something which is present for our services for a while. First 
> the script for downloading the libraries is executed and then the build 
> script can be started.
>
> example (from trunk):
>
>  ant -f build-rrdma lib
>  ant -f build-rrdma build
>
> > I don't think we should copy required libraries for every micro-STABLE 
> > branches. STABLE branches should contain some description on the list 
> > of jars and version numbers of each jar that the service depends on. 
> > Ideally they should contain targets which can fetch the jars from the 
> > repository and put them in the lib directory before building. If not, 
> > the user of this branch will have to make use of the list/description 
> > and copy the jars from the repository before building the micro-STABLE 
> > branches.
>
> the list of required libraries is present in the script which downloads 
> them (see above Ant command)
>
> > However, I feel that micro-release tags should be treated differently. 
> > They should contain the complete lib directory with all the required 
> > jars (but the required jars should be copied over from our repository 
> > only - not anywhere else).
>
> I believe that libraries should be present only in the final binary 
> release file (tar.gz) created by Ant script (there is such script for 
> RRD MA).
>
>
> Roman
>
> > Loukik.
> >
> >
> > Roman Lapacz wrote:
> > > Hi,
> > >
> > > we haven't thought about jar-repository in the release process. I 
> > > wouldn't see the problem if we used only public repository with 
> > > libraries maintained by other project groups. But unfortunately we 
> > > created new two directories in our repository (axis and rrdjtool, the 
> > > rest are copied from the public repository) and I think now we should 
> > > tie them somehow with service releases. For example, if I want to 
> > > create branch STABLE for RRD MA should I include also our all 
> > > jar-repository or just those two directories created by us? What do 
> > > you think?
> > >
> > > Roman