[Contrib: Evaluation System] [Building Sakai] RSF Present and Future

[Jim Eng]

I am running into RSF errors trying to get trunk of evalsys (a webapp built on RSF) to run with trunk of sakai (i.e. version 2.9-SNAPSHOT).  The RSF dependencies in the evalsys "tool" module remain the same as they have been for several years (shown below).  Everything builds fine, but I get error messages on startup indicating inability to locate some of the RSF beans, which eventually causes the evaluation tool not to startup.  

I noticed the following JIRA ticket, which seems to indicate that a new version of RSF is in the works for sakai 2.9.  

	https://jira.sakaiproject.org/browse/SAK-20964 

Does anybody know the status of that work?

Thanks.

Jim



From evaluation/tool/pom.xml:

    <properties>
        <sakairsf.sakai.version>2.2.x</sakairsf.sakai.version>
        <rsfutil.version>0.7.4</rsfutil.version>
    </properties>

        <!-- RSF dependencies -->
        <dependency>
            <groupId>uk.org.ponder.sakairsf</groupId>
            <artifactId>sakairsf</artifactId>
            <version>${rsfutil.version}-sakai_${sakairsf.sakai.version}</version>
        </dependency>
        <dependency>
            <groupId>uk.org.ponder.sakairsf</groupId>
            <artifactId>SakaiRSFComponents-evolvers</artifactId>
            <version>${rsfutil.version}-sakai_${sakairsf.sakai.version}</version>
            <type>jar</type>
        </dependency>
        <dependency>
            <groupId>uk.org.ponder.sakairsf</groupId>
            <artifactId>SakaiRSFComponents-templates</artifactId>
            <version>${rsfutil.version}-sakai_${sakairsf.sakai.version}</version>
            <type>war</type>
        </dependency>





On Feb 6, 2010, at 2:17 AM, Antranig Basman wrote:

> Thanks for your concern, Dr. Chuck.
> Sakai management has certainly a good track record for keeping a steady 
> eye on its trajectory on the 5 year timespan, and I'm also glad to see 
> its tradition of orderly and sober decision-making combined with respect 
> for community-oriented thinking continues unabated :)
> I and the Sakai maintenance team have already been communicating this 
> week on how to produce an RSF maintenance release addressing SAK-17877 
> amongst other packaging issues. As I stated in my earlier mail, I remain 
> committed to providing support needed for RSF for the Sakai community 
> and you will certainly be amongst the first to hear if this situation 
> changes. The RSF resources are as I already explained not under the 
> control of "some Cambridge IT person" but have received committed 
> resources for hosting from the Fluid Foundation for the forseeable future.
> Putting the RSF/Sakai Maven artefacts in the Sakai Maven repo to me 
> seems perfectly sensible, but starting an independent SVN fork at 
> present does not. There are still RSF users active outside the Sakai 
> community, and Fluid are perfectly happy to provide commit access to the 
> RSF tree to selected members of the Sakai maintenance team as well as 
> review of patches.
> In the meantime I welcome your enthusiasm for ensuring that the RSF 
> source base not be lost - I do encourage you to burn a copy to CD to 
> keep in your sock drawer or perhaps upload a version to Amazon S3. I 
> will be happy to mail you a tarball.
> 
> Yours,
> Antranig.
> 
> csev wrote:
>> This topic always ends in a hung jury :)
>> 
>> The -1 folks have great reasons until some Cambridge IT person stops backing up the server or asks around and says "are we using this old server" - and since no one in earshot says how important the server is, they shut it off and send it to property disposition and then we have *no source code at all*.
>> 
>> I am not concerned about next week or next year - I am concerned about five years from now.
>> 
>> There is no comparison between this and an apache project - of course we would never fork Apache - but RSF @ Cambridge is dead.  And over time folks will simply start to forget about it.   For now we know where the source is so I say we get a copy while the getting is good.   In five years - we will have the jars in our repo but not even have a single clue as to how to regenerate the jars.
>> 
>> This is like Y3K - we do what is lowest effort for the moment knowing full well that by the time this becomes a problem - we will no longer be around and so we simply won't care that it all falls apart.
>> 
>> /Chuck
>> 
>> 
>> 
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
>