Menu
▾
▴
treebase-devel — TreeBASE developer mailing list
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
(41) |
May
(41) |
Jun
(50) |
Jul
(14) |
Aug
(21) |
Sep
(37) |
Oct
(8) |
Nov
(4) |
Dec
(135) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(145) |
Feb
(110) |
Mar
(216) |
Apr
(101) |
May
(42) |
Jun
(42) |
Jul
(23) |
Aug
(17) |
Sep
(33) |
Oct
(15) |
Nov
(18) |
Dec
(6) |
| 2011 |
Jan
(8) |
Feb
(10) |
Mar
(8) |
Apr
(41) |
May
(48) |
Jun
(62) |
Jul
(7) |
Aug
(9) |
Sep
(7) |
Oct
(11) |
Nov
(49) |
Dec
(1) |
| 2012 |
Jan
(17) |
Feb
(63) |
Mar
(4) |
Apr
(13) |
May
(17) |
Jun
(21) |
Jul
(10) |
Aug
(10) |
Sep
|
Oct
|
Nov
|
Dec
(16) |
| 2013 |
Jan
(10) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Hilmar L. <hl...@ne...> - 2010-01-14 21:44:40
|
Vladimir - I think you can use the first backup that there is. Or one before the first tests were run. -hilmar On Jan 14, 2010, at 4:06 PM, Vladimir Gapeyev wrote: > This is mostly for Bill: > > Since we started running tests in late December, the DB has > accumulated lots of junk (see, for a start, tables userrole, user, > study). > > We might speed up obtaining a clean DB instance if we restore one from > a past, rather than a current backup, which would hopefully contain > less junk that we need to prune by hand. > > So, what would be the date, farthest in the past, by which the > instance at NESCent already held all the valuable data it has there > now? > > --Vladimir > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts > the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important > issues through > interactions with peers, luminaries and emerging and established > companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Hilmar L. <hl...@ne...> - 2010-01-14 21:43:25
|
Can we give those 7 java classes some more attention as to why they are needing the CIPRES framework to compile? Let's remember, we know for a fact that code that relies on that framework is guaranteed not to function. We should at least know what it is in those 7 classes that we know can't be functional because it needs the CIPRES framework. Leaving that code in there because we need it is the same as saying, there is code in there that we need but that we know doesn't work. I'm not comfortable with this. -hilmar On Jan 14, 2010, at 3:46 PM, youjun guo wrote: > I checked into TreeBase code and found 7 java classes still need > cipres framework 1.1 to compile. I suggest we keep it for now. > > Youjun > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts > the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important > issues through > interactions with peers, luminaries and emerging and established > companies. > http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Hilmar L. <hl...@ne...> - 2010-01-14 21:38:43
|
On Jan 14, 2010, at 1:45 PM, Vladimir Gapeyev wrote: > Does the property treebase.domain.name I voted strongly for calling this treebase.purl.domain, to make clear what it is. I believe Rutger and most (all?) others were fine with that? > hold the value (be it "purl.org/ phylows" or "treebase.org") that > will be the same in all three or more TB installations (production, > staging, development, ...)? It can't be the same everywhere *and* resolve back to the same instance, since we won't replicate staging and dev URL redirects to purl.org. So either it is the same everywhere and then de-referencing those URIs will always go to production, or it is different to allow resolution to the origin, and then staging and dev need to have their own purl.treebase.org or something URIs, which complicates matters. I don't see a problem if for the time being PURL URIs always go to production regardless of origin. That is not different, for example, for Dryad, where all handle URIs resolve to production, whether they originate from development or production, or if we used DOIs. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Vladimir G. <vga...@ne...> - 2010-01-14 21:06:39
|
This is mostly for Bill: Since we started running tests in late December, the DB has accumulated lots of junk (see, for a start, tables userrole, user, study). We might speed up obtaining a clean DB instance if we restore one from a past, rather than a current backup, which would hopefully contain less junk that we need to prune by hand. So, what would be the date, farthest in the past, by which the instance at NESCent already held all the valuable data it has there now? --Vladimir |
|
From: Vladimir G. <vla...@du...> - 2010-01-14 20:55:24
|
I agree: more investigation looks like too much trouble now, so I filed a bug note for the future. --VG On Jan 14, 2010, at 3:46 PM, youjun guo wrote: > I checked into TreeBase code and found 7 java classes still need > cipres framework 1.1 to compile. I suggest we keep it for now. > > Youjun > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts > the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important > issues through > interactions with peers, luminaries and emerging and established > companies. > http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel |
|
From: youjun g. <you...@gm...> - 2010-01-14 20:46:37
|
I checked into TreeBase code and found 7 java classes still need cipres framework 1.1 to compile. I suggest we keep it for now. Youjun |
|
From: youjun g. <you...@ya...> - 2010-01-14 20:41:44
|
Dear TreeBASEer, Here is the current situation about TreeBASE unit test, there are only 3 fails left, all of them related to sequence problem. 2. testAddDelete(org.cipres.treebase.service.matrix.MatrixServiceImplTest) 3. testCreateDelete(org.cipres.treebase.dao.tree.PhyloTreeDAOTest) 6. testAddDelete(org.cipres.treebase.service.study.StudyServiceImplTest) Youjun |
|
From: Vladimir G. <vla...@du...> - 2010-01-14 18:45:54
|
On Jan 14, 2010, at 12:41 PM, Hilmar Lapp wrote: > So, trying to recall what's at issue here I'm not so sure anymore. > Looks like we pretty much agree and Rutger is almost there with the > property and getter method naming? Or am I under coffee deprivation? Putting aside the relative merits of PURLs vs YOURL-APAYAs (Your Own URLs - As Permanent As You Are), here is the practical matter: Does the property treebase.domain.name hold the value (be it "purl.org/ phylows" or "treebase.org") that will be the same in all three or more TB installations (production, staging, development, ...)? If yes, all is good. [I see it is currently "treebase-dev.nescent.org: 6666", which does not smell good.] If not, can we adjust our needs or the implementation so that it is the case? [This could be doable, while keeping PURLs in.] If not, then this value should be moved outside the WAR (e.g., become a JNDI parameter). --Vladimir |
|
From: Hilmar L. <hl...@ne...> - 2010-01-14 17:41:48
|
On Jan 14, 2010, at 12:36 PM, William Piel wrote: > If there exists one, say, GIS document that references a tree like > so: <id>http://purl.org/phylo/treebase/phylows/tree/T1020</id> and > another, say, CITES document that references the very same tree with > <id>http://treebase.org/phylows/tree/T1020</id>, a semantic reasoner > might not realize that the referenced trees are the same tree, no? I agree that canonical data object URIs are a highly desirable feature, and if TB2 can show them rather than having the user guess that's valuable. It also seems to me that the implementation of that is almost done by Rutger anyway? So, trying to recall what's at issue here I'm not so sure anymore. Looks like we pretty much agree and Rutger is almost there with the property and getter method naming? Or am I under coffee deprivation? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: William P. <wil...@ya...> - 2010-01-14 17:36:31
|
On Jan 14, 2010, at 11:57 AM, Hilmar Lapp wrote: > Looks nice to me, but anyone (i.e., any third party) could do that on > top of each resource's individual base PhyloWS URL, couldn't they? > I.e., this need not be a responsibility of the data resources per se, > no? Yes, although we don't want to proliferate synonymous references, right? On Jan 13, 2010, at 4:52 PM, Vladimir Gapeyev wrote: > As far as I understand the problem, the real stability issues of a URL like http://purl.org/phylows/study/TB2:S1020 lie not in its "http://purl.org/phylows" part but in its "study/TB2:S1020" part I take it that the "gold standard" is now the "linked list" approach in the semantic world: i.e., each RDF, XML, OWL, or whatever, uses fully resolvable and globally unique identifiers. So for TreeBASE study_id "44", they would not use <id>44</id>, nor would they use <id>study/TB2:S1020</id> or even <id>/phylows/study/TB2:S1020</id> -- but rather they would use <id>http://purl.org/phylo/treebase/phylows/study/TB2:S1020</id>. If there exists one, say, GIS document that references a tree like so: <id>http://purl.org/phylo/treebase/phylows/tree/T1020</id> and another, say, CITES document that references the very same tree with <id>http://treebase.org/phylows/tree/T1020</id>, a semantic reasoner might not realize that the referenced trees are the same tree, no? So, my take of the "linked list" approach is that the full URLs matter (not just the "study/TB2:S1020" part), and therefore we should beware of multiple domains that have the effect of creating synonymous URIs. bp |
|
From: Hilmar L. <hl...@ne...> - 2010-01-14 16:58:03
|
Looks nice to me, but anyone (i.e., any third party) could do that on top of each resource's individual base PhyloWS URL, couldn't they? I.e., this need not be a responsibility of the data resources per se, no? -hilmar On Jan 14, 2010, at 9:59 AM, William Piel wrote: > > On Jan 14, 2010, at 9:36 AM, Ryan Scherle wrote: > >> But domain names can and do change. > > Don't know if this is worth anything, but is there anything > "elegant" about an informal policy of putting phylows APIs in a > common base domain? > > eg.: > > purl.org/phylo/treebase/ > purl.org/phylo/ToL_web/ > purl.org/phylo/iplant/ > purl.org/phylo/phylr/ > > (etc) > > bp > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts > the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important > issues through > interactions with peers, luminaries and emerging and established > companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Ryan S. <rsc...@ne...> - 2010-01-14 15:04:51
|
> Realistically, how any one of these is significantly more likely than > * purl.org ceases operations Get out your crystal ball. But a number of libraries depend on purl.org, so I expect someone to keep it running for a long time. --- Ryan |
|
From: William P. <wil...@ya...> - 2010-01-14 15:00:00
|
On Jan 14, 2010, at 9:36 AM, Ryan Scherle wrote: > But domain names can and do change. Don't know if this is worth anything, but is there anything "elegant" about an informal policy of putting phylows APIs in a common base domain? eg.: purl.org/phylo/treebase/ purl.org/phylo/ToL_web/ purl.org/phylo/iplant/ purl.org/phylo/phylr/ (etc) bp |
|
From: Vladimir G. <vla...@du...> - 2010-01-14 14:43:41
|
On Jan 14, 2010, at 9:36 AM, Ryan Scherle wrote: > But domain names can and do change. We have no idea whether > treebase.org will still exist in 50 years. A few fun scenarios: > * Treebase merges with Dryad (tryad.org) > * Treebase is bought out by Google (phylogenetics.google.com) > * Treebase takes over all repositories in the world (the-one-uber- > repository.com) Realistically, how any one of these is significantly more likely than * purl.org ceases operations ? --Vladimir |
|
From: Ryan S. <rsc...@ne...> - 2010-01-14 14:36:32
|
On Jan 13, 2010, at 4:52 PM, Vladimir Gapeyev wrote: > At the moment, I have trouble seeing why TB should in any way depend on a third-party URL redirection service. The only valid reasons for PURLs that I see mentioned at http://en.wikipedia.org/wiki/PURL apply to poor people without their own domains. From a technical perspective, this is correct. As long as the organization has a commitment to maintain permanent URLs, any old domain name will do. But domain names can and do change. We have no idea whether treebase.org will still exist in 50 years. A few fun scenarios: * Treebase merges with Dryad (tryad.org) * Treebase is bought out by Google (phylogenetics.google.com) * Treebase takes over all repositories in the world (the-one-uber-repository.com) There are many possible situations in which it would not make sense to continue use of the treebase.org domain. Using a more neutral third party (purl.org) is one way to manage the changes. --- Ryan |
|
From: Vladimir G. <vla...@du...> - 2010-01-13 21:53:01
|
On Jan 13, 2010, at 2:32 PM, William Piel wrote: > my $0.01 thought is that using purls for all phylows URIs is > something we, at one point, decided to do. Since I am late to the party, could someone point me to more details on this matter? At the moment, I have trouble seeing why TB should in any way depend on a third-party URL redirection service. The only valid reasons for PURLs that I see mentioned at http://en.wikipedia.org/wiki/PURL apply to poor people without their own domains. As far as I understand the problem, the real stability issues of a URL like http://purl.org/phylows/study/TB2:S1020 lie not in its "http://purl.org/phylows" part but in its "study/ TB2:S1020" part -- and a redirect to http://treebase.org/phylows/study/TB2:S1020 does not help solving these issues at all, while http://treebase.org/phylows is as stable as http://purl.org/phylows. For a context: I am concerned with the matter only as far as considerations like > So, for example, our dev-build would be built using the global > phylows-property parameter "http://treebasedb-dev.nescent.org:8180/treebase-web/ > ", while the deployment build would be built using the global > parameter "http://purl.org/phylo/treebase/". That way we can easily > test new changes to TreeBASE on the dev server without all of its / > phylows/ links rerouting us to the deployment build. lead to complications of builds that could be avoided. --Vladimir |
|
From: William P. <wil...@ya...> - 2010-01-13 19:32:36
|
On Jan 13, 2010, at 12:47 PM, Hilmar Lapp wrote: > Isn't there a difference between the domain name of a resource, and > the PURL domain it may or may not use? We don't want to serve TB off > of the PURL domain and masquerading as such, right? And why is the > domain treebase.org not stable as a basis? Don't know if I quite understand the nuance here between a stable treebase.org and using purls. But my $0.01 thought is that using purls for all phylows URIs is something we, at one point, decided to do. By contrast, all non-phylows URLs can use whatever domain TreeBASE is running off of (and for the deployment build, treebase.org would point to this). So, for example, our dev-build would be built using the global phylows-property parameter "http://treebasedb-dev.nescent.org:8180/treebase-web/", while the deployment build would be built using the global parameter "http://purl.org/phylo/treebase/". That way we can easily test new changes to TreeBASE on the dev server without all of its /phylows/ links rerouting us to the deployment build. I suppose we could view the access-code-phylows as a "special" /phylows/ string that doesn't need domain name stability. So in that case we would not make use of the global phylows-property parameter, and would instead use whatever the domain name happens to be. bp |
|
From: Rutger V. <rut...@gm...> - 2010-01-13 18:24:00
|
Sure, that's fine. Note that this isn't operational yet anyway, but I'll be happy to rename to a more intuitive getter and property name. On Wed, Jan 13, 2010 at 5:47 PM, Hilmar Lapp <hl...@ne...> wrote: > I'm not entirely happy with the naming of the property and the getter > (getDomainName()). Would every developer who sees this assume it is > the TreeBASE domain name, treebase.org? > > Isn't there a difference between the domain name of a resource, and > the PURL domain it may or may not use? We don't want to serve TB off > of the PURL domain and masquerading as such, right? And why is the > domain treebase.org not stable as a basis? > > Why not just call it what it is: treebase.purl.domain for example, and > getPurlDomain()? > > -hilmar > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com |
|
From: Hilmar L. <hl...@ne...> - 2010-01-13 17:47:43
|
I'm not entirely happy with the naming of the property and the getter (getDomainName()). Would every developer who sees this assume it is the TreeBASE domain name, treebase.org? Isn't there a difference between the domain name of a resource, and the PURL domain it may or may not use? We don't want to serve TB off of the PURL domain and masquerading as such, right? And why is the domain treebase.org not stable as a basis? Why not just call it what it is: treebase.purl.domain for example, and getPurlDomain()? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Vladimir G. <vga...@ne...> - 2010-01-13 17:15:21
|
I have just committed the changes. Please try them out in your local setups. If you deploy treebase-web.war by coping it into $CATALINA_BASE/ webapps of an unconfigured Tomcat, there is only one thing to be done, besides the SVN update: specify DB credentials in /treebase-web/target/ treebase-web/META-INF/context.xml. Use context.xml.example for guidance. Thanks to Youjun's tips, the tests seem to run. (I hope errors and failures are the same as before!) We might want to switch from c3p0 DataSource to Apache DBCP, but that is not pressing, I think. More details are on the wiki https://sourceforge.net/apps/mediawiki/treebase/index.php?title=Databases --Vladimir |
|
From: Vladimir G. <vla...@du...> - 2010-01-12 20:31:52
|
The main reason is switching to JNDI. This will factor DB credentials (url, username, password) out of the WAR, allowing us to easily deploy (and redeploy) multiple instances of the application. As per my recent problem with the unit tests, I've now got a tip from Youjun on how to proceed, so I hope the two of us will be able to resolve this. --Vladimir On Jan 12, 2010, at 3:21 PM, Hilmar Lapp wrote: > > On Jan 12, 2010, at 3:19 PM, William Piel wrote: > >> >> On Jan 12, 2010, at 3:10 PM, Vladimir Gapeyev wrote: >> >>> Youjun has noted that the JNDI update will break the tests >> >> Is there a big advantage to switching from the mchange connection >> pooling package to commons-dbcp ? (meaning, despite being >> "obscure," if it works, is now the right time to switch this, given >> that we're in the final stretch for a TreeBASE release?) > > Bill - that's a good point, though switching or not switching the > connection pooling implementation won't affect or help with the JNDI > setup for unit tests. > > -hilmar > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast > and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel |
|
From: Hilmar L. <hl...@ne...> - 2010-01-12 20:22:03
|
On Jan 12, 2010, at 3:19 PM, William Piel wrote: > > On Jan 12, 2010, at 3:10 PM, Vladimir Gapeyev wrote: > >> Youjun has noted that the JNDI update will break the tests > > Is there a big advantage to switching from the mchange connection > pooling package to commons-dbcp ? (meaning, despite being > "obscure," if it works, is now the right time to switch this, given > that we're in the final stretch for a TreeBASE release?) Bill - that's a good point, though switching or not switching the connection pooling implementation won't affect or help with the JNDI setup for unit tests. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: William P. <wil...@ya...> - 2010-01-12 20:19:47
|
On Jan 12, 2010, at 3:10 PM, Vladimir Gapeyev wrote: > Youjun has noted that the JNDI update will break the tests Is there a big advantage to switching from the mchange connection pooling package to commons-dbcp ? (meaning, despite being "obscure," if it works, is now the right time to switch this, given that we're in the final stretch for a TreeBASE release?) bp |
|
From: Hilmar L. <hl...@ne...> - 2010-01-12 20:17:43
|
On Jan 12, 2010, at 3:14 PM, William Piel wrote: > If Mark didn't design it for multiple & incremental updating (e.g. > if each time you run it it creates more and more duplicate author > records), than yes, we should only do the 284-record update. That was exactly my concern, not the size of the file. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Hilmar L. <hl...@ne...> - 2010-01-12 20:16:47
|
JNDI services can be provided by many implementations. There are implementations that use the file system to serialize objects, or that use the memory. Developers will have to have one of those that you can include locally with the test suite (and exclude from deployment), and the unit test setup code will have to include code to instantiate the JNDI service and register the dataSource. That means that the unit tests would not be testing the correct deployment of the dataSource to the application server, but that sounds acceptable to me. -hilmar On Jan 12, 2010, at 3:10 PM, Vladimir Gapeyev wrote: > Youjun has noted that the JNDI update will break the tests: they are > executed on the developer side, where JNDI data sources are not > available. (Technical details: my update will re-define the > dataSource bean in treebase-core/src/main/resources/ > applicationContext- > dao.xml to look itself up in JNDI, instead of creating itself as an > object of class com.mchange.v2.c3p0.ComboPooledDataSource.) > > A correct resolution, I believe, should provide a Spring configuration > file that is an alternative to (new) applicationContext-dao.xml and > configure the tests to use this configuration. > > Anyone has ideas how to make this happen? I, unfortunately, do not > yet know enough about Spring and Maven to figure this out. > > --Vladimir > > > On Jan 11, 2010, at 3:45 PM, Vladimir Gapeyev wrote: > >> It looks like I have figured out how to set up Treebase to use JNDI >> data sources. Surgery on code and on the build procedures is >> surprisingly minor, but if anyone is concerned about effects on their >> not-yet-committed code, react soon. I'll commit my changes and post >> switch instructions Tuesday morning. >> >> A bonus question: TB currently does its Connection pooling via the >> package com.mchange.v2.c3p0.ComboPooledDataSource see treebase-core/ >> src/main/resources/applicationContext-dao.xml. Is anyone aware why >> this (obscure?) choice? Tomcat, by default, uses another pooling >> library (Apache commons-dbcp) behind DataSources that it serves via >> JNDI. I'd rather stick with the Tomcat's default. >> >> --Vladimir >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast >> and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Treebase-devel mailing list >> Tre...@li... >> https://lists.sourceforge.net/lists/listinfo/treebase-devel > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast > and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
9 messages has been excluded from this view by a project administrator.
