IoC TLP's
public class Log4J implements JakartaAware, LoggingAware
{
...
}public class Log4J
{
public void setJakarta(Jakarta jakarta) { ... }
public void setLogging(Logging logging) { ... }
}public class Log4J
{
public Log4J(Jakarta jakarta, Logging logging) { ... }
}=)
-Brian
On Dec 19, 2003, at 2:04 PM, Craig R. McClanahan wrote:
Quoting Harish Krishnaswamy <[EMAIL PROTECTED]>:
Thanks Craig, this is elaborate, informative and puts the issue in my perspective. May be this should be put on the website too somewhere.
Here are my inferences so far...
<inferences>
ASF is a group of projects administered by the Apache board members. The
board delegates certain
responsibilities over to the PMCs of the individual projects while still
maintaining the authority
and management responsibilities. The PMC is responsible for a wholesome code
and community of the
project it oversees but does not have the authority to recognize new
projects.
Jakarta started out as a single project for a web container and has grown
into a foundation of
projects in itself without sufficient administration/organization.
</inferences>
Waiting for the bureacracy to be created first is kind of antithetical to the
way most open source developers think :-).
Here are my thoughts distilled from a lot others'...
* I think the projects at ASF should be classified in some way (preferably by
technology like we
have now for xml, db etc.) into umbrella projects. All projects piled
together at the top level
would not convey very well. This is where Jakarta would need redefinition.
Seems like the inital
motivation, server side web development, is a good fit. And that would mean
some reshuffling.
The problem with "graph shaped" (single inheritance) hierarchies is that
sometimes a single project fits more than one place. For example, where do you
put Cocoon? It's clearly a thing that fits into an "XML Technologies" sort of
place. It's also a thing that clearly fits into a "server site technologies"
sort of place. The answer that Cocoon chose (the right one, IMHO) was to be a
separate TLP that is *linked* to both of those technology's web sites.
But, the more fundamental principle is that the legal organization of the ASF
need not have anything at all to do with how websites are organized and how
projects are made visible.
* I think each umbrella project or each project within could have a PMC and
each project should
maintain a PMC membership of atleast 51% of its committers to sustain.
That's pretty much the way that Jakarta works now (we've focused on expanding
the PMC membership over the last year to ensure coverage from all the
subprojects). But, as a Jakarta PMC member, it's still a daunting thought to
be held responsible for oversight of all the code, and all the releases, across
all of Jakarta. It's hard enough for me, for example, just to stay current on
the three projects I watch and try to participate in (Commons, Struts, Tomcat).
I'm pretty clueless about what the Tapestry folks are doing, yet *I* need to
approve releases?
Having Tapestry committers on the PMC helps, but isn't sufficient.
* I think the website should match the organizational structure to avoid
confusion.
I don't agree. The website(s) should be focused around making it easy for users
to find out what Apache projects might have products that are relevant to
their needs. The internal project organization is an implementation detail.
* I think the board should classify the newly adopted projects. Projects that
churn out of existing
projects should be brought back to the board for classification at the time
of creating new CVS
repositories.
* Each umbrella could have a commons and a sandbox to share and play.
* There could be a top level commons to house cross-umbrella components.
It seems like what we now have is pretty much in good shape and only means
that the following
actions take place...
* Reorganize Jakarta (and may be others??)
The interesting question is what Jakarta becomes after the subprojects that want
to become TLPs do so. I suspect that keeping it as a brand is likely to be
helpful, but the brand has been pretty muddled too (is it "Apache Struts" or
"Jakarta Struts"? Depends on which book title you read :-), and the earlier
perceptions that Jakarta had for high quality server side Java code is starting
to slip.
* Enforce project level PMC membership
IMHO, it's just not good enough to satisfy the oversight requirements delegated
to the PMCs by the ASF Board.
Just my thoughts.
Regards, Harish
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
