Mark, Correct - My general approach to exposing something like FOSSology is to set it up as a common service. The service will need to reach out to the repository (typically remote) and then do that processing for the team.
Further, I am evolving a Continuous Integration architecture that can be implemented with OSS tools. As part of my research I like what I see in the Hudson tool (as it supports a number of plugins) Over time, I could see a FOSSology plugin for Hudson .. From: Mark Donohoe <[email protected]> To: [email protected] Cc: [email protected], [email protected], [email protected] Date: 08/04/2009 05:46 PM Subject: Re: [FOSSology] 1.2 features [email protected] wrote: > > Bob, > > I know a subversion interface is on list for a later version, but I > would position subversion access as functionality that would simply > the usage of FOSSology in larger organizations, but could be extended > in a number of ways > > 1. From an ease of use perspective, it would be easier to have > FOSSology read from a Subversion repository rather than have teams > create the appropriate directories and extract files to it. You > could further extend the argument that > > 2. You could then include a FOSSology scan into a continuous build > process (pick your favorite - Hudson, Continuum etc) - > > > Just a thought .. > George, I am wondering what you mean by subversion access. You can upload from a local svn with cp2foss by using the -X .svn option to exclude svn files. I just uploaded fossology1.1.0 from a checked out copy from our subversion repository. By subversion access, do you mean the ability to point it at the subversion url? If so, you are correct, that does not work currently. Hope that helps. -- Mark Donohoe MOST/OSTT, Cupertino CA. fossology.org
_______________________________________________ fossology mailing list [email protected] http://fossology.org/mailman/listinfo/fossology
