> >
> >Now or in the future?  In large measure because this is
> intended to be
> >a TLP, and the list of sub-projects is almost certain to grow over
> >time.  I think it makes sense to organize by component rather than
> >language.
> >
>
> What I'm digging at is the question of granularity.  Break
> out langauge
> at a fine grain component granularity would IMO be a mistake (or at
> least a unnecessary development overhead).  But breaking out at the
> level of subprojects would make sense.
>

I think the component level is the right place. To take an example from elsewhere, think of Tomcat's mod_jk. There's the project jakarta-tomcat-connectors, subproject jk and then components: eg the shared library for Apache and the Java connector for Tomcat. If you want to build "jk", you can change into that subproject and run ant or maven, which delegates to the components and asks them to build themselves, and it is at this level that it worries about what language it is and what artifact it is producing.

If it is split by language, you have to jump through some hoops to build "jk", and I don't see any reason why you would say "build all c programs", then "build all java programs", when potentially these subprojects are quite different.

This is especially important if using maven for the website, because you're site's structure is probably going to mirror the subproject structure, not the language structure.

So,

directory/
        subproject1/
                component1/
                        src/
                                conf/
                                c/
                        xdocs/
                component2/
                        src/
                                conf/
                                java/
                        xdocs/

Sounds good.

BTW, has anyone noticed that the reply-to address on the list isn't being set back to the list?

Cheers,
Brett