Subversion and Maven changes

Owned by Former user (Deleted)
Last updated: Jun 30, 2008Version comment
6 min read

Topics

Tasks

Seth (with support from Ray): Continue to work with Indiana and Michael to enable the "institution" branch. Collect volunteer admin names (from sakai-dev?): currently Seth, Ray, David Horwitz, Mike Osterman. We'll start small to gain admin expertise and get an idea of what issues might arise before opening the process up.

David Horwitz (with support from Aaron): Create and self-assign JIRA task for Maven pom cleanups Sakai-wide. Move to proper Maven release version names for Sakai. Clean out unnecessary use of versions in poms. Make sure source JARs will be installed with release builds. Roll in across code base for trunk and 2.6.

Aaron (with support from Ian): Make recommendations for proper artifact group names. Ask Ian about possible conflicts with Eclipse development fix.

Ray: Initial guinea pig for relocating current "bspace" branch to "institutional/berkeley.edu".

Ray: Self-assign SAK-13484. Add dependency on version name cleanup and source JARs. Since there will be some transition pain, send sakai-dev absolutely convincing statistical propaganda on the speed of Sakai development before and after the change.

Anthony: Report on the pros and cons of eliminating the "master" pom.xml and relying on the base POM instead.

Minutes

Alan: We should think about how to integrate static code review with check-ins.

Seth: Ray's proposal was for an "institutions" top-level folder with institution-managed subdirectories. Seth wants to push it. Indiana not ready for it. What are the issues? How can we make this happen. Wants to avoid git as a distraction now.

David Horwitz.: Can see which institutions are running which versions.

Ray: Useful to find out which projects many institutions need to customize: look for a common solution.

Seth: The Oracle content conversion fix is an example of how it helps maintenance. Ray could branch multiple modules and send back to trunk.

Mike: Same svn repo, not contrib, right?

Yes, otherwise can't do merges.

Seth: Admin overhead seems like the main worry.

Ryan: Lance couldn't make it. Andrew Poland is server admin. Both repos only take up 2 MB. Network traffic is one worry. Admin was another, but we're getting volunteers. Lance worried about extra costs. Michael willing to think about helping; waiting for details.

Seth: I have some stats. Terabytes of data going in and out, but infrastructure should be able to handle it.

Ryan: Andrew looking at svn update to 1.5 in the next month.

Dave Haines: Licensing?

Seth: Yes, you couldn't use the service without promising to leave iffy licenses and binaries out.

Alan: Possible to put in automated guard against both?

Seth: MAKE SURE NO CONFIDENTIAL DATA! Not even encrypted.

Mike: Would network traffic really be an issue?

Seth: Probably Indiana just wants to ensure the load can be managed.
It would simplify my life. It could even take pressure off Indiana admins.

David Ho.: Should help to reduce customized code. Also, branch commits mentioning a Sakai JIRA will show up in official reports.

Ryan: Makes things phenomenonly easier for review and distribution to community.

Seth: We're all in agreement. Who's ready to volunteer for "institutional" admin? Seth, Ray for starters. (Europe / South Africa coverage?)

Andrew: Plan for an orderly queue of requests and a set of admins. Set realistic expectations for turnaround time.

Ryan: Also want to include installation of rt in the upcoming SVN upgrades (including Subversion 1.5!), so requests won't get lost and it will be easier for a team of admins to share them. Michael's suggestion was to start first and figure out costs later.

David Ho: Controlled rollout with a few institutions first.

Ryan: Need to coordinate relocation into top module.

Anthony: "bspace" -> "/institutional/berkeley.edu" will be first.

Seth: Use standard domain names for the directories.
Start by offering access to foundation members, since they're paying and the foundation is helping.

Alan: Match structure in "contrib"? Match structure to Confluence space?

David Ho: "contrib" is pretty confusing; some directories are institutional, some are projects.
JIRA references in commit messages would probably be more useful for tracking than trying to connect directly to Confluence.

Maven project versioning is next topic.

David Ho: Sakai uses very non-standard version numbers in both 2.5 and trunk. No one has agreed as to when changes should happen.
Version number in trunk should be real version number: 2.5.x-SNAPSHOT. SNAPSHOT is meant to be a version keyword rather than the name of a version itself.
This gets us into big messes when patching for multiple deployments.

Ryan: Will sometimes use regular expression to change all across checkout.

Others at table doing the same.

David Ho: So we should switch to 2.6.0-SNAPSHOT in trunk. When?

Aaron: Shouldn't hold anyone up to do it pretty quickly. Developers just need to clean up their Tomcat directories afterwards. 2.5.x changes would be too controversial, though.

Seth: Announce guidelines for version so mistakes don't get made.

David Ho: Ian has scripts to do global change. David will make sure there's a JIRA and spearhead it.

Ray: Clean up Maven artifact group names at same time?

David Ho: What's recommendation? "sakaiproject.org" or "sakaiproject.org-project"?

Aaron: Uses the project in the name to speed up his searches in the repo directories.
Legitimately different projects in the same suite should have their own space. Spring does that way.

Aaron?: Get together a recommendation based on best practices. Get feedback. See if we can fit into other cleanup. Ian has opinions. (If this falls through, Ray will pick up the task.)

Aaron: Different projects should not need to have the same version number. Why is it necessary to lock all the versions together? There might not be any changes in the module.
The K1 deliverable should help move us toward that.

David Ho: We also want to manage applications or suites on different management / relase lines, and that requires different versions.

Ray: Sakai releases already use svn:externals to point to specific rev numbers for the subprojects. The only change would be that the rev numbers might no longer be the same for all projects.

Aaron: This change can happen gradually, module by module.

How should we start moving?

David Ho: Most projects aren't working correctly with dependency management - they're hard-coding Sakai version numbers, which screw this up moving forward. Spring / Hibernate versions the same problem.

Umbrella JIRA task to find-and-replace and remove the built-in versions where possible.
Join in with the SNAPSHOT version fix.

Simplifying and speeding up Eclipse development by removing the Eclipse configurations from the repo and having developers generate them via "mvn eclipse:eclipse" or the M2 plugin.

Aaron: One missing piece is that we'll either need to build source JARs or include source in the library JARs.
Ray: Can also point Eclipse to local source. But Lance recommends the standard source JARs approach. Individual developers who need it can always set their local Eclipse workspaces to point to checked-out source.
Aaron: After we have the version fixes to follow Maven release naming conventions, then generation of source JARs will be automatic.

Ray will add to existing JIRA and point to the version naming fix.

Aaron: There will be transitional pain.
Ray: But if we can show a side-by-side comparison, they'll be sold. I'll post timing information to sakai-dev.

First, need a Sakai-wide version. Then need to clean up pom files. Then we can tackle individual projects. More changes to master pom.

David Ho: Target the very stable modules first, since that's where we'll see the first payback for project-specific versions. (E.g., you don't store a dozen JARs all containing the same code with different version names.)

Anthony: We should think about combining the master pom and the base directory pom.

Aaron: Sounds like part 3, since everything's extending.

Anthony: Base pom is profiles. Master is dependency. Should they be combined?

Ray: Possible conflicts with how we're currently managing top-level local suites (Cafe, bSpace)?

Needs further investigation. Anthony will research since he's tried it before.

David Ho: Shouldn't Sakai's externals file have some documentation? About requirements, etc.

Seth: Good idea going forward, might be too much overhead now.

David Ho: I added user and Maven blew up for missing dependencies. Why isn't it happening automatically?

Aaron: Maven should've been able to figure that out. Might be because of the release build being quirky. We say everything is provided, but maybe it's not. Possibly a mix of that with monolithic versioning? Maybe dependency management tags need to be in user pom.xml?

David Ho: Investigate after these other changes since they'll change what we're investigating.

Alan: Has seen some command-line tools that look for bogus dependencies. Add as automated check?

Aaron: Get some way to automatically synch externals with pom dependencies.

Alan: I'll take that on later.

John Lewis: Maven dependency:analyze plugin.
Maven plugin for analyzing dependencies: finds used and declared; used and undeclared; unused and declared http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html

Alan: How to bring in more code coverage in static analysis? Currently based on trunk, but can we get other projects?
Volunteer for opt-in at project level, and then pull them in through externals?

Aaron: Do whatever's easy and we'll work with it.
Could we take advantage of how some other project is managing this? Use olo's mechanism, for example.

Alan: Does actually have to build, though, for analysis to work.

Aaron volunteers Ryan to set up continuous integration reports. No comment from Ryan. (smile)