[annotator-dev] Bower (Was: Re: Request for discussion: non-text annotations?)

Randall Leeds tilgovi at hypothes.is
Sun Nov 25 03:46:37 UTC 2012


On Thu, Nov 22, 2012 at 1:30 AM, Robert Casties <casties at mpiwg-berlin.mpg.de
> wrote:

> Hi Randall,
>
> On 21.11.12 22:18, Randall Leeds wrote:
> > (Side note, I'd love feedback about publishing annotator core and
> > plugins as bower packages:
> > https://github.com/okfn/annotator/issues/117#issuecomment-10096820)
>
> Bower looks nice ans simple at a first glance. How would building the
> final .min.js work? Can that be integrated with redo? (Figuring out how
> to build took me longest ;-)
>

We would still build the annotator repo with redo. I would add something to
the packaging scripts that populates a component.json (maybe templated, to
avoid duplicating version numbers, authors, etc) and uploads the package to
bower. The net change to the annotator repo is a component.json file.

Since bower tries to stay super simple, just helping you to manage what you
have downloaded, example use would go like this:

Start a project that you want to use annotator in.
Install bower.
`bower install github.com/okfn/annotator.git` (annotator(-full).(min.)js,
css and plugins would now be in components/annotator).

As time goes by and we release a new annotator version, getting the newest
version would be as simple as `bower update`. When projects have many front
end dependencies it simplifies the process of staying up to date.

As a plugin developer, I could add a components.json to my project and
specify a dependence upon annotator. Installing my plugin with bower would
automatically ensure annotator is also downloaded. It's a small thing, but
maybe becomes important if we have dependencies *between* community
plugins. Helps us all to keep the plugins we use up to date.

All this does it make it easier to manage which version of what javascript
you have checked into your project, and to express dependencies between
client-side javascript. Much of what is now the lib/vendor directory could
by populated / updated using bower. Even if we still commit that directory,
it would make it easier for maintainers to keep it updated.

Seems like a very simple file that solves issue #117. I originally brought
the issue up, wondering how to distribute a plugin. Maybe I'm just being
neurotic and I'm too infected by linux package management that I can't let
go of automatic dependency tracking.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20121124/0ad4a4a3/attachment.html>


More information about the annotator-dev mailing list