Difference between revisions of "User talk:Keshav"
(→'''Use Cases''') |
(→CVS Paths) |
||
Line 79: | Line 79: | ||
Use the following repository paths to connect to the geWorkbench projects (this is how it is now ... it could change): | Use the following repository paths to connect to the geWorkbench projects (this is how it is now ... it could change): | ||
/cvs/geworkbench - The geWorkbench project (geWorkbench core project) | /cvs/geworkbench - The geWorkbench project (geWorkbench core project) | ||
− | /cvs/components - The Component project (multiple component projects developed by third party developers). We will have to give users committer access to their specific project. | + | /cvs/components - The Component project (multiple component projects developed by third party developers). We will have to give users committer access to their specific project. For example, the cvs root could be something like: |
+ | |||
+ | /cvs/components/foobar |
Revision as of 15:42, 18 January 2006
(Work in progress)
Contents
Building in Eclipse
Checkout geworkbench from adcvs.cu-genome.org/cvs/acallab. In exclipse this looks like :extssh:keshav@adcvs.cu-genome.org:/cvs/acallab Add the following to the build path:
Folders
geworkbench/_all geworkbench/annotation geworkbench/bin geworkbench/src geworkbench/conf
Add all src folders in the components directory to the build path. These are folders like: geworkbench/components/alignment/src geworkbench/components/analysis/src geworkbench/components/annotations/src
Add all the jars in the lib directory.
Add all the jars in the respective components/lib directories to the build path. Add all the jars in the plugins directory to the build path.
Right-click on the project and select properties. In the Order and Export tab make sure the jar mageom.jar is below mageom-client.jar. If you do not do this the eclipse compiler will use the incorrect version of the mage classes when building (it will use the mage classes that are not Identifiable ... ie. they do not have getIdentifier() or getName()). This issue is under investigation.
When the application is run, the jars for each component are "added to the classpath" at runtime. Due to this, you should not have the jar files in component/xxx/lib or the jar files in the plugins directory on the classpath. You can remove them from your run configuration or, alternatively, you can keep them on your classpath and run in dev mode. To do this, add the program argument -dev to your run configuration. Actually, this doesn't seem to matter anymore.
Ant Tasks
Running the ant tasks compile and run are a "test" to see if your edits have caused anything to break. When hacking, however, you should take advantage of your IDE and have it build your java classes automatically. This is what the setup above does for you.
Magnet Development Process
We need to consider us, the core developers, as well as the component developers.
Use Cases
Anonymous Access (component developer)
- can have read access to the core code, can modify locally, but does not have commit access. This is great for component developers that want to fix a bug or add a feature to test their component. They would then send the patch to us and we would apply/deny it. Eclipse has a great built-in patch system, allowing users to create a patch for our core and send it to use. IntelliJ probably has a good patch system as well. An example of a patch being sent to a core development team can be found here: http://www.mail-archive.com/andromda-devel@lists.sourceforge.net/msg06408.html.
This is standard practice.
To do this, we would just give users anonymous access to our repository. This could look like:
Host - magnet.columbia.edu Repository Paths - (See "Repository paths", below) User - anonymous Password - (leave blank) Connection Type - pserver
Committer Access (core developer and super users from the committee)
- can edit core and submit changes to our repository, and/or can commit to 'their' project.
Host - magnet.columbia.edu Repository Paths - (See "Repository paths", below) User - (your committer user id, supplied by the webmaster) Password - (your committer password) Connection Type - extssh
Some component developers may be behind a firewall and are blocked from accessing hosts on port 20 (ssh) or port 2401 (pserver). We may want to consider a redirect host for those in this situation (on port 443). This could look something like:
Host - proxy.magnet.columbia.edu Repository Paths - (See "Repository paths", below) User - (your committer user id, supplied by the webmaster) Password - (your committer password) Connection Type - extssh Use port 443 (if we support pserver we can also do this for pserver access on port 80)
CVS Paths
Use the following repository paths to connect to the geWorkbench projects (this is how it is now ... it could change):
/cvs/geworkbench - The geWorkbench project (geWorkbench core project) /cvs/components - The Component project (multiple component projects developed by third party developers). We will have to give users committer access to their specific project. For example, the cvs root could be something like:
/cvs/components/foobar