Reorganizing Repositories — Some help?

46 views
Skip to first unread message

Davey Shafik

unread,
Jul 19, 2012, 12:13:55 AM7/19/12
to frap...@googlegroups.com
Alright,

so one of the things I'm working through is the repository re-org; I've managed to create both a frapi-admin (basically src/frapi/admin/* moved to the top-level, removed src) and a frapi-common repo (src/frapi/library -> top, rm src), with frapi-admin using frapi-common as a submodule at /library.

I've pruned the repo history, so that they should be as small as possible, making cloning as snappy as possible... with one snag. Because frapi-common is just the /library folders contents, that means it includes Zend Framework. Which, due to it's size, slows down the checkout process.

For frapi-admin, that's not a big deal, but we need frapi-common in frapi-api also (for the Frapi lib, and currently Lupin which then needs ZF, but we're working to remove that dependency), which I feel defeats the entire purpose of splitting out the repos.

We could split out the Frapi library, and the Lupin library, into their own repos, and then have a 3rd party library repo for everything else? Now we have six repos. That's too many.

I'm really not sure how to solve this problem — any suggestions are welcome; it's really a blocker for everything in 0.2 at this point.

- Davey


Clay Hinson

unread,
Jul 20, 2012, 12:19:17 AM7/20/12
to frap...@googlegroups.com
Davey, 

I think the dependency issues can be solved by moving Lupin and ZF into the frapi-admin repository. 

1. Lupin: this can move to the frapi-admin repository, and for the frapi-api repo, refactor Frapi/Internal.php to use Input/XmlParser.php for reading the config XML files (when cache misses). The XML parser for input is document-agnostic and should have no problem parsing the config XML files. We may need a helper in front of it, but it should be small as frapi-api will only ever read these files. 

 Lupin is actually the smaller part of the ZF dependency, as it only uses ZF::Registry conditionally, and only in admin mode anyway.

2. The real ZF dependency is in Frapi_Authorization_Adapter_Xml , but that's also only used in the admin and doesn't need to be in the FRAPI library at all. That can be moved to the frapi-admin repository with minimal repercussions. 

Moving the above into frapi-admin will allow ZF to also move with them, reducing frapi-common to Frapi, Doctrine (classloader) and PEAR libs. 

- Clay 
Reply all
Reply to author
Forward
0 new messages