[Gmod-tripal-devel] Migration of Tripal to Drupal Project

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Gmod-tripal-devel] Migration of Tripal to Drupal Project

Stephen Ficklin-2
Hi Tripal developers!

We have a new Drupal developer, Alex, at WSU who just started.  He has jump started some topics we've discussed in the past.  For instance, when we submitted the Tripal paper one of the reviewer comments was that we look at migrating Tripal over to be a module (Project) on the Drupal website.  Right now you can't find Tripal when you look through the Drupal module repository.  Some of the advantages for making this transition would be that we would get automatic notifications when new Tripal modules are available and also we can automate installation of Tripal modules and upgrades using Drush.   This move would force us to follow the Drupal coding standards, which we need to do.

So, here is a proposed plan put together by discussions with Alex and myself and some input from Lacey too.   Let me know what you think:

1.  We create two Drupal projects:  a Tripal module project and a Tripal Theme project.
2.  We abandon the SVN repository and switch to the Drupal git respository. 
3.  We change the organization of our directory structure in this way:

Tripal Project:
/sites/all/modules/tripal/base/tripal_<module_name>   (for the core Tripal modules)
/sites/all/modules/tripal/extensions/tripal_<extension_name>  (for the extension modules)

Tripal Theme Project:

/sites/all/themes/tripal_theme/base/   (for the Tripal base theme)
/sites/all/themes/tripal_theme/subthemes/<extension_name>_theme/  (for the Tripal extension sub themes)

4.   With this structure we have a single Tripal module and all of the other modules (i.e. tripal_feature, tripal_organism, etc.) become sub modules.
 
5.  We handle extension modules a bit differently.  Extension modules get put back into the Tripal as sub modules.  But we store those in a separate 'extensions' directory. When someone downloads Tripal they get everything (base and extensions).  We also create sub themes corresponding to each extension sub modules..  These sub themes are part of the Tripal theme, but allow us to keep extension separate.   The process for submitted extension modules for inclusion in Tripal would be as follows.  We will create a testing suite using Jenkins (https://wiki.jenkins-ci.org/display/JENKINS/Home) and Sellenum (http://seleniumhq.org/) to ensure the extension modules don't conflict with the Tripal package. We expose this testing suite to developers to test their own modules.  If the modules pass we can then include them in Tripal.  We can also maintain the description of extension modules on the Tripal website to ensure folks get credit where credit is due.

The first step in migrating to Drupal is to create a sandbox where we can prepare the project for review.  After review and acceptance then Tripal becomes a full module on the Drupal site. After that we can then look at branching to Drupal 7.

Any objections or concerns or other ideas?

Stephen

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Gmod-tripal-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-tripal-devel] Migration of Tripal to Drupal Project

Chun-Huai Cheng
Hi all,

I'm glad Tripal is moving to Drupal.org!

We had a discussion about the way Tripal creates Durpal nodes for the
Chado data long time ago. As we're branching into Drupal 7, it might
be a good time to revisit this issue.

Right now we have a syncing mechanism to create Drupal nodes for all
Chado features/organisms/analyses/stocks. I'm thinking maybe we can
try getting rid of it and pull the data directly from Chado and create
the node on the fly.

We made the decision to sync data because we wanted to utilize
Drupal's built-in search function. However, the built-in search is
slow and wasn't very helpful for most of our projects. We had to
create separate search functions that query the Chado database
directly. The following are some pros and cons.

Pro:
1. No duplicate data. Genomic data are only stored in Chado database/schema.
2. Save time. No time-consuming syncing procedure.
3. Save space. The Drupal database will be much smaller and may run faster.
4. Easier code maintaining and developing for future modules.

Con:
1. Need a lot of effort to re-write code. (but we may need to do this
for migrating into Drupal 7 anyway.)
2. Loss of the Drupal built-in search capability.

Maybe we can try it as another branch? What do you guys think?

Chun-Huai


On Tue, Nov 8, 2011 at 1:15 PM, Stephen Ficklin <[hidden email]> wrote:

> Hi Tripal developers!
>
> We have a new Drupal developer, Alex, at WSU who just started.  He has jump
> started some topics we've discussed in the past.  For instance, when we
> submitted the Tripal paper one of the reviewer comments was that we look at
> migrating Tripal over to be a module (Project) on the Drupal website.  Right
> now you can't find Tripal when you look through the Drupal module
> repository.  Some of the advantages for making this transition would be that
> we would get automatic notifications when new Tripal modules are available
> and also we can automate installation of Tripal modules and upgrades using
> Drush.   This move would force us to follow the Drupal coding standards,
> which we need to do.
>
> So, here is a proposed plan put together by discussions with Alex and myself
> and some input from Lacey too.   Let me know what you think:
>
> 1.  We create two Drupal projects:  a Tripal module project and a Tripal
> Theme project.
> 2.  We abandon the SVN repository and switch to the Drupal git respository.
> 3.  We change the organization of our directory structure in this way:
>
> Tripal Project:
> /sites/all/modules/tripal/base/tripal_<module_name>   (for the core Tripal
> modules)
> /sites/all/modules/tripal/extensions/tripal_<extension_name>  (for the
> extension modules)
>
> Tripal Theme Project:
> /sites/all/themes/tripal_theme/base/   (for the Tripal base theme)
> /sites/all/themes/tripal_theme/subthemes/<extension_name>_theme/  (for the
> Tripal extension sub themes)
>
> 4.   With this structure we have a single Tripal module and all of the other
> modules (i.e. tripal_feature, tripal_organism, etc.) become sub modules.
>
> 5.  We handle extension modules a bit differently.  Extension modules get
> put back into the Tripal as sub modules.  But we store those in a separate
> 'extensions' directory. When someone downloads Tripal they get everything
> (base and extensions).  We also create sub themes corresponding to each
> extension sub modules..  These sub themes are part of the Tripal theme, but
> allow us to keep extension separate.   The process for submitted extension
> modules for inclusion in Tripal would be as follows.  We will create a
> testing suite using Jenkins
> (https://wiki.jenkins-ci.org/display/JENKINS/Home) and Sellenum
> (http://seleniumhq.org/) to ensure the extension modules don't conflict with
> the Tripal package. We expose this testing suite to developers to test their
> own modules.  If the modules pass we can then include them in Tripal.  We
> can also maintain the description of extension modules on the Tripal website
> to ensure folks get credit where credit is due.
>
> The first step in migrating to Drupal is to create a sandbox where we can
> prepare the project for review.  After review and acceptance then Tripal
> becomes a full module on the Drupal site. After that we can then look at
> branching to Drupal 7.
>
> Any objections or concerns or other ideas?
>
> Stephen
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Gmod-tripal-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel
>
>

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Gmod-tripal-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gmod-tripal-devel] Migration of Tripal to Drupal Project

Oleksiy Golovin
Hello,
If the primary/desired way of finding and accessing data is through views, the added overhead of integrating with the drupal search may not be desired. I am all for keeping the code simpler as well. Drupal Search is really not fast enough for large sites or searching through large amount of data. For that Apache Solar would be suited better, but is another can of worms in terms of setup and maintenance. There is also a google appliance from Google, that has very low setup and maintenance needs, but costs money.
Another point that is related, we could create a webservice to run queries against chado db on the dedicated prod or dev server, to alleviate the requirements of a local dev environment. Such a webservice could also be turned off on production. The difference would be that while loading pages or dealing with data from the remote db, the pages will load slower in the dev environment.
In turn we could have a large chado db of the different sites to be run from the same database. And have a dev copy of said db with laxer privileges, for devs working either on the server remotely or localy on their dev environment and fetching data from those large databases. I do not know if that is something of benefit to the projects themselves, but it may improve how we do dev on tripal. Plus the data would be synced up across all dev environments (if desired).
Those are my 2 cents :)

Alex




On Wed, Nov 9, 2011 at 11:15 AM, Chun-Huai Cheng <[hidden email]> wrote:
Hi all,

I'm glad Tripal is moving to Drupal.org!

We had a discussion about the way Tripal creates Durpal nodes for the
Chado data long time ago. As we're branching into Drupal 7, it might
be a good time to revisit this issue.

Right now we have a syncing mechanism to create Drupal nodes for all
Chado features/organisms/analyses/stocks. I'm thinking maybe we can
try getting rid of it and pull the data directly from Chado and create
the node on the fly.

We made the decision to sync data because we wanted to utilize
Drupal's built-in search function. However, the built-in search is
slow and wasn't very helpful for most of our projects. We had to
create separate search functions that query the Chado database
directly. The following are some pros and cons.

Pro:
1. No duplicate data. Genomic data are only stored in Chado database/schema.
2. Save time. No time-consuming syncing procedure.
3. Save space. The Drupal database will be much smaller and may run faster.
4. Easier code maintaining and developing for future modules.

Con:
1. Need a lot of effort to re-write code. (but we may need to do this
for migrating into Drupal 7 anyway.)
2. Loss of the Drupal built-in search capability.

Maybe we can try it as another branch? What do you guys think?

Chun-Huai


On Tue, Nov 8, 2011 at 1:15 PM, Stephen Ficklin <[hidden email]> wrote:
> Hi Tripal developers!
>
> We have a new Drupal developer, Alex, at WSU who just started.  He has jump
> started some topics we've discussed in the past.  For instance, when we
> submitted the Tripal paper one of the reviewer comments was that we look at
> migrating Tripal over to be a module (Project) on the Drupal website.  Right
> now you can't find Tripal when you look through the Drupal module
> repository.  Some of the advantages for making this transition would be that
> we would get automatic notifications when new Tripal modules are available
> and also we can automate installation of Tripal modules and upgrades using
> Drush.   This move would force us to follow the Drupal coding standards,
> which we need to do.
>
> So, here is a proposed plan put together by discussions with Alex and myself
> and some input from Lacey too.   Let me know what you think:
>
> 1.  We create two Drupal projects:  a Tripal module project and a Tripal
> Theme project.
> 2.  We abandon the SVN repository and switch to the Drupal git respository.
> 3.  We change the organization of our directory structure in this way:
>
> Tripal Project:
> /sites/all/modules/tripal/base/tripal_<module_name>   (for the core Tripal
> modules)
> /sites/all/modules/tripal/extensions/tripal_<extension_name>  (for the
> extension modules)
>
> Tripal Theme Project:
> /sites/all/themes/tripal_theme/base/   (for the Tripal base theme)
> /sites/all/themes/tripal_theme/subthemes/<extension_name>_theme/  (for the
> Tripal extension sub themes)
>
> 4.   With this structure we have a single Tripal module and all of the other
> modules (i.e. tripal_feature, tripal_organism, etc.) become sub modules.
>
> 5.  We handle extension modules a bit differently.  Extension modules get
> put back into the Tripal as sub modules.  But we store those in a separate
> 'extensions' directory. When someone downloads Tripal they get everything
> (base and extensions).  We also create sub themes corresponding to each
> extension sub modules..  These sub themes are part of the Tripal theme, but
> allow us to keep extension separate.   The process for submitted extension
> modules for inclusion in Tripal would be as follows.  We will create a
> testing suite using Jenkins
> (https://wiki.jenkins-ci.org/display/JENKINS/Home) and Sellenum
> (http://seleniumhq.org/) to ensure the extension modules don't conflict with
> the Tripal package. We expose this testing suite to developers to test their
> own modules.  If the modules pass we can then include them in Tripal.  We
> can also maintain the description of extension modules on the Tripal website
> to ensure folks get credit where credit is due.
>
> The first step in migrating to Drupal is to create a sandbox where we can
> prepare the project for review.  After review and acceptance then Tripal
> becomes a full module on the Drupal site. After that we can then look at
> branching to Drupal 7.
>
> Any objections or concerns or other ideas?
>
> Stephen
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Gmod-tripal-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel
>
>

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Gmod-tripal-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel


------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Gmod-tripal-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel