RE: [PROPOSAL] The Commons - web connector
On Wed, 14 Mar 2001, GOMEZ Henri wrote: Still no response for this sub-project proposal. A big +1 This will also reduce the pressure on making changes in the "stable" code. If a bug is found in the connector - we can just make a new release of the connector ( both sides ), without a need to make a dot.dot release of tomcat. ( tomcat 3.3 should still include the current mod_jk, with some of the fixes that are "safe" and/or proven in the new potential module ) BTW, if the "commons" project is aproved, than this can be a part of the "sandbox"/"agora" - and it doesn't require any special aproval from PMC or other projects ( only a vote on tomcat-dev). I saw at least 4 potentials commiters working on it : - Dan Milstein, our resident hacker/expert of mod_jk. - Keith Wannamaker, webdav specialist - Pier P. Fumagalli, mod_jserv and mod_webapp father - I, Henri Gomez, mod_jk and adaptation to Apache 2.0 I can help with some performance and a bit in the C side. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
on 3/9/01 1:15 PM, "David Duddleston" [EMAIL PROTECTED] wrote: Just another rant Even after a few years, it still bugs me that license and copyright mark on each piece of Apache code is so darn long. Even a dog knows it only takes a few drops to marks its territory. -david Tell that to the lawyers. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
At 12:40 10/3/01 -0500, Geir Magnusson Jr. wrote: I have to side a little with Peter Donald on this, if you are serious about achieving this goal, then it is better to work with an existing project that is attempting to achieve some of the same goals. I would agree 100%, because of the benefits of community, but it's not clear to me what the Avalon goals are. Long story short - in my opinion (ie perhaps not all of Avalon groups) is that whatever you want to do that fits under the charter is something you are free to do ;) The way it is now is basically a result of the base work Fede/Pier/Stefano put down when originally architecturing the project. You think there is a better way of doing it then feel free to ask for access and hack away. If successful it will live - if not it may help improve other sections - so there is win-win ;) Maybe - but you can see the kind of things people are proposing we go get (like asking if Poolman wants to be contributed) or things that people are proposing be pushed into here, like the 'web connector' subproject, and org.apache.tools.tar and org.apache.tools.mail from Ant (I think). I suspect CJAN will be the main distribution point of all products in the future. In Ant2 I suspect each "group/jar" of tasks will be a separate CJAN entry while all the different utility components from other projects will be "productised" and spat out. This is just my opinion based on what people have bene saying though ;) (It also assumes publishing is easy). So we seem to be attracting code bases already, may go out and solicit existing ones from outside of Jakarta - if the value we add is to make them easy to find, document them well, and be a community that supports them *for their own sake*, then I think there is significant added value. Natural selection will take care of that - the best will get high "karma" ratings or whatever we implement for CJAN (some indication of how many projects/members use/vote-for component etc). So good packages will bubble to the top leaving behind all the crappy sediment ;) Cheers, Pete *-* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons
That could be - my problem when I went looking for things is that I surmised that Avalon was some sort of framework, rather than a collection of independent utilities. I got that idea because that is what the avalon site says... Peter and others are aware that this is often the perception. Yeah, not suprising at all. The documentation on the site does not give much of an indication that is it also repository of common classes. Only if you go back and read the messages regarding its creation do you get the idea that it was supposed to be the glue to intergrate several java apache projects and help them share code. I could be possible that this is not the true goal of Avalon anymore and it is just a framework for servers, but based on current activity, it seems much more than just a framework and a collection of interfaces. So we seem to be attracting code bases already, may go out and solicit existing ones from outside of Jakarta - if the value we add is to make them easy to find, document them well, and be a community that supports them *for their own sake*, then I think there is significant added value. I can imagine this would be a huge value and even more so if the other projects use them. I love the fact that most projects use Ant as a make tool. It makes my life so much simpler, since I only have to learn Ant and not a million different make tools. Same thing could be said for other things like a JDBC Connection broker. Even though it is not difficult to bounce from one broker to another (small learning curve) you still have to think, hmmm another implementation, where is the config file, how is the config file organized, and the biggest questions... is it well implemented and bug free. What is even more frustrating is seeing several incomplete implementations of the same project. I'm not against supporting new projects and allowing new ideas to evolve, but having consistency and quality is usualy more important. Try marking a lawyer. They seem to require more than a few drops.. :) I guess snakes require more droppings ;-) BTW, is there a listing of the all the proposed code bases to be part of the Commons? I would love to see good collections classes. I have some of my own implementation of OrderMap, type specific Lists and Map, but I'm sure the are better (optimized) implementation out there than mine. -david - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
David Duddleston wrote: Over the several years I have been lurking these forums, the topic of a shared library of common classes has been discussed several times and a few different attempts have been made to realize this goal, but all have either failed or fallen sort. Avalon is probably the closest project to supplying a useful set of library code, yet it lacks strong support from the community and only has a relatively small set of classes. That could be - my problem when I went looking for things is that I surmised that Avalon was some sort of framework, rather than a collection of independent utilities. I got that idea because that is what the avalon site says... Peter and others are aware that this is often the perception. [SNIP] I have to side a little with Peter Donald on this, if you are serious about achieving this goal, then it is better to work with an existing project that is attempting to achieve some of the same goals. I would agree 100%, because of the benefits of community, but it's not clear to me what the Avalon goals are. By starting a new project is just the same as another subproject writing its own utility class even though there is already some code in another project that is closely related. If you feel strong that this needs to be a new project, then create your own informal group and come back a few months later with an established code base. Maybe - but you can see the kind of things people are proposing we go get (like asking if Poolman wants to be contributed) or things that people are proposing be pushed into here, like the 'web connector' subproject, and org.apache.tools.tar and org.apache.tools.mail from Ant (I think). So we seem to be attracting code bases already, may go out and solicit existing ones from outside of Jakarta - if the value we add is to make them easy to find, document them well, and be a community that supports them *for their own sake*, then I think there is significant added value. Just another rant Even after a few years, it still bugs me that license and copyright mark on each piece of Apache code is so darn long. Even a dog knows it only takes a few drops to marks its territory. Try marking a lawyer. They seem to require more than a few drops.. :) One thing I've seen is that people put it at the bottom, so it's out of the way. Is there any legal implication regarding position? geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
Hi Steve! Steve Downey wrote: Please, let us not start the great brace and indentation holy war here. Nope sir, not my intention at all. Also, if you want to reformat code, take a look at astyle, (sorry don't have a URL handy) a syntax directed indent engine that converts between the various styles. Nope either, I don't want to reformat shared code. If anything, a fast reformat can help you browse some unknown code -- but you get used fast to reading other styles as well. And, since I haven't touched one line of Apache code yet, I have better be quiet :) Un saludo, Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons - web connector
On Fri, 9 Mar 2001, Nael Mohammad wrote: I for one would like to see mod_webapp Same for me - the automatic configuration is great for most users. Having this "common" project would be great because it'll allow the development of a connector that combines the best features of mod_jk and mod_webapp. Of course, this depends on having the "commons" aproved and started in a reasonable time, and on aproval from tomcat-dev people to share the connector, and of course on interest from Pier ( who is the main author of mod_webapp ) and Dan and the other people who maintain mod_jk. BTW, the protocol could be used for other projects that need to connect to apache ( and in many ways it belongs more to httpd then tomcat ). ( I would guess mod_perl and mod_php could also benefit from the load balancing features ) Costin -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Friday, March 09, 2001 4:11 PM To: [EMAIL PROTECTED] Subject: [PROPOSAL] The Commons - web connector Hi to all, What about a new sub-project, web connector, where all the developpement on mod_jserv and mod_jk (and why not mod_webapp) could live. Apache 1.3 and 2.0 are allready supported by mod_jk but also IIS, AOL, and NES (iPlanet) even JNI. Tomcat's 3.x and 4.x provide interfaces (modules, interceptor or whatever) that these connectors will implement :) A project which could be in The Commons even if there is still C code inside but also many java part (TC mod/interceptor). We could (must) see Tomcat 4.x use mod_jk or Tomcat 3.x use mod_webapp from Apache 2.0... Comments ? - 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: [PROPOSAL] The Commons
Ted Husted wrote:
Since I'm the lone wolf on this point:
snip
(3.1) mailing list(s)
jakarta-commons-general
jakarta-commons-DBCP (database connection pool)
jakarta-commons-sandbox (unreleased packages)
/snip
insert
(3.1) mailing list(s)
jakarta-commons
/insert
I think that I do agree with both sides : but I think that you are right
in the longer term - it will be clear as it evolves that we will need to
cut down on the noise if sub-sections get active enough. In the shorter
term, the single list will be community-building.
+1
and how about:
7. In general, packages should provide an interface and one or more
implementations of that interface, or implement another interface
already in use.
and:
23. Like all Jakarta subprojects, we adopt the Code Conventions for the
Java Programming Language as published by Sun. In addition, we specify
that indentation is constructed using 4 spaces only -- no tab
characters whatsoever.
I support the notion of standardization, but some of the Sun conventions
are just awful, particularly the bit about ending the method declaration
with a '{'
Futher, I like starting blocks with a { a la
if( foo )
{
block
}
I know it makes code 'big', but I personally find it easy to read, and
then if someone adds something, you don't get stuck with the bug
if(foo)
bar;
going to
if(foo)
woogie;
bar;
if they forget to add the braces, which can be a bear to find,
especially when groggy and tired :)
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons
Hola a todos, Ted: Since I'm the lone wolf on this point: snip (3.1) mailing list(s) jakarta-commons-general jakarta-commons-DBCP (database connection pool) jakarta-commons-sandbox (unreleased packages) /snip insert (3.1) mailing list(s) jakarta-commons /insert +1 and how about: 7. In general, packages should provide an interface and one or more implementations of that interface, or implement another interface already in use. +0 and: 23. Like all Jakarta subprojects, we adopt the Code Conventions for the Java Programming Language as published by Sun. In addition, we specify that indentation is constructed using 4 spaces only -- no tab characters whatsoever. +1721 ( it's the tabs count inside tomcat 3.3 sources :) Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
From: "Ted Husted" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 08, 2001 10:57 PM Subject: Re: [PROPOSAL] The Commons +1 to all your changes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
From: "Geir Magnusson Jr." [EMAIL PROTECTED]
I support the notion of standardization, but some of the Sun conventions
are just awful, particularly the bit about ending the method declaration
with a '{'
+1, but I fear it is too widely used in the Java world now :-(
Getting rid of the tabs is a start, though.
Conor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
Geir Magnusson Jr. wrote:
Futher, I like starting blocks with a { a la
if( foo )
{
block
}
Blech. I guess it takes all kinds. ;-)
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons
Jon Wrote: Additional: the issues surrounding logging and pluggable logging implementations are not covered here. I think they have the same importance as configuration. My vote is that we standardize on simply using Log4J and its interfaces for *everything*. +1 Two logging mechanisms is infinitely worse than one logging mechanism. It's even worse than NONE. With none, I can at least count on 21 logfile.log getting everything. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
1) There are religious battles over the hanging brace..
let's not start one here please. We can either follow the standard
or not, period... But the code should all look the same...
- on a side note, many people in my company have gone full circle
first fighting for the hanging brace ( what you want ), and now
hating having done that.. i don't why, I'm not one of those...
2) The one line "if" statements are already strongly discouraged in the
Sun convention.. for precisely the reasons you gave
fern
I support the notion of standardization, but some of the Sun conventions
are just awful, particularly the bit about ending the method declaration
with a '{'
Futher, I like starting blocks with a { a la
if( foo )
{
block
}
I know it makes code 'big', but I personally find it easy to read, and
then if someone adds something, you don't get stuck with the bug
if(foo)
bar;
going to
if(foo)
woogie;
bar;
if they forget to add the braces, which can be a bear to find,
especially when groggy and tired :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
on 3/8/01 8:57 AM, "Ceki Glc" [EMAIL PROTECTED] wrote: To summarize, I think that as an organization we should consider APIs on the basis of their merit and their respective advantages/disadvantages. Saying that we should adopt API XYZ just because it is Sun sponsored is not the wisest way to proceed. Regards, Ceki Yes. Well said. Primary example API's that are not being considered enough based on their advantages/disadvantages: EJB and JSP -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
Gunnar R|nning wrote: "Geir Magnusson Jr." [EMAIL PROTECTED] writes: The thing that started this, about the coding guidelines, was in response to the addition of the Sun coding guidelines (rules...) - I was just indicating my preference. Of course, but it is important to be able to accept and tolerate different [SNIP] Geir - this is not to take it out on you, but I've been pretty annoyed/frustrated with people trying to specify to much. Better keep it simple - I have no problem reading code in different styles and I usually keep to the style of the author if I have to modify some code. Tolerance and respect for cultural richness is what I advocate. Opening braces on the same or next line - it is still code - black or white - you're still a human being. Unless I am a code generator, in which case, well, I'm a code generator. Seriously - I have to admit I do like some regularity to coding style, especially when we have this 'free' environment in Commons where any committer can commit anywhere. However, I was just indicating my dislike for some of the Sun coding standards which seemed to be hinted at as useful for Commons. mine kroner, Isn't that something like US$0.11? Gunnar geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
Ted Husted [EMAIL PROTECTED] wrote: Conor MacNeill wrote: I think it would be better to start with one mailing list so ensure there is enough "mass" in discussions. I feel strongly that there should be a combined user/dev list for each package, and I personally stand by the statement in the FAQ. snip/ We feel that if we do not keep the list traffic separate, it may be much harder for people to focus on the packages they care about. I think the key phrase is "start with". Say I'd propose to move the org.apache.tools.tar and org.apache.tools.mail packages from Ant to the commons repository - which I'll probably do - these are very small thingies that don't really need separate mailing lists at all. How about starting with a common list and create lists for the packages that generate enough of traffic - I'm guess this could very soon happen for the dbcp stuff. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
Ted, Let me give my counter point and then I will say no more. IMHO, for a list to be useful it needs to have a certain critical mass of subscribers. When there aren't enough people to get a discussion going, people stop posting. If the messages are few and far between, the list tends to atrophy altogether. You need community and you need cross-fertilization of ideas from that community. Maybe it is like the gene pool - if there aren't enough people participating, it doesn't work. If there was one list for the commons, more people will be exposed to each component of the commons. It will make the components more well known. People may not need a component now but they may remember later a discussion about some capability. I feel that one of the keys to the success of the commons will be how well its components are known, because only then will they be reused. Conor - Original Message - From: "Ted Husted" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 07, 2001 11:57 PM Subject: Re: [PROPOSAL] The Commons Conor MacNeill wrote: Ted, Sounds good to me. I think it would be better to start with one mailing list so ensure there is enough "mass" in discussions. I feel strongly that there should be a combined user/dev list for each package, and I personally stand by the statement in the FAQ. -- Why is there a separate mailing list for each package? It's possible that many users or developers may be interested in a single package or two. We feel that if we do not keep the list traffic separate, it may be much harder for people to focus on the packages they care about. Since this is a volunteer effort, we must be very sensitive to the time constraints and attention spans of our developers and users. People who have a wider interest can just subscribe to additional lists. If this doesn't work out, it would be a simple matter to merge the subscription lists later. -- I believe that if "the unit of reuse is the unit of release", then it should also be the unit of subscription. -Ted. - 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: [PROPOSAL] The Commons
At 09:21 7/3/01 -0500, Ted Husted wrote: Peter Donald wrote: I will say it again - though no one really seems to listen. No one's asking you to do anything you don't want to do, Peter. If you are not comfortable working on a Commons package, then you should not work on a Commons package. I already work on commons packages - after all I work on Avalon ;) Meanwhile, we've got nine committers here who do want to collaborate on packages in the Commons setting. It has to be about what committers will commit to, because, as Roy Fielding said, "that's pretty much the only way to ensure that what we do remains a true collaboration and doesn't degrade into some sort of consortium or a mirror of our real jobs." If the nine committers are devoted to it then it will happen regardless of where. If you have an aversion to Avalon then road test it elsewhere. Startup a sourceforge project and start building a community there. If after 6 months the project has proven itself, has a community and has actually achieved (or looks like achieving) it's goals then I will help you lobby everyone to get it under Jakarta-Apache umbrella. If you look back at the java.apache.org site you will notice that not every project hit the bigtime. Yet they still carried the Apache name and presumably apache members gave at least peripheral support to the projects. This degrades the value of the Apache name (which is meant to be one of the benefits of being an official Apache project) and is a drain on the more devoted apache peeps. Besides IMNSHO not only do projects have to have a commitment to Apache but Apache has a commitment to it's projects. I think duplicating a project due to NIH is a violation of that commitment in all but a few circumstances (of which this is not one). Cheers, Pete *-* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
Say I'd propose to move the org.apache.tools.tar and
org.apache.tools.mail packages from Ant to the commons repository -
which I'll probably do - these are very small thingies that don't
really need separate mailing lists at all.
+1 !!
And maybe parts of ProjectHelper ( turned into a introspection. package ),
and the ${var} stuff. It's great code, very useful.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
on 3/7/01 5:08 AM, "Sam Ruby" [EMAIL PROTECTED] wrote: Jon Stevens wrote: 7: Should provide an interface or implement a Sun defined interface. s/Sun defined/standard/ - Sam Ruby define standard. http://jakarta.apache.org/velocity/ymtd/ymtd-implementation.html -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
on 3/7/01 5:21 AM, "Ted Husted" [EMAIL PROTECTED] wrote: How about: 7. In general, packages should provide an interface and one or more implementations of that interface, or implement another standard interface (e.g. one defined by Sun). -1 I don't like the implication that something defined by Sun is a standard. To me, a standard is something that is open. Sun isn't open. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
on 3/7/01 4:57 AM, "Ted Husted" [EMAIL PROTECTED] wrote: I feel strongly that there should be a combined user/dev list for each package, and I personally stand by the statement in the FAQ. This will fail for new projects. Reason: community building. To create a community, you need a single list. When there is a community, that is when you branch out to two lists. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
Peter, On Thu, 8 Mar 2001, Peter Donald wrote: I already work on commons packages - after all I work on Avalon ;) Avalon is not a commons package, it is a "common framework for server applications". Why does the framework need to contain code to accomplish specific tasks? What Ted proposes is the creation of a "Commons" library that will hold utility APIs that will be useful in every Jakarta project, including Avalon. Avalon and the "Commons" proposal are not at odds - they are compliments. Avalon codebase provides a framework for developing modular server applications. Avalon should be able to peacefully coexist with a library of utility code such as Ted proposes. For example, if a developer wanted to create a "Connection Pool" Block they could easily develop a wrapper Block component, and a meta-info description file. I don't see how Ted's proposal is at odds with the Avalon project. Wouldn't having a "Commons" library make it much easier to expand Avalon? Tim O'Brien [EMAIL PROTECTED] PS: Congratulations to the new PMC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
At 02:53 7/3/01 -0600, Tim O'Brien wrote: Avalon is not a commons package, it is a "common framework for server applications". Why does the framework need to contain code to accomplish specific tasks? The perception that it is solely a framework is wrong. Frameworks by themselves are useless beasts ;) Avalon codebase provides a framework for developing modular server applications. Avalon should be able to peacefully coexist with a library of utility code such as Ted proposes. For example, if a developer wanted to create a "Connection Pool" Block they could easily develop a wrapper Block component, and a meta-info description file. Blocks are not part of Avalon as such - they are part of Phoenix/Cormerstone (The application server part). This will eventually be split off. Compare your perception of Avalon to the original call to vote/why-we-need Avalon documents in history section of Avalon web page. Once Phoenix/Cormerstone are split off, util is split off and the general components are placed in whatever Commons becomes - what do you see Avalon being? (If you say glorified component model then your answer would be correct ;]). I don't see how Ted's proposal is at odds with the Avalon project. Wouldn't having a "Commons" library make it much easier to expand Avalon? yes sure. Think of it this way. I want to see the infrastructure in place for all projects - as a separate project this has more possibility of occuring. Now this project has a high risk factor. Several other attempts have been made in past to do things like this and "failed". Working on unapplied/infrastructure components is unsexy/difficult/lots of work - especially when you have to jump through as many hoops as will developers on this project (mainly to keep the N projects that rely on component uptodate/aware of changes). For all means lets develope it under org.apache.commons hierarchy with the view to making it a separate project. Usually these projects will loose steam and within a year the commons will be either just another framework (like AValon was a while back) or will loose all the active development as the project looses it's luster. Sure we may get a few decent components out of it - likely we will also get some crap too ;) Now if it fails like this it would be up to the remaining apache members to offer support etc. However if we host it somewhere else (ie Avalon or sourceforge) give it some time to grow and see if it will actually work then there is low risk. If it succeeds then good for it - surely it will be split off/hosted under Apache - if not then it is just a dead proposal in another project (ie no-one has to maintain it ;-O). PS: Congratulations to the new PMC thanks. Cheers, Pete *-* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons
Ted, Sounds good to me. I think it would be better to start with one mailing list so ensure there is enough "mass" in discussions. Also, I am a bit dubious about the name "commons" (Don't know if there has been much discussion about that). The concept of a Commons is often used as an example of things that get abused because there is no ownership. If the name is up for discussion, can I suggest the name "substrate"? Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons
Nice initiative. Sharing code is allways great and there are in jakarta projects some fine pieces of code which could be used outside their 'original' project. A suggestion will be to ask all of you to do your best to organize this subproject in many smaller sub-subprojects just to avoid finishing with an UGLY library ( la GLIBC). (4) identify the initial set of committers Morgan Delagrange Ted Husted Geir Magnusson Jr. Costin Manolache Remy Maucherat Craig R. McClanahan Ignacio J. Ortega Rodney Waldhoff David Weinrich Count me on RPM packaging (will help check/specify cross dependencies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
The archive for the interim "library-dev" mailing list is at mail-archive.com There is also a page linking the working documents at http://husted.com/about/jakarta/library.html . My own preference is that it be called something simple and generic. (I was good with library.) Conor MacNeill wrote: Ted, Sounds good to me. I think it would be better to start with one mailing list so ensure there is enough "mass" in discussions. Also, I am a bit dubious about the name "commons" (Don't know if there has been much discussion about that). The concept of a Commons is often used as an example of things that get abused because there is no ownership. If the name is up for discussion, can I suggest the name "substrate"? Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
on 3/6/01 2:03 PM, "Ted Husted" [EMAIL PROTECTED] wrote: Proposal for "The Commons" - A Jakarta Subproject version 1.0 - 5 Mar 2001 (0) rationale Apache-Java and Jakarta originally hosted product-based subprojects, consisting of one major deliverable. The Java language however is package-based, and most of these products have many useful utilities. Some products are beginning to break these out so that they can be used independently. A Jakarta subproject to solely create and maintain independent packages is proposed to accelerate and guide this process. (1) scope of the subproject The subproject shall create and maintain packages written in the Java language, intended for use in server-related development, and designed to be used independently of any larger product or framework. Each package will be managed in the same manner as a larger Jakarta product.To further this goal, the subproject shall also host a workplace for Jakarta committers and a master index of reusable packages related to Jakarta products. (1.5) interaction with other subprojects (1.5.1) the sandbox The subproject will host a CVS repository available to all Jakarta committers as a workplace for new packages. Before releaseto the public, a sandbox package must be accepted to the library, or sponsored by another Jakartasubproject. (1.5.2) the directory The subproject will also catalog packages and other resources available to the public related to other Jakarta subprojects and ASF projects. This will be a dynamic catalog, like Bugzilla and Jyve, similar in functionality to download.com, cpan.org, or SourceForge.net. New entries may be added by Jakarta committers, developers, and users. Entries by developers and users will be approved by a committer before being made public. (2) identify the initial source from which the subproject is to be populated The initial packages would be based on existing ASF codebases, including those that provide services for DataSource/Database Pools, XML Configuration, Message Resources and i18n, JNDI and Naming, and Testing Suites. The initial committers have agreed to first create and maintain a Database Connection Pool package, along with related testing suites and subproject infrastructure. Comments: You haven't covered what happens with regards to management of these projects. Is it the initial committers responsibility to maintain each of these products? What is the long term outlook on these code bases? For example, in the Java Apache project, we had a java-whiteboard CVS tree (look at the /site/cvsindex.html page for the CVS tree). This was quite a bit of code that was abandoned over time. I would suggest maintaining the current feeling that all projects should have a minimum of 3 responsible people who oversee each of the projects. You also have not covered the possibility of competing implementations. For example, what if someone doesn't like the existing database connection pool and wants to contribute another product that duplicates the functionality? You also have not covered the possibility of an existing Jakarta project which has a competing implementation of something that exists in the commons. Is there some sort of policy that is being proposed at the higher Jakarta level that requires sub projects to become part of this project? [I actually think that this might be a good thing in order to help foster the community]. Other than the above comments (which are really asking more for clarification rather than being negative) I am +1 to see this happen. thanks, -jon stevens -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
