Break apart proposal

[ProLoser]

Assorted bullets I have done or need to tackle

• Continuing repo history from AngularUI
• Creating component.json with dependencies
• Creating a ui.select2 module
• Change ui.config to uiSelect2Config
• Create docs with subsection from demo page
• Create super-dumb test runner
• Add assets as submodules(?)

[ProLoser]

In the MAIN repo I want to have the following structure:

/
  docs/
    index.html -> uses ng-include to pull modules/select2/docs/*
  tests/
  build/
  modules/
    select2/ -> git submodule
  component.json -> "keywords":["angular","angularui","utilities"] or "bootstrap" or "widgets" or "recommended"
  package.json
  *

[petebacondarwin]

Build will contain build related utils or are you thinking of build Output?

... sent from my tablet
On Mar 6, 2013 12:57 AM, "Dean Sofer" notifications@github.com wrote:

In the MAIN repo I want to have the following structure:

/
docs/
index.html -> uses ng-include to pull modules/select2/docs/*
tests/
build/
modules/
select2/ -> git submodule
component.json -> "keywords":["angular","angularui","utilities"] or "bootstrap" or "widgets" or "recommended"
package.json
*

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-14476040
.

[ProLoser]

Umm... both-ish?

I am still having mixed thoughts about just about everything. See, I wanted to have 1 repo dedicated JUST to building, but then you guys wanted us to have several modules grouped together, so I felt like having this ui repo with others as submodules might only be a redundancy.

But after playing around with folder structures and ways to efficiently add resources (git submodules, bower components, etc) I feel like I'm back to square one.

The most RELIABLE way to get 1 file I can link to for test.conf.js is with bower, but these folders aren't submodules, and they aren't even maintained by the project owners. I felt almost like sitting on everything and going back to the twitter team and telling them they're morons for forcing every single project out there to create a duplicate repo JUST for bower.

Completely. Stupid.

I wish things were like CakePHP, git and submodules are how you manage plugins, and no one needs to build shit, or if they do, the main project takes care of it.

I feel like someone needs to develop a build system + package management system, but solutions like ender seem to go too far(?)

[petebacondarwin]

How about we create an npm module which is a grunt plugin that is
specifically created for building angular-ui modules. Then we can easily
have separate repositories for modules. In each repository you would have
the source files, the test specs, a simple test.config, the documentation
files a component.json, a package.json to bring in this grunt-angular-ui
module and a simple gruntFile.js that just loads up this module. Doesn't
solve where to put the built files though :-(

On 6 March 2013 07:44, Dean Sofer notifications@github.com wrote:

Umm... both-ish?

I am still having mixed thoughts about just about everything. See, I
wanted to have 1 repo dedicated JUST to building, but then you guys wanted
us to have several modules grouped together, so I felt like having this ui
repo with others as submodules might only be a redundancy.

But after playing around with folder structures and ways to efficiently
add resources (git submodules, bower components, etc) I feel like I'm back
to square one.

The most RELIABLE way to get 1 file I can link to for test.conf.js is with
bower, but these folders aren't submodules, and they aren't even maintained
by the project owners. I felt almost like sitting on everything and going
back to the twitter team and telling them they're morons for forcing every
single project out there to create a duplicate repo JUST for bower.

Completely. Stupid.

I wish things were like CakePHP, git and submodules are how you manage
plugins, and no one needs to build shit, or if they do, the main project
takes care of it.

I feel like someone needs to develop a build system + package management
system, but solutions like ender seem to go too far(?)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-14486672
.