[OT] [JOKE] Re: Jakarta: Confederation or Single Project?
Holy war time:
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]
Re: Jakarta: Confederation or Single Project?
On Dec 19, 2003, at 2:27 PM, Ted Husted wrote: Harish Krishnaswamy wrote: 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. I'd say it the other way around. The ASF is a collection of communities that create and maintain codebases. To obtain infrastructure support and some legal protection, these communities donate the copyright of its software and ownership of its brand to the Foundation. In order to provide legal protection and watchdog its copyright, the board assigns a vice president to oversee the project. A committee is also convened to assist the VP with oversight. I think this is mostly right, and I say mostly because it's legally precise, but in practice, the community tends to be there first, rather than be convened later, and the community also tends to suggest to the board the individual they wish to 'oversee' (meaning the PMC chair). The board doesn't always accept the community's recommendation, though, and indeed the selection of chair is legally the board's sole assignment, as you way. Since the committee is formed by a resolution of the board, its members are eligible for legal protection in the event of a lawsuit. I don't believe this is correct, although it will require someone else to give a definitive answer. (I've been playing a bit in the legal sandbox re some ASF-related issues, so I've been paying attention to this...) Indemnification is granted for directors, officers and members of the corporation (the ASF), or serving at the request of the corporation in some way. Thus, the PMC chair, as an officer of the corporation is protected, but not all PMC members. However, the structure of the ASF is such that the ASF is the holder of copyright and owner of the code, which provides a level of protection for committers. Also, since the committee is the only formal body created by the board, only the votes of committee members are considered binding. In the normal course, most or all of the committers are also committee members. (Jakarta being an anomaly.) 100% correct [SNIP] A very subtle concept is that the ASF doesn't actually own the codebase. The codebase belongs to its community, and under the Apache License, that community can always vote with its feet. Since it is the community that gives the software its value (by using and maintaining it), there is an Apache belief that the community is the true owner of the codebase. The ASF just owns the brand and yesterday's copyright. I believe that this isn't right - the ASF does own the codebase via the copyright, and the codebase is licensed at no cost to any entity that is willing to agree to the terms of the license. That entity, community or otherwise, cannot remove that license or change it unilaterally. I think that my understanding of these issues has been clarifying over the last several months due to my JCP work. This stuff always is hard for us non-lawyers. To that end, as I am not a lawyer, all that I said above could be completely wrong :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
On Sat, 20 Dec 2003 07:36:20 -0500 Geir Magnusson Jr. wrote: One example might be a lawyer working closely w/ a community (for whatever reason) - that lawyer might be providing tremendous input and participation, but has no need/use for committership. That person could still be a member of the PMC. Well said. Also, i think PMC members do *not* have to develop source codes. For example, look at ORO. I've heard ORO team does not have 3 *active* committers, however, I believe some of PMC members (not ORO committers) can vote at oro-dev and can take *responsibilities* to the codes, when the vote of ORO X.Y.Z release. ORO-dev archive (open) memorizes who vote(d) and who are/were responsible to the votes. Anyways, I think Jakarta can have Jakartan-Way. Good luck, folks. Cheers, -- Tetsuya. ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Log4j is not leaving. It is simply moving to a new room in the house, a room with a different label but still located within the same house. As any house, this house offers protection and comfort to its inhabitants. It is a place where developers can unleash their creative powers onto the world. But this house is unique in its degree of openness and tolerance. Apache is a great place to be regardless of the room you chose. As for log4j, its developers will continue to be involved with Jakarta. Many of us use Jakarta products in our daily work. Moreover, without the software contained in Jakarta, there wouldn't be much use for log4j. So there are no goodbyes to be said, we are just next door. No need to put on shoes, you can hang on to your slippers. Our door is open, you don't have to knock when you come in. At 07:23 AM 12/20/2003 -0500, Geir Magnusson Jr. wrote: On Dec 19, 2003, at 3:33 PM, Costin Manolache wrote: Ted Husted : [SNIP] I agreed w/ every word from Costin. And look what's happening with logging: Now that it's a TLP, they are bringing-in the various Log4J compatibles. Now, there can be one Apache logging project serving every platform. That's community-building! Is logkit included in the logging TLP ? What about commons-logging ? I agree with you that the logging TLP does define a community ( just like jakarta or httpd ). It's a separate PMC bringing togheter different codebases and people. It remains to be seen if log4j as a TLP will be better than log4j as part of jakarta. There are plenty of TLPs - like apache-commons - that don't seem to be much better than sub-projects like jakarta-commons. Agreed. JC is a vibrant sub-project with ties to may Jakarta sub-projects. I think that important and valuable. I think log4j will do fine, and they can always come back. It's not clear what kind of synergy the log4* projects will bring together, but will be interesting to watch. I had such mixed emotions about log4j leaving, as I think it's going to take a bit of our community away. On the other hand, I support the freedom of the log4j community to choose it's own path, and that wins out with me. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
On Dec 20, 2003, at 8:24 AM, Ceki Gülcü wrote: Log4j is not leaving. It is simply moving to a new room in the house, a room with a different label but still located within the same house. As any house, this house offers protection and comfort to its inhabitants. It is a place where developers can unleash their creative powers onto the world. But this house is unique in its degree of openness and tolerance. Apache is a great place to be regardless of the room you chose. Well, you moved out of the Jakarta suite to another part of the Apache house :) As for log4j, its developers will continue to be involved with Jakarta. Many of us use Jakarta products in our daily work. Moreover, without the software contained in Jakarta, there wouldn't be much use for log4j. So there are no goodbyes to be said, we are just next door. No need to put on shoes, you can hang on to your slippers. Our door is open, you don't have to knock when you come in. public_pestering type=obligatory Can we have TRACE as a supported level? /public_pestering At 07:23 AM 12/20/2003 -0500, Geir Magnusson Jr. wrote: On Dec 19, 2003, at 3:33 PM, Costin Manolache wrote: Ted Husted : [SNIP] I agreed w/ every word from Costin. And look what's happening with logging: Now that it's a TLP, they are bringing-in the various Log4J compatibles. Now, there can be one Apache logging project serving every platform. That's community-building! Is logkit included in the logging TLP ? What about commons-logging ? I agree with you that the logging TLP does define a community ( just like jakarta or httpd ). It's a separate PMC bringing togheter different codebases and people. It remains to be seen if log4j as a TLP will be better than log4j as part of jakarta. There are plenty of TLPs - like apache-commons - that don't seem to be much better than sub-projects like jakarta-commons. Agreed. JC is a vibrant sub-project with ties to may Jakarta sub-projects. I think that important and valuable. I think log4j will do fine, and they can always come back. It's not clear what kind of synergy the log4* projects will bring together, but will be interesting to watch. I had such mixed emotions about log4j leaving, as I think it's going to take a bit of our community away. On the other hand, I support the freedom of the log4j community to choose it's own path, and that wins out with me. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki Gülcü For log4j documentation consider The complete log4j manual ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Geir Magnusson Jr. wrote: I'd say it the other way around. The ASF is a collection of communities that create and maintain codebases. To obtain infrastructure support and some legal protection, these communities donate the copyright of its software and ownership of its brand to the Foundation. In order to provide legal protection and watchdog its copyright, the board assigns a vice president to oversee the project. A committee is also convened to assist the VP with oversight. I think this is mostly right, and I say mostly because it's legally precise, but in practice, the community tends to be there first, rather than be convened later, Yes, that's what it says. A collection of communities that ... *not* a collection of codebases. [SNIP] A very subtle concept is that the ASF doesn't actually own the codebase. The codebase belongs to its community, and under the Apache License, that community can always vote with its feet. Since it is the community that gives the software its value (by using and maintaining it), there is an Apache belief that the community is the true owner of the codebase. The ASF just owns the brand and yesterday's copyright. I believe that this isn't right - the ASF does own the codebase via the copyright, and the codebase is licensed at no cost to any entity that is willing to agree to the terms of the license. That entity, community or otherwise, cannot remove that license or change it unilaterally. It owns a static image of the codebase, but from an Apache perspective, a codebase is a living, growing thing with a lifecycle that can endure for decades. The point is that without a community, even if it is a stable community of users helping users, the codebase has no value, and there is nothing *worth* owing. The board may sometimes disagree with a dysfunctional PMC, for the good of the community, but I don't believe the board would ever deliberately act against the community. The point of the exercise is to create communities around codebases, which means the community always comes first. (Else, there is no reason to have the codebase to begin with.) The essential difference between SourceForge and Apache is that SourceForge is just about sharing code. Apache is about building communities around the code we share. The reason a true community (in the Apache sense of the word) has never coalesced around Jakarta is that the subprojects were too coarsely grained to share code. So, we invented the Commons. The difference between Jakarta and Jakarta Commons is that the Commons has codebases that are *designed* to be shared with a community of developers and users. The truly marvelous thing about Jakarta Commons is that its communities transcend Jakarta. Everywhere I go in open-source land these days, I find other projects importing packages from the Commons. Thus, our license and style of management is exposed, and fresh blood is drawn into the Apache community, so that the cycle of life can continue. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
El sábado, 20 dici, 2003, a las 14:00 Europe/Madrid, Geir Magnusson Jr. escribió: On Dec 19, 2003, at 2:27 PM, Ted Husted wrote: (...) A very subtle concept is that the ASF doesn't actually own the codebase. The codebase belongs to its community, and under the Apache License, that community can always vote with its feet. Since it is the community that gives the software its value (by using and maintaining it), there is an Apache belief that the community is the true owner of the codebase. The ASF just owns the brand and yesterday's copyright. I believe that this isn't right - the ASF does own the codebase via the copyright, and the codebase is licensed at no cost to any entity that is willing to agree to the terms of the license. That entity, community or otherwise, cannot remove that license or change it unilaterally. I think the point Ted makes, summarized as: The ASF just owns the brand and yesterday's copyright. is, actually, subtle: Because of the Apache License, anybody wishing so can carry the code and keep the development outside of the ASF, with their own rules and licenses. This has only the brand and attribution restriction, as per our license. So, even if nominally, as you say, the code is the ASF property, anybody can re-license under different terms, provided that the ASF license conditions, the brand, essentially, are met. In the hypothetical event that the ASF would close our License (which, BTW, would be against the ASF charter), the commmunity could just stop contributing the same day (hence the yesterday's copyright), and keep the development elsewhere, with just a notice, a copy of the Apache License and a disclaimer (hence the brand). This implies that those having easier ability or will to maintain the product are the effective owners of it. as in a rapidly changing environment, software rot takes care of static code bases. Regards, Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Santiago Gala wrote: [SNIP] This implies that those having easier ability or will to maintain the product are the effective owners of it. as in a rapidly changing environment, software rot takes care of static code bases. Exactly. There is a saying from Dune: Whoever has the power to destroy a thing, owns that thing. (The case in point being melange.) The community has the power to effectively destroy the ASF's codebase by defecting and reforming elsewhere, leaving the ASF project dormant. Conversely, the ASF cannot destroy the codebase, since the community can just set up shop somewhere else under a new brand. Meanwhile, the ASF cannot create or maintain the codebase itself, since it has neither the resources nor the will. So, while the static copyright and the brand belong to the ASF, the living codebase belongs to the community that supports it. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
On Dec 20, 2003, at 11:36 AM, Santiago Gala wrote: El sábado, 20 dici, 2003, a las 14:00 Europe/Madrid, Geir Magnusson Jr. escribió: On Dec 19, 2003, at 2:27 PM, Ted Husted wrote: (...) A very subtle concept is that the ASF doesn't actually own the codebase. The codebase belongs to its community, and under the Apache License, that community can always vote with its feet. Since it is the community that gives the software its value (by using and maintaining it), there is an Apache belief that the community is the true owner of the codebase. The ASF just owns the brand and yesterday's copyright. I believe that this isn't right - the ASF does own the codebase via the copyright, and the codebase is licensed at no cost to any entity that is willing to agree to the terms of the license. That entity, community or otherwise, cannot remove that license or change it unilaterally. I think the point Ted makes, summarized as: The ASF just owns the brand and yesterday's copyright. is, actually, subtle: Because of the Apache License, anybody wishing so can carry the code and keep the development outside of the ASF, with their own rules and licenses. This has only the brand and attribution restriction, as per our license. Well, it's not terribly deep, IMO. They can fork and carry the code, but the code that is created has their own rules and license. The ASF code still has the ASF license and thus the rules in that license. I agree that the beauty of OSS is that anyone can continue w/ a project in their own way as they choose, but I just don't think it's that deep or subtle. That freedom is one of the reasons we all are here. So, even if nominally, as you say, the code is the ASF property, anybody can re-license under different terms, provided that the ASF license conditions, the brand, essentially, are met. Not at all. You can't relicense the code. The Apache Software License remains w/ the code. *new* code can have different terms, but not ASF-licensed code. In the hypothetical event that the ASF would close our License (which, BTW, would be against the ASF charter), the commmunity could just stop contributing the same day (hence the yesterday's copyright), and keep the development elsewhere, with just a notice, a copy of the Apache License and a disclaimer (hence the brand). They can't close the license retroactively - that's one of the great things about the license. There is no risk that in the future, the code you have now will become unavailable due to some kind of license change. *Future versions* released under a *different license* may be, but that is totally different. Using a version now doesn't require to use a version in the future. This implies that those having easier ability or will to maintain the product are the effective owners of it. as in a rapidly changing environment, software rot takes care of static code bases. However, you have to recognize that sometimes software is done. Look at ORO and Regexp. Do we use them because they are rapidly innovating, or because they do what they say they are going to do, and do it well? geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Harish Krishnaswamy wrote: How about Jakarta = Java Development? Then, they all seem in place, no? Henri Yandell wrote: Because it's wrong. XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all Java Development and not in Jakarta. Jakarta is the *brand*. It defines itself. Jakarta brand development. A brand can give a unique identity and grouping to an otherwise disparate and commodity range of goods and services. Think of any large brand: McDonalds: Fast food restaurants. And accommodation. And a childrens charity. Nike: Sneakers (trainers). And sports clothing. And fashion clothing. And a sports team. And a college (American) football league. Virgin. Music label. And music shops. And hot air balloons. And an airline. And trains. And mobile 'phones, drinks, health clubs, Internet service provider, credit cards, finance and car rentals. Personally, I think the Jakarta brand has much much more to say about *how* the software is developed and *how* the community operates than *what* products are offered, *what* language it is written in and *what* languages can use the products. So perhaps the Jakarta tagline should be ...it's in the process. ...it's in the community. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Michael Davey wrote: Jakarta is the *brand*. It defines itself. Jakarta brand development. A brand can give a unique identity and grouping to an otherwise disparate and commodity range of goods and services. Apache is a brand too, and, IMHO, a much stronger brand than Jakarta. I believe Jakarta distracts people from the fact that everything we do here is on behalf of the Apache Software Foundation. We are not Jakarta Committers, we are Apache Committers. We use the Apache License, package our product for apache.org, check code into cvs.apache.org, and donate every line to the Apache Software Foundation. I realize that there are people who have romantic notions about Jakarta and like to talk about preserving Jakarta for Jakarta's sake. But for the life of me, I can't see why. For me, it's always been about the codebase and its community. If a product I use is hosted at SourceForge, I work at SourceForge. If it's hosted at Jakarta, I work at Jakarta. If it's a top-level ASF project, then I work there. I go where my community lives; and my community is centered on a codebase, not a hostname. There are people who have called Jakarta a jewel. I'd agree that Cactus is a jewel, as is Lucene, and Velocity, and all the other *communities* we've built around our codebases. But Jakarta is not the jewel, at best it's a jewelry box. All along, there have been people who envisioned a Jakarta community. But, what's the point of that, really? We already have the Apache community and the open source community. Why do we need another community within a community? What's the point of another layer of indirection? In my experience, if you make a significant contribution to any open source codebase anywhere, its community will welcome you with open arms. We don't need hostnames to create communities. People create their own communities and forge their own relationships, by the simple virtue of their contributions. And look what's happening with logging: Now that it's a TLP, they are bringing-in the various Log4J compatibles. Now, there can be one Apache logging project serving every platform. That's community-building! The real, underlying issue with Jakarta is that most of our products are *not* about Java. They are about a feature set. Java was just a convenient implementation language, but most of our products could be implemented in other languages and made available to a broader community. In fact, many have, but since they are not Java implementations, we have multiple communities around a product instead of one. A language-centric project like Jakarta doesn't create community, it dilutes it. But I would not say that Jakarta is broken. I'd say Jakarta is finally starting to work. The proof that Jakarta is working is that products are finally growing up and becoming projects. Every worthy parent's goal is self-sustaining children. The Foundation, like a good parent, has always tried to build self-sustaining projects -- projects that can outlive their creators. I'm happy that some of these projects were born at Jakarta and became great enough to join our top-level peers. So, why are Ant, Maven, Logging, Slide, et al, graduating to top-level Apache projects: because they can :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
On Dec 19, 2003, at 8:01 AM, Ted Husted wrote: Michael Davey wrote: Jakarta is the *brand*. It defines itself. Jakarta brand development. A brand can give a unique identity and grouping to an otherwise disparate and commodity range of goods and services. Apache is a brand too, and, IMHO, a much stronger brand than Jakarta. Not to Java people. I agree w/ you that it should be, but Apache Jakarta serves just as well, just as Apache Httpd is a strong brand too :) I believe Jakarta distracts people from the fact that everything we do here is on behalf of the Apache Software Foundation. We are not Jakarta Committers, we are Apache Committers. We use the Apache License, package our product for apache.org, check code into cvs.apache.org, and donate every line to the Apache Software Foundation. I realize that there are people who have romantic notions about Jakarta and like to talk about preserving Jakarta for Jakarta's sake. But for the life of me, I can't see why. For me, it's always been about the codebase and its community. Jakarta is also a community - while it may also be a romantic notion, it is a fact. Denying that fact serves well the high-minded notion of for the Foundation, but ignores the reality. The ASF has seen the incredible growth of codebase, community and thus opportunity for participation in the projects like Jakarta, XML, WebServices, etc, all of which are larger umpbrella-like entities where like minded people can come together and work on whatever scratches their itch near and with others that also have the same interests. Preserving those fostering communities is a romantic notion worth working for, and not at adds with the ASF or it's governance requirements. It generates an opportunity for new ideas and collaborations to take hold, and a place go grow and live until the project wants to be a TLP. Or doesn't. :) geir P.S. And before you say Incubator Project, the Incubator is by design not intended to be such an entity, but rather a mechanism to ensure health and accounting of IP and community of incoming codebases and projects, the protection of the ASF. -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Radical view: allow the subprojects to send 1-2 delegates to the PMC and require each subproject to send one or die. This would size the PMC, assure that heart attack in the crowd syndrome doesn't take place and make the discussion more manageable. Have the sub projects manage their own policy for who to send and for how long under threat of being closed. This also prevents PMC for life syndrome and makes sure that the PMC serves not only the boards interests but the committers of the projects. It also puts pressure on PMC members to keep discussions public. -Andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] Date: Thu, 18 Dec 2003 22:26:44 -0800 To: Jakarta General List [EMAIL PROTECTED], Harish Krishnaswamy [EMAIL PROTECTED] Cc: Jakarta General List [EMAIL PROTECTED] Subject: Re: Jakarta: Confederation or Single Project? Quoting Harish Krishnaswamy [EMAIL PROTECTED]: Could someone please explain the motivation behind the creation of Jakarta and how it got to where it is today? May be that would help answer some of the questions we have? -Harish These comments are going to be (like anyone's would be) colored by my own personal experiences during the development of Jakarta -- including my ignorance of a lot of the details in subprojects that I'm not an active participant. But it should give you a little feel for the history of the place. The gist of the creation of Jakarta was around three facts: * Apache wasn't an incorporated entity (this is about four years ago now), but wanted to be -- and was formally becoming the Apache Software Foundation. * Apache had a project to build a servlet container (Apache JServ) at a website called java.apache.org which created a trademark-use issue around java. (I was a committer on Apache JServ, which is how I originally got involved in open source software.) * Sun wanted to contribute, and Apache wanted to accept, the source code for the servlet and JSP implementation called the Java Servlet Development Kit, and later published by Apache as Tomcat 3.0. Just as an item of slight historical interest, Jakarta was the name of the conference room at Sun where a lot of the early discussions took place. An organizational framework to focus on developing open source server side Java stuff was created to host these initiatives, and other related subprojects got proposed and added to the mix. As the number of Jakarta committers scaled from the original 10 or so to where we are today (hundreds), the original charter has become, umm, somewhat stretched. Ironically, it didn't take long at all for the scope of that original charter to get exceeded, because one of the little nuggets of code that was included in the original Tomcat contribution was a pure-Java build tool (to replace make) called Ant ... As more and more subprojects were added, there were some inevitable cases of overlapping scope, and overlapping implementations of the same ideas. One of the best things we've done (IMHO) was purposely creating a subproject (jakarta-commons) focused on making small, focused, reusable packages, and encouraging the larger projects to use them. Not only has this been successful within Jakarta -- there's been quite a lot of cross-fertilization among the web app frameworks, for example -- it's also created a fairly rich library of funcational packages that are widely used elsewhere. But one could really argue whether something like Commons Digester (originally designed as an easy-to-use tool to parse XML configuration files) really fit the Jakarta charter. Over time, there have been more than a few, err, voluminous discussions about how to scale up Jakarta from an organizational perspective, and whether the fundamental organizing principle was still the correct one. Does a focus on server side stuff exclude what could be some really interesting open source projects? Does a focus on Java make sense when just across the website there are things like xml.apache.org that are focused on a technology, not on an implementation language? Does it make sense to have community type projects that host individual software package projects at all? Coupled with these increasing concerns (at the ASF board level) about the ability of any oversight group (a responsibility delegated to PMCs in the ASF organizational structure), several original Jakarta subprojects (or even sub-sub-projects in some cases
Re: Jakarta: Confederation or Single Project?
Ted Husted wrote: Michael Davey wrote: Jakarta is the *brand*. It defines itself. Jakarta brand development. A brand can give a unique identity and grouping to an otherwise disparate and commodity range of goods and services. Apache is a brand too, and, IMHO, a much stronger brand than Jakarta. The relative brand strengths aren't important to this discussion (I think we will have to agree to disagree in any case). I was simply attempting to demonstrate two points: * a brand can unify products that otherwise would have no business being together * a brand can be used to give a concrete definition of otherwise abstract, ill-defined or hard-to-grasp concepts I realize that there are people who have romantic notions about Jakarta and like to talk about preserving Jakarta for Jakarta's sake. But for the life of me, I can't see why. For me, it's always been about the codebase and its community. [snip] I go where my community lives; and my community is centered on a codebase, not a hostname. [snip] All along, there have been people who envisioned a Jakarta community. But, what's the point of that, really? We already have the Apache community and the open source community. Why do we need another community within a community? To me, there is a difference between the Jakarta community and the Apache community. I think that the Jakarta community have a slightly different set of values than the wider Apache community. The values aren't wildly different, but they are different none the less. I think that this difference is most noticable in the discussions on lists like this. Now I'm not entirely sure I explicitly know both sets of values. In part this is because there is a difference between what the community claims as its values and how the community acts and in part because many of the values that the Jakarta community claims aren't written down. Certainly, the Jakarta community tend to go about their business in a slightly different way to the wider Apache community. Sometimes, the Jakarta way seems to work better or seems to be leading the way (for instance near-total transparency and openness, even when in means airing your dirty laundry, or commons and commons-sandbox) and sometimes the Jakarta way demonstrates that it hasn't learned the lessons that the wider Apache community learned the hard way (such as keeping secret the rationale for blocking an admision to a board of people). Perhaps there is actually a The Jakarta Way that is similar to The Apache Way, that is not explicit right now. Such a term could encapsulate the Jakarta process, approach to the community and values. The real, underlying issue with Jakarta is that most of our products are *not* about Java. They are about a feature set. Java was just a convenient implementation language, but most of our products could be implemented in other languages and made available to a broader community. Agreed. My fear is that if we don't work now to really understand The Jakarta Way, install the good bits into The Apache Way and document the problems and solutions to the bad bits, ASF may loose something of real worth and may not ever truely recover. I am not sentimental about the Jakarta name, but I do recognise that Jakarta represents something unique that we are in danger of loosing. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
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 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. * 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. * I think the website should match the organizational structure to avoid confusion. * 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??) * Enforce project level PMC membership Just my thoughts. Regards, Harish Craig R. McClanahan wrote: Quoting Harish Krishnaswamy [EMAIL PROTECTED]: Could someone please explain the motivation behind the creation of Jakarta and how it got to where it is today? May be that would help answer some of the questions we have? -Harish These comments are going to be (like anyone's would be) colored by my own personal experiences during the development of Jakarta -- including my ignorance of a lot of the details in subprojects that I'm not an active participant. But it should give you a little feel for the history of the place. The gist of the creation of Jakarta was around three facts: * Apache wasn't an incorporated entity (this is about four years ago now), but wanted to be -- and was formally becoming the Apache Software Foundation. * Apache had a project to build a servlet container (Apache JServ) at a website called java.apache.org which created a trademark-use issue around java. (I was a committer on Apache JServ, which is how I originally got involved in open source software.) * Sun wanted to contribute, and Apache wanted to accept, the source code for the servlet and JSP implementation called the Java Servlet Development Kit, and later published by Apache as Tomcat 3.0. Just as an item of slight historical interest, Jakarta was the name of the conference room at Sun where a lot of the early discussions took place. An organizational framework to focus on developing open source server side Java stuff was created to host these initiatives, and other related subprojects got proposed and added to the mix. As the number of Jakarta committers scaled from the original 10 or so to where we are today (hundreds), the original charter has become, umm, somewhat stretched. Ironically, it didn't take long at all for the scope of that original charter to get exceeded, because one of the little nuggets of code that was included in the original Tomcat contribution was a pure-Java build tool (to replace make) called Ant ... As more and more subprojects were added, there were some inevitable cases of overlapping scope, and overlapping implementations of the same ideas. One of the best things we've done (IMHO) was purposely creating a subproject (jakarta-commons) focused on making small, focused, reusable packages, and encouraging the larger projects to use them. Not only has this been successful within Jakarta -- there's been quite a lot of cross-fertilization among the web app frameworks, for example -- it's also created a fairly rich library of funcational packages that are widely used elsewhere. But one could really argue whether something like Commons Digester (originally designed as an easy-to-use tool to parse XML configuration files) really fit the Jakarta charter. Over time, there have been more than a few, err, voluminous discussions about how to scale up Jakarta from an organizational perspective, and whether the fundamental organizing principle was still the correct one.
Re: Jakarta: Confederation or Single Project?
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]
Re: Jakarta: Confederation or Single Project?
Andrew C. Oliver wrote: Radical view: allow the subprojects to send 1-2 delegates to the PMC and require each subproject to send one or die. This would size the PMC, assure that heart attack in the crowd syndrome doesn't take place and make the discussion more manageable. Have the sub projects manage their own policy for who to send and for how long under threat of being closed. This also prevents PMC for life syndrome and makes sure that the PMC serves not only the boards interests but the committers of the projects. It also puts pressure on PMC members to keep discussions public. I don't like this 1-2 delegates. All active committers in a subproject should be in the PMC ( unless they don't want to ). The concern that there are too many people is absurd. What is missing is a bit of discipline in proposals/votes - and that has nothing to do with the number of people. As you said, all discussions should happen on jakarta-general - so each jakarta committer ( including those who chose not to be in PMC ) get to participate and express their opinion. The vote should be on jakarta-general too ( counting as binding only PMC member votes, of course ). The difference between committers who are in PMC and the other should be only in the counting of the votes. The other argument - that nobody can or want to be responsible for codebases he is not involved with - is also bad. Each PMC member is overseeing whatever he chooses to ( typically the projects he is involved with and some he voluunteers to ). Every member of the PMC can vote on any issue - but it is common sense that those who are not involved with a codebase will abstain ( unless they have a good reason not to ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Ted Husted wrote: Michael Davey wrote: Jakarta is the *brand*. It defines itself. Jakarta brand development. A brand can give a unique identity and grouping to an otherwise disparate and commodity range of goods and services. Apache is a brand too, and, IMHO, a much stronger brand than Jakarta. I believe Jakarta distracts people from the fact that everything we do here is on behalf of the Apache Software Foundation. We are not Jakarta Committers, we are Apache Committers. We use the Apache License, package our product for apache.org, check code into cvs.apache.org, and donate every line to the Apache Software Foundation. We are apache committers - but each apache committer is also httpd committer or cocoon committer or jakarta comitter. You can't deny that HTTPD has a community of people, just like jakarta - which is not identical with the whole ASF ( even if ASF was originally the HTTPD community ). ASF is a collection of communities - some bigger, some smaller. Jakarta happens to be the bigger - and as long as you believe we are jakarta committers, you should also accept that jakarta _is_ a community just like httpd. A lot of people seem to have a problem with us feeling part of jakarta - and at the same time denying that jakarta is a community. IMO TLP is very closely related to community - in the sense that each TLP is or should be centered around a community. I realize that there are people who have romantic notions about Jakarta and like to talk about preserving Jakarta for Jakarta's sake. But for the life of me, I can't see why. For me, it's always been about the codebase and its community. If a product I use is hosted at SourceForge, I work at SourceForge. If it's hosted at Jakarta, I work at Jakarta. If it's a top-level ASF project, then I work there. I go where my community lives; and my community is centered on a codebase, not a hostname. I think it's not about codebase or hostname, but it is about community. As long as a project choose to remain part of jakarta - and refer to themself as jakarta committer - they are part of the jakarta community, just like an HTTPD committer is part of the httpd community. And a community with people from struts + tomcat + velocity + taglibs + cactus + POI + ( whatever projects choose to remain part of jakarta ) is IMO stronger that N separate TLPs, sourceforge-style. There are people who have called Jakarta a jewel. I'd agree that Cactus is a jewel, as is Lucene, and Velocity, and all the other *communities* we've built around our codebases. But Jakarta is not the jewel, at best it's a jewelry box. The fact that people from velocity, struts, poi, etc are all involved in this discussion about jakarta should mean that jakarta is a bit more than a sourceforge. All along, there have been people who envisioned a Jakarta community. But, what's the point of that, really? We already have the Apache community and the open source community. Why do we need another community within a community? What's the point of another layer of indirection? And if each codebase in jakarta becomes a TLP - wouldn't this be another level if indirection ? Apache community and open source community are all great - but both of them are one way or another an umbrella for multiple smaller communities. ASF is the real umbrella - not jakarta. Jakarta has multiple codebases and it started as an umbrella - but we managed to act and be perceived as a community. Not a perfect community. And look what's happening with logging: Now that it's a TLP, they are bringing-in the various Log4J compatibles. Now, there can be one Apache logging project serving every platform. That's community-building! Is logkit included in the logging TLP ? What about commons-logging ? I agree with you that the logging TLP does define a community ( just like jakarta or httpd ). It's a separate PMC bringing togheter different codebases and people. It remains to be seen if log4j as a TLP will be better than log4j as part of jakarta. There are plenty of TLPs - like apache-commons - that don't seem to be much better than sub-projects like jakarta-commons. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Bill Barker wrote: I'm sure that Craig or other will correct my mistakes (I haven't been here quite that long :). Jakarta started as Tomcat and friends after Sun donated Tomcat to the ASF (hence the name 'Jakarta' :). As the project grew (sign of success), Jakarta grew to include projects that don't necessarily rely on Tomcat (but could be used with), nor that Tomcat relies on. This has been the traditional server-side-java test. Now, Jakarta has been having projects that want to leave to ASF-TLP status (e.g. log4j, ant, maven, james). This is calling into question what the 'Jakarta' name stands for now. What this thread is about is trying to answer this question: what, if any, is the mission of 'Jakarta' going forward. I think Tomcat and friends remains an excelent definition :-) ( it's the friends part that is important - tomcat just happens to be the first project in jakarta :-) Costin - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Thursday, December 18, 2003 9:11 PM Subject: Re: Jakarta: Confederation or Single Project? Could someone please explain the motivation behind the creation of Jakarta and how it got to where it is today? May be that would help answer some of the questions we have? -Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - 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]
Re: Jakarta: Confederation or Single Project?
How about Jakarta = Java Development? Then, they all seem in place, no? -Harish Henri Yandell wrote: On Thu, 18 Dec 2003, Costin Manolache wrote: IMO it would be sad if projects like struts or tapestry leave jakarta - since they are closely related to web development and server side java ( compared with log4j or regexp for example ). So, Jakarta = Server side web development is the subtitle. Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in that they don't focus on that subtitle. Slide would be if a WebDAV TLP were to arrive. Just as a flamebait suggestion :) Hen - 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]
Re: Jakarta: Confederation or Single Project?
On Thu, 18 Dec 2003 20:24:00 -0500 (Subject: Re: Jakarta: Confederation or Single Project?) Harish Krishnaswamy wrote: How about Jakarta = Java Development? Then, they all seem in place, no? -Harish +1. Agreed. Why don't Jakarta adopt EU-like governance style? (Board = Secretariat of the United Nations: Jakarta Sub-Projects can have the status of Nation Jakarta itself is United Nations. Other TLPs are Nations) People often hold of the wrong end of the stick and assume that bylaws is for bylaws. -- NO -- Bylaws is *for* the components of each communities/organizations. I'd like to see -- Jakarta PMC: responsible for jakarta-site/jakarta-site2 Tomcat PMC: tomcat and related code Struts PMC: struts and related code Jakarta Commons PMC: ... Tapestry PMC: ... ... styled governance (what Noel mentioned) in jakarta tlp. I am not a laywer, however, there might be no legal problem. Regards, -- Tetsuya. ([EMAIL PROTECTED]) Henri Yandell wrote: On Thu, 18 Dec 2003, Costin Manolache wrote: IMO it would be sad if projects like struts or tapestry leave jakarta - since they are closely related to web development and server side java ( compared with log4j or regexp for example ). So, Jakarta = Server side web development is the subtitle. Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in that they don't focus on that subtitle. Slide would be if a WebDAV TLP were to arrive. Just as a flamebait suggestion :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Because it's wrong. XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all Java Development and not in Jakarta. If we go with this approach, we end up with the continuation of: should digester be in jakarta or xml etc. Does XML take precedence over the fact it's in Java, or does it just depend on which community creates or invites the codebase. As they have to go through the Incubator now [or be fast-tracked with the board's new scheme Greg mentioned], is the community inviting them in as important as it used to be. I'd much rather find a real subtitle for Jakarta that fits well [Cocoon is Java web development, but only indirectly I think, ditto for Avalon]. Hen On Thu, 18 Dec 2003, Harish Krishnaswamy wrote: How about Jakarta = Java Development? Then, they all seem in place, no? -Harish Henri Yandell wrote: On Thu, 18 Dec 2003, Costin Manolache wrote: IMO it would be sad if projects like struts or tapestry leave jakarta - since they are closely related to web development and server side java ( compared with log4j or regexp for example ). So, Jakarta = Server side web development is the subtitle. Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in that they don't focus on that subtitle. Slide would be if a WebDAV TLP were to arrive. Just as a flamebait suggestion :) Hen - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
That's true, so back to Jakarta = Server side web development! But is it restricted only to Java web development or just plain web development? -Harish Henri Yandell wrote: Because it's wrong. XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all Java Development and not in Jakarta. If we go with this approach, we end up with the continuation of: should digester be in jakarta or xml etc. Does XML take precedence over the fact it's in Java, or does it just depend on which community creates or invites the codebase. As they have to go through the Incubator now [or be fast-tracked with the board's new scheme Greg mentioned], is the community inviting them in as important as it used to be. I'd much rather find a real subtitle for Jakarta that fits well [Cocoon is Java web development, but only indirectly I think, ditto for Avalon]. Hen On Thu, 18 Dec 2003, Harish Krishnaswamy wrote: How about Jakarta = Java Development? Then, they all seem in place, no? -Harish Henri Yandell wrote: On Thu, 18 Dec 2003, Costin Manolache wrote: IMO it would be sad if projects like struts or tapestry leave jakarta - since they are closely related to web development and server side java ( compared with log4j or regexp for example ). So, Jakarta = Server side web development is the subtitle. Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in that they don't focus on that subtitle. Slide would be if a WebDAV TLP were to arrive. Just as a flamebait suggestion :) Hen - 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] - 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]
Re: Jakarta: Confederation or Single Project?
Not really (my POV) As people we naturally think in terms of the hierarchy ASF to Jakarta to MySubProject. But the middle layer is artificial. It could just as well be XML or DB or WebApps or Java or C or 'Projects starting with S' or 'Projects where Joe Bloggs works'. There simply is no one way of categorizing, hence there actually is no one community either. (ie. 'the jakarta community' simply does not exist in my eyes) The alternative is a one layer structure ASF to MyProject which gives full oversight, management and confidence both to the ASF and the ASF. Separately, there is a search website that allows searches by all the different ways that you might want to look things up. After all, the one layer (TLP) structure didn't harm Ant or James, and almost certainly benefitted Maven, Avalon and from the looks of it Log4J. In the end, actions will speak louder than words. Stephen - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] That's true, so back to Jakarta = Server side web development! But is it restricted only to Java web development or just plain web development? -Harish Henri Yandell wrote: Because it's wrong. XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all Java Development and not in Jakarta. If we go with this approach, we end up with the continuation of: should digester be in jakarta or xml etc. Does XML take precedence over the fact it's in Java, or does it just depend on which community creates or invites the codebase. As they have to go through the Incubator now [or be fast-tracked with the board's new scheme Greg mentioned], is the community inviting them in as important as it used to be. I'd much rather find a real subtitle for Jakarta that fits well [Cocoon is Java web development, but only indirectly I think, ditto for Avalon]. Hen On Thu, 18 Dec 2003, Harish Krishnaswamy wrote: How about Jakarta = Java Development? Then, they all seem in place, no? -Harish Henri Yandell wrote: On Thu, 18 Dec 2003, Costin Manolache wrote: IMO it would be sad if projects like struts or tapestry leave jakarta - since they are closely related to web development and server side java ( compared with log4j or regexp for example ). So, Jakarta = Server side web development is the subtitle. Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in that they don't focus on that subtitle. Slide would be if a WebDAV TLP were to arrive. Just as a flamebait suggestion :) Hen - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
I like the idea but does this mean we will be dumping the Jakarta banner? Or will it serve as an incubator for TLPs? The Jakarta banner has earned quite a reputation and would be a shame to dump it. -Harish Stephen Colebourne wrote: Not really (my POV) As people we naturally think in terms of the hierarchy ASF to Jakarta to MySubProject. But the middle layer is artificial. It could just as well be XML or DB or WebApps or Java or C or 'Projects starting with S' or 'Projects where Joe Bloggs works'. There simply is no one way of categorizing, hence there actually is no one community either. (ie. 'the jakarta community' simply does not exist in my eyes) The alternative is a one layer structure ASF to MyProject which gives full oversight, management and confidence both to the ASF and the ASF. Separately, there is a search website that allows searches by all the different ways that you might want to look things up. After all, the one layer (TLP) structure didn't harm Ant or James, and almost certainly benefitted Maven, Avalon and from the looks of it Log4J. In the end, actions will speak louder than words. Stephen - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] That's true, so back to Jakarta = Server side web development! But is it restricted only to Java web development or just plain web development? -Harish Henri Yandell wrote: Because it's wrong. XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all Java Development and not in Jakarta. If we go with this approach, we end up with the continuation of: should digester be in jakarta or xml etc. Does XML take precedence over the fact it's in Java, or does it just depend on which community creates or invites the codebase. As they have to go through the Incubator now [or be fast-tracked with the board's new scheme Greg mentioned], is the community inviting them in as important as it used to be. I'd much rather find a real subtitle for Jakarta that fits well [Cocoon is Java web development, but only indirectly I think, ditto for Avalon]. Hen On Thu, 18 Dec 2003, Harish Krishnaswamy wrote: How about Jakarta = Java Development? Then, they all seem in place, no? -Harish Henri Yandell wrote: On Thu, 18 Dec 2003, Costin Manolache wrote: IMO it would be sad if projects like struts or tapestry leave jakarta - since they are closely related to web development and server side java ( compared with log4j or regexp for example ). So, Jakarta = Server side web development is the subtitle. Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in that they don't focus on that subtitle. Slide would be if a WebDAV TLP were to arrive. Just as a flamebait suggestion :) Hen - 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] - 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] - 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]
Re: Jakarta: Confederation or Single Project?
Stephen Colebourne wrote: Not really (my POV) As people we naturally think in terms of the hierarchy ASF to Jakarta to MySubProject. But the middle layer is artificial. It could just as well be XML or DB or WebApps or Java or C or 'Projects starting with S' or 'Projects where Joe Bloggs works'. There simply is no one way of categorizing, hence there actually is no one community either. (ie. 'the jakarta community' simply does not exist in my eyes) I agree that we probably can't define Jakarta in terms of content in a way that will make everyone happy. I disagree, however, that this means that there is no community, or that Jakarta should be dissolved. I would say that Jakarta = the community. What are called Products on the web site are what this community produces. Java is one common denominator, but so are some common release management and decision-making practices (currently under debate / revision). I am much less bothered than others about the fact that not *all* server-side Java in Apache is in Jakarta or that some Jakarta projects might belong elsewhere. I really don't see why this is a problem. The only real problem that we have is making sure that we have sufficient oversight. The middle layer makes that look like more of a challenge, but that's only if you assume that oversight has to come from a small number of Jakarta PMC members. Growing the PMC (as we are now) so that all community activity has has direct PMC oversight will solve the oversight problem. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta: Confederation or Single Project?
Henri Yandell wrote: XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all Java Development and not in Jakarta. If we go with this approach, we end up with the continuation of: should digester be in jakarta or xml etc. Does XML take precedence over the fact it's in Java, or [...] There is an entire spectrum of possibilities between Jakarta as One Big Project, and Jakarta as a Confederation of Projects. And to be quite honest, so long as there is proper oversight, I generally couldn't care less where in the spectrum things get organized. When you come down to it, we ought to be facilitating an enlarged and healthy ASF Community, where everyone feels welcome to participate in whatever project(s) they find interesting. The PMC structure is about oversight. My view is that each subproject should decide how it wants to participate in the structure, so long as it ensures that proper oversight is provided. And this is why, however the projects decide to participate in a PMC, we should keep in mind that project organization does not have to be reflected by the web organization. If project P decides to have its own PMC, and wants to be present on the web as jakarta.apache.org/P, why should we say that it has to reside elsewhere? In fact, client-side-caching and performance aside for the moment, imagine if we had a new domain: my.apache.org which was running some portal software, and allowed people to customize their own view of the Apache Projects. People who wanted to track commits, news, e-mails, issues, and other information related to their favorite projects could see their customized portal view of the ASF. Perhaps impractical today, but just consider the possibilities when we stop thinking of the web site structure as reflecting our internal organization. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta: Confederation or Single Project?
Costin Manolache wrote: Noel J. Bergman wrote: Geir Magnusson Jr. wrote: Noel J. Bergman wrote: There is a difference between a hierarchy and a confederation. There is absolutely nothing that says that we cannot have: [list of PMCs] All without a single change to the Jakarta domain. No one should feel that there is any relationship between the Foundation's legal structure, and e-mail/web addresses. This is nothing I would encourage. There's really no question that it's legal. But it does then make Jakarta a website, rather than a community, IMO. I'd rather see the community. As I said in a reply to a message from Henri, I think that each project should be able to chose how it wants to participate in a PMC, so long as oversight is provided by the choice. But I still maintain that the web site structure does not have to, and should not be forced to, reflect that choice. Actually - it's jakarta PMC that does the oversight for Jakarta commons and all other jakarta subprojects. Hence my use of the terms de jure and de facto in my message. We have not made them the same, yet, but since we intend to do so, I see no need to debate the current status. :-) All committers who are active in jakarta are are willing should be part of the jakarta PMC. That's how things work in httpd and this is the right thing to do. If tapestry ( or any other sub-project ) doesn't feel like beeing part of a jakarta community or doesn't like oversight by the jakarta PMC - it is free to apply for top level status. I agree with both of those points ... so long as the second choice does not mean that the choosing project must relocate its web presence, although it may choose to do so. IMO it would be sad if projects like struts or tapestry leave jakarta - since they are closely related to web development and server side java Agreed. So are we agree that if one of them chooses to form its own PMC, we won't force them out of Jakarta? :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Could someone please explain the motivation behind the creation of Jakarta and how it got to where it is today? May be that would help answer some of the questions we have? -Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
I'm sure that Craig or other will correct my mistakes (I haven't been here quite that long :). Jakarta started as Tomcat and friends after Sun donated Tomcat to the ASF (hence the name 'Jakarta' :). As the project grew (sign of success), Jakarta grew to include projects that don't necessarily rely on Tomcat (but could be used with), nor that Tomcat relies on. This has been the traditional server-side-java test. Now, Jakarta has been having projects that want to leave to ASF-TLP status (e.g. log4j, ant, maven, james). This is calling into question what the 'Jakarta' name stands for now. What this thread is about is trying to answer this question: what, if any, is the mission of 'Jakarta' going forward. - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Thursday, December 18, 2003 9:11 PM Subject: Re: Jakarta: Confederation or Single Project? Could someone please explain the motivation behind the creation of Jakarta and how it got to where it is today? May be that would help answer some of the questions we have? -Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Quoting Harish Krishnaswamy [EMAIL PROTECTED]: Could someone please explain the motivation behind the creation of Jakarta and how it got to where it is today? May be that would help answer some of the questions we have? -Harish These comments are going to be (like anyone's would be) colored by my own personal experiences during the development of Jakarta -- including my ignorance of a lot of the details in subprojects that I'm not an active participant. But it should give you a little feel for the history of the place. The gist of the creation of Jakarta was around three facts: * Apache wasn't an incorporated entity (this is about four years ago now), but wanted to be -- and was formally becoming the Apache Software Foundation. * Apache had a project to build a servlet container (Apache JServ) at a website called java.apache.org which created a trademark-use issue around java. (I was a committer on Apache JServ, which is how I originally got involved in open source software.) * Sun wanted to contribute, and Apache wanted to accept, the source code for the servlet and JSP implementation called the Java Servlet Development Kit, and later published by Apache as Tomcat 3.0. Just as an item of slight historical interest, Jakarta was the name of the conference room at Sun where a lot of the early discussions took place. An organizational framework to focus on developing open source server side Java stuff was created to host these initiatives, and other related subprojects got proposed and added to the mix. As the number of Jakarta committers scaled from the original 10 or so to where we are today (hundreds), the original charter has become, umm, somewhat stretched. Ironically, it didn't take long at all for the scope of that original charter to get exceeded, because one of the little nuggets of code that was included in the original Tomcat contribution was a pure-Java build tool (to replace make) called Ant ... As more and more subprojects were added, there were some inevitable cases of overlapping scope, and overlapping implementations of the same ideas. One of the best things we've done (IMHO) was purposely creating a subproject (jakarta-commons) focused on making small, focused, reusable packages, and encouraging the larger projects to use them. Not only has this been successful within Jakarta -- there's been quite a lot of cross-fertilization among the web app frameworks, for example -- it's also created a fairly rich library of funcational packages that are widely used elsewhere. But one could really argue whether something like Commons Digester (originally designed as an easy-to-use tool to parse XML configuration files) really fit the Jakarta charter. Over time, there have been more than a few, err, voluminous discussions about how to scale up Jakarta from an organizational perspective, and whether the fundamental organizing principle was still the correct one. Does a focus on server side stuff exclude what could be some really interesting open source projects? Does a focus on Java make sense when just across the website there are things like xml.apache.org that are focused on a technology, not on an implementation language? Does it make sense to have community type projects that host individual software package projects at all? Coupled with these increasing concerns (at the ASF board level) about the ability of any oversight group (a responsibility delegated to PMCs in the ASF organizational structure), several original Jakarta subprojects (or even sub-sub-projects in some cases) like Ant, Maven, and James decided to become top level projects (TLPs) of their own -- this takes making a formal proposal to the ASF Board that gets accepted, and the formation of a PMC for that project. Those sorts of discussions continue to this day. Somewhat separately, but overlapping in time, it became clear that there needed to be a way to incorporate new developer communities (and in some cases existing codebases that were being contributed) into Apache. The developers (if they weren't Apache committers already) needed to learn the Apache way to do things. The code (if any) needed to be vetted for appropriate contributor agreements to protect both the ASF and those that rely on our code. Thus, the incubator project was created as a place for these things to happen. It is also actively evolving. personal-view To a large extent, the stresses that are felt as the ASF grows are actually a result of our success, and should not be looked at as signs of failure. I remember a statement from a consultant that one of my employers brought in along the way to deal with some important decisions when we had no consensus at all: The absence of stress is death. So, here's to having some more stress! :-) /personal-view Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
