Cytoscape WikiRFC Name : Dependency Management/Build Process |
Editor(s): Sarah Killcoyne |
Status: In progress |
<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>
Proposal
Add a build process to Cytoscape, to streamline builds for both developers and users.
Biological Questions / Use Cases
- Many users like specific plugins or have a paper referencing a specific version of Cytoscape and plugin. Builds of the old Cytoscape’s with the plugins that were compatible at the time would make reproducing results from these papers far simpler.
- Simplify library updating/clean up by not keeping all required libraries in the repository
- Tracking a library version would also be simpler and again easier to update
- Core libraries can be built and put in a maven type repository with versioning, again to make it easy to update/clean the libraries through the build process rather than subversion
- Also could be used for creating some generic "skins" for Cytoscape (not user specific necessarily)
General Notes
Maven can utilize ant build scripts so this would use what we currently have and add more control to the libraries. Single "pom" file can handle checking out the most recent code from the repository and building it, streamlining the process for users who don't want to pick their way through subversion in order to create a local build for plugin development.
Requirements
- 1 month FTE
Deferred Items
Open Issues
Backward Compatibility
References
Comments
DanielAbel - 8/5/2007
I would like to add a usecase which should be made much easier with such a refactor. For testing / debugging purposes, it is really usefull if one can edit _any_ .java file, whether in a plugin, a coreplugin, core cytoscape or a core library, run an automated build process, and get everything rebuilt. This should be a trivial process. However, currently it is not. I had to severly edit the build.xml files to tie the seperate build.xml files together, copy the produced .jar files in the right place, etc. As far as I could see, there is currently no fully automated build process, despite the fact that everything uses ant. The seperate ant builds are not connected together.
MikeSmoot - 8/8/2007
The reason I haven't pushed to unify the builds of cytoscape, coreplugins, and corelibs is that I want to ensure that various dependencies don't emerge. Specifically, corelibs shouldn't depend on either cytoscape or coreplugins, and cytoscape shouldn't depend on coreplugins. The goal is to maintain modularity.
That said, the current build system is definitely cumbersome and I'd be very open to updating it.
RE: maven, I'd be interested in exploring how this works, but I (and others) are a bit worried about the rigidity of that system. I'd also be concerned about how easy it is for non-core developers to build cytoscape. Personally, I've had more luck with ant in the past than mvn in getting random projects to build. Finally, we need to make sure that maven supports all IDEs that people on the team use.
SarahKillcoyne - 8/14/2007
We've used maven some here for various projects and it's pretty easy once the code is set up for it.. As for IDE's, I know that Eclipse and IntelliJ (the two we've used here) both work with maven, I don't know about NetBeans. However, I only suggested maven because we've used it. If there are other ways to do this that'd be fine as well. The plus to a system like this over just ant is being able to set up a repository that will handling versioning of things like the corelibs and which cytoscape version needs which (different pom file for Cytoscape version 2.1 vs 2.5 for instance). It also might allow us to set up poms based on a specific plugin and the version of cytoscape/libs it needs instead.
MikeSmoot - 8/20/2007
It seems like we're conflating issues here. In my mind, all versioning happens in subversion. If you want to build release 2.1, then you just need to check out version 2.1. If you want 2.5, then you checkout the 2.5 branch. If you need to make changes to 2.5, then check out the branch and make the changes in the branch. So, I guess I don't see how maven would help that. Is there a use case I'm missing?
How to Comment
Edit the page and add your comments under the provided header. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.