How are you developing your engines?

#1

I’m trying to jump into developing engines, but I’m getting stuck with
how to structure my code.

Lets say that I have 2 projects that both include an engine. I’m
assuming the preferred method of working is including my engine using
svn:externals.

Does this allow you to edit code inside the engine in Project 1, and
commit it (so I could sync to the updated code in Project 2)?

Is this how most people are working on their engines or is there another
way?

Is anyone using Perforce or am I the only one?

Thanks…

#2

On 1/3/06, Seth removed_email_address@domain.invalid wrote:

I’m trying to jump into developing engines, but I’m getting stuck with
how to structure my code.

Lets say that I have 2 projects that both include an engine. I’m
assuming the preferred method of working is including my engine using
svn:externals.

Does this allow you to edit code inside the engine in Project 1, and
commit it (so I could sync to the updated code in Project 2)?

I’ve only written one small engine (Indexed Search Engine
http://langwell-ball.com/indexed-search/) so my experience is limited.
But here’s what I did.

I started by just writing an application and as I wrote the app I
realized that the search functionality could be extracted pretty
easily. So, I created a Subversion repository for the engine itself
and removed the engine code from my app.

The repository has 2 top level directories:

/indexed_search_engine (the engine)
/searchable_app (a sample application that I use to test and continue
development)

In the searchable_app, I have a symlink from
vendor/plugins/indexed_search_engine up to the top level directory.
This allows me to make changes in either the top level or within the
sample app itself without having duplication.

For my next application that uses the engine, I’ll just treat it like
any other external code by getting the version I want and installing
it.

Not sure if this really answers your question or fits your scenario…

Lance

#3

Lance B. wrote:

The repository has 2 top level directories:

/indexed_search_engine (the engine)
/searchable_app (a sample application that I use to test and continue
development)

In the searchable_app, I have a symlink from
vendor/plugins/indexed_search_engine up to the top level directory.
This allows me to make changes in either the top level or within the
sample app itself without having duplication.

For my next application that uses the engine, I’ll just treat it like
any other external code by getting the version I want and installing
it.

Thanks for the response Lance…

That seems very brittle to me. For instance, I develop across OSX and
XP. Symlinks aren’t too portable, or flexible. Yes I know you can
symlink on NTFS, but I’m kind of trying to avoid it.

Additionally, if you setup your projects like you mention it seems to me
like it’ll be hard to make changes on your next application to the
engine, then bring it back into the first.

Anyone else have some input on this one?

#4

Hey Seth,

I recommend using the steps outlined at:
http://rails-engines.org/wiki/pages/Extracting+Engines

As far as running the
$ script/generate engine CustomEngine

This will provide you will the full structure of your engine
sub-application.

In addition, SVN:Externals would work great. Simply use the
./script/plugin install -x
http://path.to.your/svn/repository/customengine

And the plugin will be added to your system. The -x flag signifies to do
an
svn:externals on that plugin instead of doing an export and loosing
track of
what revision the central engine repository is at.

Now, whenever you update your project root, it will update the
svn:externals
which are hooked into your plugin.

With tools like Eclipse, and tortoise, if I modify a externals and have
the
same username which is used for the project itself, SVN will update the
externals perfectly. This may be just a benefit of my environment, but
it
should hopefully work the same for you.

Regards,
Nathaniel.

 Nathaniel S. H. Brown                           http://nshb.net
#5

For your first ‘engine’ I’d recommend following Jon’s instructions on
the wiki - first, build your application as normal, then move anything
you’ve added to the ApplicationController or ApplicationHelper classes
into modules, and move the files over.

When I’m developing the login and user engines (and our internal
engines), we have a repository for engines, and another set of ‘test
projects’ (similar to what Lance describes) used solely for the
development and testing of the engine. We then use svn:externals to
include the engines in our actual client applications.

While you can certainly make changes to engines and commit them
directly back to the repository (and then update the other project to
merge the changes there), this can get a bit messy, and certainly
wouldn’t be recommended if you started needing to manage versions of
your engine. Here at my company we use SVN tag versions (which
shouldn’t be committed to) in running applications, and only the test
projects have svn:externals links to actual development branches or
the trunk.

  • james
#6

James A. wrote:

While you can certainly make changes to engines and commit them
directly back to the repository (and then update the other project to
merge the changes there), this can get a bit messy, and certainly
wouldn’t be recommended if you started needing to manage versions of
your engine. Here at my company we use SVN tag versions (which
shouldn’t be committed to) in running applications, and only the test
projects have svn:externals links to actual development branches or
the trunk.

Barring my switch to SVN from Perforce, I might try this same approach,
branching my engine into each project, then integrating changes back
into the engine “trunk” when necessary. Good idea.