Split modules to subprojects

I would keep Domain Views but move Domain Theme and Domain User into separate projects as they have very specific use case.
The same rule also applies to Domain Alias and Domain Prefix.

I think we might be able to make better progress on Domain Views if it had its own release cycle.

I think Domain Alias may be the most useful module of the bunch, actually, so I am tempted to keep it. It doesn't change frequently.

Don't know enough about the project (I just started testing it 1 week ago)
but I have the feeling that "domain blocks" is probably fit for the main project ...

@GirorgosK

The problem with that is that each new module in the package slows development of new features. It would be more efficient for me to split things up. I already rejected Domain Blocks for that reason.

I'm willing to maintain Domain Views if you really feel like it should be split from the main module.

It would be good to make a poll, to see what modules are used more often. Maybe my production sites usage will help.

I dont use this modules:
Domain Alias
Domain Prefix (not for begginers)
Domain Strict (this one is a traditional problem for people who dont read docs before usage) :)
Domain User (specific case)

Yeah, let's run down some logic on the module list:

- Domain (required)
- Domain Alias -- ultra useful for me in my dev environment where we use multiple SVN checkouts. Staying.
- Domain Conf -- first helper module written and probably the most popular submodule. Staying.
- Domain Content -- helper module. Non-essential, but not hard to maintain. Probably staying.
- Domain Nav -- kinda cool, but small utility. Easy to maintain and shows off the API a bit. Probably staying.
- Domain Prefix -- an experiment. Hard to use and for experts only. Probably split to separate module.
- Domain Source -- popular, but confusing to some. Probably needs to stay.
- Domain Strict -- shows off the API; too small to be released stand-alone, IMO. Probably stays.
- Domain Theme -- cool, but has lots of edge cases that would benefit from a release cycle. Might split.
- Domain User -- an experiment, with limited use case. Should be split.
- Domain Views -- very useful module, but would benefit from its own release cycle, though that is less important now that Views is stable. Might split.

Our production site uses:
Domain Conf
Domain Theme
Domain Views

Perhaps the solution for Views support is not to have it as a separate module but each submodule should provide its own views?
I vote for taking Domain Theme, Domain User and Domain Prefix out. Each of these are for a specific use case only.

Using

Domain Alias
Domain Blocks
Domain Conf
Domain Content
Domain Source
Domain Theme

I believe except Domain theme all the above make a fine bundle for users to start off.

I basically agree, except that Domain Blocks is a separate project now, and I'm not sure I want to bring it in.

These changes, btw, would affect the 7.x branch.

The following modules will be staying in the main package for D7.

-- Domain
-- Domain Alias
-- Domain Conf
-- Domain Content
-- Domain Nav
-- Domain Source
-- Domain Strict

And I _might_ split Domain into two modules, Domain, and Domain Access, making a generic domain handler in the process.

This means that the following are getting spun into separate projects:

-- Domain Prefix
-- Domain Theme
-- Domain User
-- Domain Views

The reasoning is that those 4 modules are quite complex, and need more attention.

Automatically closed -- issue fixed for 2 weeks with no activity.