Hi Chris, Sorry it took so long to respond to this thread, I've been swamped over this weekend. See my comments below:
On Tue, Jun 23, 2009 at 10:34 PM, Chris Wilper<[email protected]> wrote: > Hi Mark & all, > > On Tue, Jun 23, 2009 at 3:01 PM, Mark Diggory<[email protected]> wrote: >> ... >> There are topics the community are very interested in participating on, and >> I'd like to start seeing DSpace and Fedora community members sitting in >> activities together. [...] >> 1.) Maven and Spring DM activities (we are currently restructuring parts of >> the DSpace 2.0 repo and having cross pollination of ideas would assist >> here). > > I think this would be a great place to cross-pollinate too...here's > where the Fedora ant-to-maven work is being done/described: > https://fedora-commons.org/confluence/display/FCREPO/ANT+to+Maven2 > Is there a similar page on the DSpace 2 repo restructuring? Repo restructuring for DSpace 2.0 hasn't been as hard bound to retaining backward compatibility with any previous release process, its recent reorg has been "from the hip" based upon our need to get the projects organized and a release process in place. So, unfortunately, this means little documentation ATM. My current initiative has been to simply "peel" apart the separate projects into individual svn projects capable of being maintained with separate revision histories. See for instance the following sources: http://scm.dspace.org/svn/repo/dspace2/core/trunk/ http://scm.dspace.org/svn/repo/dspace2/modules/xmlui/trunk/ http://scm.dspace.org/svn/repo/dspace2/modules/storage-jackrabbit/trunk/ The objective here is that where-ever we have separate trunks, we can maintain separate incremental versioning. This will allow individual components within the system to be upgraded. I draw upon a couple different Open Source communities as "templates" for our current changes in project structure. 1.) The Maven Community: More specifically, the Maven project'[s SVN repository structure is divided into two major areas: a.) components: https://svn.apache.org/viewvc/maven/components/trunk/ b.) plugins: https://svn.apache.org/viewvc/maven/plugins/trunk/ Components are low level parts of the maven execution environment, everything in Maven that has to do with interpreting pom.xml resides within here. Plugins are more familiar, and represent the stereotypical manner in which functionality is added to the maven build process. My observations: Maven versions parent poms as single digit releases (1, 2, 3, 4, ...) and they are versioned separate from all other projects and only increments when dependencyManagement changes. Multiple plugins in one svn project space: One svn project for all components or all plugins gets messy quickly, its is best to manage individual plugins in separate svn projects. Multiple components in one svn project space: Components are very critical to the current maven version and tend to be released in lock step with maven releases, it makes much more sense to maintain this finite set maven modules as a group under one svn project space. Thus in DSpace 2, we have http://scm.dspace.org/svn/repo/dspace2/core/trunk/ http://scm.dspace.org/svn/repo/dspace2/modules/xmlui/trunk/ http://scm.dspace.org/svn/repo/dspace2/modules/storage-jackrabbit/trunk/ Where I have divided the core from each individual module "addon" to dspace. The core will be released in lockstep, while the modules are free to evolve over time. I decided not to manage our parent pom separately from the rest of the projects because we will have very regular and often releases. http://scm.dspace.org/svn/repo/dspace2/core/trunk/pom.xml I expect that this parent pom will change as much as our core implementation evolves over time. 2.) The SAKAI Community: I observed that the SAKAI community has taken advantage of svn externals to organize together all the individual maven projects necessary for a specific build of the sakai application, while each individual project is maintained separately under individual svn project spaces. See: https://source.sakaiproject.org/svn/sakai/trunk/.externals https://source.sakaiproject.org/svn/entitybroker/trunk/ It is difficult to see this from the above URL, but if you are to checkout https://source.sakaiproject.org/svn/sakai/trunk you get the all the projects configured in the svn externals and maintained individually at the top level https://source.sakaiproject.org/svn I've reused this in our current Continuous Integration build here https://scm.dspace.org/svn/repo/dspace2/build I can see us organizing together different testing distributions of dspace2 using this strategy, but I do expect to fully utilize the Maven release cycle to maintain production distributions of DSpace 2, this will mean just having "aggregation" projects that bring together appropriate modules required for a distribution. > We haven't really started the SpringDM work yet, but here's the best URL > I've got for it for now: > https://fedora-commons.org/jira/browse/FCREPO-84 I feel from our past discussions, that the really important point here is to makes sure that in teh svn project organization, that we are not excluding usage of technologies like SpringDM, OSGi, etc) By using atomic projects with cleanly defined dependency hierarchies and by working to separate out Dependency Injection into a configuration/runtime layer (Spring/Guice/OSGi). It can be assured that most any DI IoC container might be used to configure an application. I have an example where I've observed this process happening in other projects. Apache Cocoon started out in version 2.1 to be bound to a Container called "Avalon", a project which ultimately died a very slow death due to stagnation and loss of its community. In Cocoon 2.2, the application was divided up into modules, the DI externalized into Spring configuration and a clean separation of modules was accomplished. Now, the Cocoon community is working hard on version 3.0, which will be an implementation of separate maven modules that can be connected together with or without any specific container, they are also working to configure support for multiple containers (Spring, OSGi, etc). So IMO, the ultimate path I learned to refactoring the project structure of DSpace from 1.5.0 to 2.0 is that we are on a similar path. 1.5.x divided the project initially into separate modules wired together by a maven build process. 2.x is working to create a ServiceManager that is abstracted away from any specific DI/IoC container technology, but ultimately utilizes Spring and Guice as DI implementations. Upon discussion concerning the usage of OSGi, we see OSGi playing a similar role tot hat of our Spring and Guice implementations and that eventually we should have an implementation of a ServiceManager supporting an OSGi registry of bundles running behind the scenes. >> 2.) Planning around Duraspace and OSL resources. >> 3.) Starting to Share Duraspace resources like Confluence and JIRA > > To provide a little background on this: > We're hoping to migrate as much of the Fedora Commons development > infrastructure to be physically hosted at OSUOSL over the next couple > months. And we've identified a few areas where we can probably use > the same software (and in some cases the same instance) for the > projects. Yes, I'm very interested in a couple areas here: 1.) Confluence is far superior to Mediawiki in terms of capability as a documentation engine and medium for community interaction. I would like to see a Duraspace wiki with separate spaces for each project in the Duraspace community rather than separate wikis for each and every project in the community. 2.) JIRA: It would be great as well to see a consolidation of JIRA since we are both using it and the "allocation" of JIRA project spaces for individual Duraspace projects 3.) Crucible and Fisheye. It would be really great to get local implementations of this running once the repositories have been migrated. >> 4.) Community Driven Release Processes and decision making around release >> feature-sets >> 5.) OS Governance and Processes. >> The DSpace community has a rather solid release management process and I >> agree that DSpace community members should attend some of your activities to >> advise on our process in greater detail (ie a round table). > > Definitely, consider yourselves invited...I'd like to understand more > about what's worked/hasn't for you guys. One thing we're pretty clear > on right now is that we'd like to have a community release manager for > Fedora. At the same time, we're hoping the move to a standards-based > module architecture over the next year will make it simpler for people > to contribute and extend the core repository service in a loosely > coupled way. +1000 thank you and I will try to attend Fedora meetings (although they are a bit early for me on the left coast) >> I think there need to be shared resources to advertise Fedora and DSpace >> activities. I might recommend we repurpose the Google Calendar we have for >> DSpace activities to be Duraspace activities and that any time we have >> Developer meetings, training and conferences, they be published in it > > We also have a google calendar for FC-related events, but have mostly > relied on the fedora-commons.org website, twitter, etc, for actually > disseminating this info. I really like the idea of having a merged > view of our calendars, but that doesn't necessarily mean it has to be > managed as one, e.g.: > > http://fedora-commons.org/confluence/display/~cwilper/Calendar+Test I like this too, it would allow each subproject to maintain a separate calendar of events (DSpace, Fedora, Mulgara, Topaz, Duracloud, etc). My only concern is that the calendars will be very sparse and we will end up having lots of duplicate events on them. So I might recommend trying a consolidated calendar, and the expanding out from there if it seems that its getting to crowded? >> I will emphasize my own opinion that Fedora Commons trying to open up its >> community and DSpace working make its existing volunteer community healthier >> are really trying to solve the same problem and we can share >> our experience here. >> For both the DSpace and Fedora groups, the core >> development team is already a sub-set of the community that preexists and >> that to foster greater involvement in the codebase, you will need to reduce >> the (often self imposed) barriers to participation by attributing merit to >> your community members that deserve it and rewarding them with commitership >> rights and delegating trust to them to assist in leading the direction of >> the codebase. > > Agreed on both points...meritocracy works. > > On that note, I want to point out that we have a good sized list of > community-submitted requests that have been opened and are ready to be > worked on. For anyone reading this wondering how you can get involved > with Fedora development, see: > > http://fedora-commons.org/go/fcrepo > > We're working on ways to make this more inviting, so 1) if you have > suggestions, don't be shy, and 2) look for updates on the above page > in the coming months. The DSpace wiki has been challenging to get organized in regards of an individual page outlining the project contribution process so succinctly. The basics of the project, its team and its resources are accessible from the "Developers" section of the DSpace wiki http://wiki.dspace.org I'd say that the strongest feedback I can give is to work to "tear down" organizational boundaries where ever possible within your project. At this time, my vision is to see the following page get so long as to become absolutely impossible to maintain and the distinction of the two categories of contributor and committer be utterly nonsensical. http://wiki.dspace.org/index.php/DSpaceContributors Cheers, Mark -- Mark R. Diggory @mire - http://www.atmire.com ------------------------------------------------------------------------------ _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
