Re: Web Components/Common project
On 8/8/05, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/8/05, robert burrell donkin [EMAIL PROTECTED] wrote: snip/ IMO the proposal can be finished off pretty quickly but i'm unsure about the best way to handle the name issue. didn't seem to be any sort of a consensus. opinions? snap/ Is there any interest in resolving the name issue as mentioned below? I think everyone's perception of the methodology used is key to a swift resolution, so it'd be nice to flesh out what the method should be. -Rahul While it would be nice, I doubt this is going to be unanimous. Unless there are other suggestions, or someone else beats me to it, I will call a vote in 24 hours. I plan to keep it simple, mark X before the name that appeals most to you. snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
On 8/9/05, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/8/05, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/8/05, robert burrell donkin [EMAIL PROTECTED] wrote: snip/ IMO the proposal can be finished off pretty quickly but i'm unsure about the best way to handle the name issue. didn't seem to be any sort of a consensus. opinions? snap/ Is there any interest in resolving the name issue as mentioned below? I think everyone's perception of the methodology used is key to a swift resolution, so it'd be nice to flesh out what the method should be. Yes. We need to pick a name ASAP so that we can get the new subproject off the ground with its own mailing lists, SVN repo, etc. The problem is that the list of candidate names, as it is now, is rather long, which could make for a somewhat messy vote. Therefore, I'd like to propose removing some of those candidate names prior to a vote: * Remove anything that has potential conflict. Let's just not go there. * Remove League, Confederation and Bloc. I honestly don't think those are serious names. * I would also recommend removing Weblets, since this suggests a uniformity of structure that simply won't be there. That would still leave us with quite a few options to choose among. -- Martin Cooper -Rahul While it would be nice, I doubt this is going to be unanimous. Unless there are other suggestions, or someone else beats me to it, I will call a vote in 24 hours. I plan to keep it simple, mark X before the name that appeals most to you. snip/ - 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: Web Components/Common project
On Tue, 9 Aug 2005, Martin Cooper wrote: On 8/9/05, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/8/05, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/8/05, robert burrell donkin [EMAIL PROTECTED] wrote: snip/ IMO the proposal can be finished off pretty quickly but i'm unsure about the best way to handle the name issue. didn't seem to be any sort of a consensus. opinions? snap/ Is there any interest in resolving the name issue as mentioned below? I think everyone's perception of the methodology used is key to a swift resolution, so it'd be nice to flesh out what the method should be. Yes. We need to pick a name ASAP so that we can get the new subproject off the ground with its own mailing lists, SVN repo, etc. The problem is that the list of candidate names, as it is now, is rather long, which could make for a somewhat messy vote. Therefore, I'd like to propose removing some of those candidate names prior to a vote: * Remove anything that has potential conflict. Let's just not go there. * Remove League, Confederation and Bloc. I honestly don't think those are serious names. * I would also recommend removing Weblets, since this suggests a uniformity of structure that simply won't be there. That would still leave us with quite a few options to choose among. +1. Let's leave Jakarta out of the names. It's assumed. So in the acronym example from Frank, it would be Apache Jakarta WP4J and not JWP4J. The only real problem is with Frank's suggestion of Web Parts and confusion over whether we'd be able to use the name; so let's get that cleared up before having a vote. Firstly, don't worry about the committership part Frank. I'm certain that if you had a decently sized lump of code accepted, and wanted to continue to maintain and enhance it and the code around, that we'll quickly nominate committership and get it passed etc. There's doubt in that people are involved etc, but I've never seen the community refuse to let someone in who is actively doing work and wanting in. I went through the same situation Frank is heading into a few years back. I had a large lump of code, some good, some crap that I wanted to donate into various Commons projects. Some was accepted, some was not. I'm pretty certain that not all of javawebparts.sf.net will end up in Jakarta name. Some of it will be code that you like Frank. This means that you'll hit a point where Jakarta name will have some of your best code, and the rest will be sitting in javawebparts and you'll have to decide what to do with it. Do you keep copies of the Jakarta name stuff (problematic)? Do you keep javawebparts as an addition to the Jakarta name stuff (see http://www.osjava.org/genjava/)? In either case, the name javawebparts will be confusing when compared to Jakarta name if name = Web Parts. So you've three options I reckon: 1) Drop the code that doesn't make it in. 2) Have a different project name for the code that doesn't make it in. 3) Vote for something else :) 1+2 both involve deprecating the javawebparts stuff. Hopefully none of that sounds too aggressive or anything; just trying to make this nice and simple so Frank can make his decision and we can include or not include Web Parts and WP4J as potential names. Let's give Frank a couple of days, then call the vote depending on his answer. (Lack of answer means they can't be in the options). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
+1. Let's leave Jakarta out of the names. It's assumed. So in the acronym example from Frank, it would be Apache Jakarta WP4J and not JWP4J. Makes sense. Firstly, don't worry about the committership part Frank. I'm certain that if you had a decently sized lump of code accepted, and wanted to continue to maintain and enhance it and the code around, that we'll quickly nominate committership and get it passed etc. There's doubt in that people are involved etc, but I've never seen the community refuse to let someone in who is actively doing work and wanting in. That is definitely one of my concerns... I absolutely want to continue to evolve what I started and build upon it, and now I have others getting involved too so I have even more of a concern than when it was just me because they are affected too. I went through the same situation Frank is heading into a few years back. I had a large lump of code, some good, some crap that I wanted to donate into various Commons projects. Some was accepted, some was not. I'm pretty certain that not all of javawebparts.sf.net will end up in Jakarta name. Some of it will be code that you like Frank. I can live with that, but of course it matters how much is deemed crap :) If 80% of it wound up being accepted, and assuming that 80% included some of the more interesting stuff (AjaxTags for instance), then I'd be OK with that. I don't know what percentage winds up making me happy or unhappy either, I just pulled 80% out of my a** :) This means that you'll hit a point where Jakarta name will have some of your best code, and the rest will be sitting in javawebparts and you'll have to decide what to do with it. Do you keep copies of the Jakarta name stuff (problematic)? Do you keep javawebparts as an addition to the Jakarta name stuff (see http://www.osjava.org/genjava/)? An addition seems reasonable... and who knows, even the stuff that doesn't get accepted initially could wind up building a community on its own and get added later, so that doesn't bother me. In either case, the name javawebparts will be confusing when compared to Jakarta name if name = Web Parts. So you've three options I reckon: Agreed. 1) Drop the code that doesn't make it in. 2) Have a different project name for the code that doesn't make it in. 3) Vote for something else :) 1+2 both involve deprecating the javawebparts stuff. Well, 1 involves that... 2 just involves a name change, which I'd be OK with if I was involved with the Apache project on an ongoing basis. Heck, I could even call it WP4J Jr. :) Hopefully none of that sounds too aggressive or anything; just trying to make this nice and simple so Frank can make his decision and we can include or not include Web Parts and WP4J as potential names. No, not aggressive at all, I very much appreciate the discussion and consideration! :) I'm in a bit of a tough position (which you have gone through, so I know you understand) because I really do want to be involved with this project, but there are things that would make the decision very easy if they could be known up-front, but of course they can't be... What code will actually be accepted and will I be invited to join as a committer chief among them. I think you understand the conundrum for me... Java Web Parts is beginning to build a community, albeit slowly, and I have full control over it (for the time being anyway)... There are definite benefits to it being subsumed by an Apache project and being involved with that instead, but I also give up a fair amount potentially and if I didn't wind up becoming a committer and having a good chunk of my work accepted, those benefits might not be worth the trade-off. I hope I'm not coming across like I'm trying to worm my way into anything either... I just don't want to lose more than I gain :) Let's give Frank a couple of days, then call the vote depending on his answer. (Lack of answer means they can't be in the options). I understand wanting to clear it up before calling a vote, but it might be better to do the vote sooner than later... at the end of the day, Web Parts might not win the vote anyway... if it doesn't, than all of this discussion is moot... I can still contribute my stuff later if I want, but the project can move forward either way. Hen Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
On Tue, 9 Aug 2005, Frank W. Zammetti wrote: +1. Let's leave Jakarta out of the names. It's assumed. So in the acronym example from Frank, it would be Apache Jakarta WP4J and not JWP4J. Makes sense. Firstly, don't worry about the committership part Frank. I'm certain that if you had a decently sized lump of code accepted, and wanted to continue to maintain and enhance it and the code around, that we'll quickly nominate committership and get it passed etc. There's doubt in that people are involved etc, but I've never seen the community refuse to let someone in who is actively doing work and wanting in. That is definitely one of my concerns... I absolutely want to continue to evolve what I started and build upon it, Yep, that's a decision we all make in contributing to the ASF communities. Are you happy to go with the commuhnity view, or want to keep things closer to your chest. and now I have others getting involved too so I have even more of a concern than when it was just me because they are affected too. Or rather, you are getting involved with others. I suspect that the process would begin by restructuring the Jakarta bits, and then pulling in the external code. I went through the same situation Frank is heading into a few years back. I had a large lump of code, some good, some crap that I wanted to donate into various Commons projects. Some was accepted, some was not. I'm pretty certain that not all of javawebparts.sf.net will end up in Jakarta name. Some of it will be code that you like Frank. I can live with that, but of course it matters how much is deemed crap :) If 80% of it wound up being accepted, and assuming that 80% included some of the more interesting stuff (AjaxTags for instance), then I'd be OK with that. I don't know what percentage winds up making me happy or unhappy either, I just pulled 80% out of my a** :) I've not looked at your code, but the numbers my arse suggests based on how much of my code got in would be 20% straight in, 20% with modifications and 60% not in. Of that 60% not in, I killed half because someone else had put bits in, especially in Collections, but that's less likely to happen here I suspect. I also killed some code because I agreed with the points of view for rejecting it. 1) Drop the code that doesn't make it in. 2) Have a different project name for the code that doesn't make it in. 3) Vote for something else :) 1+2 both involve deprecating the javawebparts stuff. Well, 1 involves that... 2 just involves a name change, which I'd be OK with if I was involved with the Apache project on an ongoing basis. Heck, I could even call it WP4J Jr. :) Probably not; it'd be a trademark issue at that point. One of those If we don't defend the trademark against WP4J Jr, we can't depend it against Evil Company's WP4J product. Hopefully none of that sounds too aggressive or anything; just trying to make this nice and simple so Frank can make his decision and we can include or not include Web Parts and WP4J as potential names. No, not aggressive at all, I very much appreciate the discussion and consideration! :) I think you understand the conundrum for me... Java Web Parts is beginning to build a community, albeit slowly, and I have full control over it (for the time being anyway)... There are definite benefits to it being subsumed (snip) I understand wanting to clear it up before calling a vote, but it might be better to do the vote sooner than later... at the end of the day, Web Parts might not win the vote anyway... if it doesn't, than all of this discussion is moot... I can still contribute my stuff later if I want, but the project can move forward either way. Let's do that. The suggested name of Web Parts does cause us to jump the gun a lot in terms of assumptions, so I'll go ahead and call a vote with Web Parts included but with a big note that it affects how we go ahead with the subproject. My gut feel is that there's a high chance you won't be happy with the way things would play out; ie) everyone could agree that AJAX components were outside scope or something. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
Yep, that's a decision we all make in contributing to the ASF communities. Are you happy to go with the commuhnity view, or want to keep things closer to your chest. I think too that it's maybe a little easier to go with the community view when its a project you didn't yourself give birth to :) Or rather, you are getting involved with others. I suspect that the process would begin by restructuring the Jakarta bits, and then pulling in the external code. I think your point is a good one... there is enough already within the foundation to get this project off the ground, and nothing says I can't come back a few months down the road and offer up my stuff at that point. Might even be easier at that point to see if the fit is truly right. I've not looked at your code, but the numbers my arse suggests based on how much of my code got in would be 20% straight in, 20% with modifications and 60% not in. Of that 60% not in, I killed half because someone else had put bits in, especially in Collections, but that's less likely to happen here I suspect. Yeah, those are the kinds of percentages I can't imagine being happy with... the two 20's are fine, but that 60 stands out in a negative way for me. Of course I know you nor anyone else can say right now what it would really wind up being, but your experience is a good general guide for me. Probably not; it'd be a trademark issue at that point. One of those If we don't defend the trademark against WP4J Jr, we can't depend it against Evil Company's WP4J product. I kind of thought so as I was typing that :) Let's do that. The suggested name of Web Parts does cause us to jump the gun a lot in terms of assumptions, so I'll go ahead and call a vote with Web Parts included but with a big note that it affects how we go ahead with the subproject. I think that's the best plan. If everyone winds up really strongly being in favor of Web Parts then there can be some discussion on how to make that work. But no sense going down that road if the consensus is for something else anyway. My gut feel is that there's a high chance you won't be happy with the way things would play out; ie) everyone could agree that AJAX components were outside scope or something. Yes, I suspect your right. There are certain decisions I could live with without much trouble at all, but there are some that I'm not sure I could go along with. If I get involved later and I don't like the decisions, I can just bail and no one is hurt, but if I agree to certain things now and then find I don't like how its going I'm locked-in to an extent and it becomes painful, so better to avoid that up-front. Hen Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebXxxx Naming Was: Web Components/Common project
Martin Cooper wrote: Some other names were added to the wiki page: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents I forgot to add some names to that page: Webbies(has the same idea of weblets, but causing less confusion) Jakartlets (someone suggested we use a name without Web - it would be cool to be derived from Jakarta then, as Jakarta is tied to server side Java) That would probably add: - web libs - web tools to your list above. (I'm not sure how appropriate 'web libs' would be though, since I'm not sure I'd refer to, say, a compression filter as a 'library'.) Web Tools can be a problem too, as it conflicts with the Eclipse Web Tools Platform. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WebXxxx Naming Was: Web Components/Common project
Also Web parts appears to be a Microsoft term I have a shirt around here someone regarding Parts for Java, which was a product from ParcPlace. Apache WebParts would be OK with me, but I care more about the content of the project than the name. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Components/Common project
Has there been any discussion with the Incubator PMC whether this contribution needs to come through them? Or does this somehow not fit into their purview? All external codebases brought into the ASF need to come through the Incubator. Sometimes, as Henri noted, that only requires the IP clearance to be filed. We put some guidelines into that document for when it might be appropriate. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WebXxxx Naming Was: Web Components/Common project
Hey, How about Apache Spider Web? ;) Sorts of like it traps things, double-entendre on the meaning of web, etc.. Just thought I'd throw it out there ;) Yoav --- Noel J. Bergman [EMAIL PROTECTED] wrote: Also Web parts appears to be a Microsoft term I have a shirt around here someone regarding Parts for Java, which was a product from ParcPlace. Apache WebParts would be OK with me, but I care more about the content of the project than the name. --- Noel - 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: WebXxxx Naming Was: Web Components/Common project
How about Apache Spider Web? No, but you just gave me an idea: Apache Silk Silk is what webs are made of. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebXxxx Naming Was: Web Components/Common project
For what it's worth, I actually like Silk a great deal... in fact, I'd go ahead and give it my non-binding +1... I was the one that put the idea on the Wiki of a more codeword-ish name, and I think Silk is perfect. Frank Noel J. Bergman wrote: How about Apache Spider Web? No, but you just gave me an idea: Apache Silk Silk is what webs are made of. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebXxxx Naming Was: Web Components/Common project
On 8/9/05, Henri Yandell [EMAIL PROTECTED] wrote: snip/ All would be describable (assuming no clashes) as: Apache Jakarta Web Components Apache Web Components There's the option of doing W*4J or something, but we can discuss that later I think as it's just an altered presentation of the chosen name. snap/ Agreed, plus I'm not too keen to see a Java tie-in with the name, given the current scope of the sub-project. We have other programming models even in the starter set. On 8/9/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: For what it's worth, I actually like Silk a great deal... in fact, I'd go ahead and give it my non-binding +1... snip/ If there is a connection to be drawn, I think many probably won't ;-) I'd refrain from voting until a formal thread appears on the subject. I know its hard ;-) but voting now will make it tougher to tally opinions from multiple threads. Hen has taken the lead to call a vote [ http://marc.theaimsgroup.com/?l=jakarta-generalm=112361926416536w=2 ], shouldn't be too long a wait. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebXxxx Naming Was: Web Components/Common project
Rahul Akolkar wrote: If there is a connection to be drawn, I think many probably won't ;-) Always the risk with names that don't spell out precisely what name. You can easily be *too* clever, this could be one of those cases. I'd refrain from voting until a formal thread appears on the subject. I know its hard ;-) but voting now will make it tougher to tally opinions from multiple threads. Hen has taken the lead to call a vote [ http://marc.theaimsgroup.com/?l=jakarta-generalm=112361926416536w=2 ], shouldn't be too long a wait. Yeah, I got a bit excited because I really do like the name :) I'll throw my vote in the official thread when it starts... knowing me I'll probably change my mind 10 times by then anyway :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
On Mon, August 8, 2005 12:42 pm, robert burrell donkin said: On Mon, 2005-08-08 at 01:54 -0300, Felipe Leme wrote: Hello all, What's the status on the new project proposal? Has the discussion moved to another list or has it just staled? in a holding pattern: IMO the proposal can be finished off pretty quickly but i'm unsure about the best way to handle the name issue. didn't seem to be any sort of a consensus. opinions? Progress on this project seemed to kind of stop, based on posts about it, about two weeks ago. As Robert indicates, there was never any consensus on the name. There were a bunch of options and comments listed on the Wiki page: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents ...but the discussion seemed to kind of fade away. My personal favorite off that list was Jakarta Web Parts For Java (JWP4J). It has the virtue of sounding like some other Apache/OSS projects (Log4J, SOAP4J, ws-wsrp4j, etc). It has the problem however of being almost identical to my own Java Web Parts project. I still have an interest in donating my work to the foundation, and that would start with the name if so desired, but I still have concerns about such a donation that might make choosing a different name more prudent. Anyway, the Jakarta Taglib Project has voted how it would like to take part on this new project, and the result was: 1.The Jakarta Taglibs Project would like to be merged into the project 2.The Jakarta Standard Taglib should then be a project of its own 3.The remaining taglibs would be gradually migrated to the new project, the most actives first 4.It's not decided yet if the migrated taglibs would have a newer release prior to the migration I'm not sure there was ever a consensus on what the overall structure of the project would be either (someone can correct me if I'm wrong on that point)... It seems like there might be a risk of sub-projects within sub-projects within sub-projects, which I'm not sure would be the best organizational stucture... if you had Jakarta Taglibs as a sub-component of the JWP4J project (assume for the sake of argument that name sticks), and then have Jakarta Standard Taglib as a sub-project of Jakarta Taglibs, is that the best structure to have? How deep of a hierarchy is OK and how deep is too deep? My own JWP project has a taglib package that has individual taglibs within it (AjaxTags, BasicString, etc), so I have the same thing going on... I personally wouldn't go beyond 3-levels like this, and I just wanted to raise the issue now before anything actually moves forward in case others have thoughts on this. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
On Mon, 2005-08-08 at 13:14 -0400, Frank W. Zammetti wrote: On Mon, August 8, 2005 12:42 pm, robert burrell donkin said: On Mon, 2005-08-08 at 01:54 -0300, Felipe Leme wrote: snip Anyway, the Jakarta Taglib Project has voted how it would like to take part on this new project, and the result was: 1.The Jakarta Taglibs Project would like to be merged into the project 2.The Jakarta Standard Taglib should then be a project of its own 3.The remaining taglibs would be gradually migrated to the new project, the most actives first 4.It's not decided yet if the migrated taglibs would have a newer release prior to the migration I'm not sure there was ever a consensus on what the overall structure of the project would be either (someone can correct me if I'm wrong on that point)... It seems like there might be a risk of sub-projects within sub-projects within sub-projects, which I'm not sure would be the best organizational stucture... if you had Jakarta Taglibs as a sub-component of the JWP4J project (assume for the sake of argument that name sticks), and then have Jakarta Standard Taglib as a sub-project of Jakarta Taglibs, is that the best structure to have? How deep of a hierarchy is OK and how deep is too deep? any deep is too deep :) AIUI everything will be flat: collective management and only social divisions. standard taglibs will become a jakarta sub-project. BTW is there any real reason not to start the promotion process for standard taglibs ASAP? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
On Mon, 8 Aug 2005, robert burrell donkin wrote: AIUI everything will be flat: collective management and only social divisions. standard taglibs will become a jakarta sub-project. +1, I agree. BTW is there any real reason not to start the promotion process for standard taglibs ASAP? None that I can see. There's a big shopping list of Jakarta rearrangements that have been desired over the last couple of years that I want to email about soon, as soon as I get back into the swing of things (currently ill and convalescing at home). Nothing too scary; HttpClient, Tomcat, Slide, JCS all need moving; Taglibs now too. Probably others. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
Frank W. Zammetti wrote: point)... It seems like there might be a risk of sub-projects within sub-projects within sub-projects, which I'm not sure would be the best organizational stucture... if you had Jakarta Taglibs as a sub-component of the JWP4J project (assume for the sake of argument that name sticks), and then have Jakarta Standard Taglib as a sub-project of Jakarta Taglibs, is that the best structure to have? How deep of a hierarchy is OK and how deep is too deep? Right now, the Standard is already a sub-project of the Jakarta Taglibs. So, what we meant (sorry for the confusion) is that the Standard wouldn't be migrated to this new project; instead, it would be a Jakarta sub-project, sibling of the new project. Regarding the other taglibs, I agree, it might make more sense for all of them to be direct sub-projects of the new project, instead of having an intermediate taglibs sub-project. But that's something we can decide later one - as we (the Jakarta Taglibs project) decided that we should create new taglibs from scratch (using the legacy code), the structure wouldn't matter at this point. My own JWP project has a taglib package that has individual taglibs within it (AjaxTags, BasicString, etc), so I have the same thing going on... I personally wouldn't go beyond 3-levels like this, and I just wanted to raise the issue now before anything actually moves forward in case others have thoughts on this. I agree - sometimes it makes more sense to aggregate components by functionality than classes. For instance, we could have a Security sub-project which would produce taglibs (like a PageGuardTag), filters and even Struts actions. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Components/Common project
On 8/8/05, robert burrell donkin [EMAIL PROTECTED] wrote: snip/ IMO the proposal can be finished off pretty quickly but i'm unsure about the best way to handle the name issue. didn't seem to be any sort of a consensus. opinions? snap/ An informal thread was here [ http://marc.theaimsgroup.com/?l=jakarta-generalm=111972374202676w=2 ], where I believe the majority opted for Web Components. While it would be nice, I doubt this is going to be unanimous. Unless there are other suggestions, or someone else beats me to it, I will call a vote in 24 hours. I plan to keep it simple, mark X before the name that appeals most to you. On 8/8/05, Henri Yandell [EMAIL PROTECTED] wrote: On Mon, 8 Aug 2005, robert burrell donkin wrote: AIUI everything will be flat: collective management and only social divisions. standard taglibs will become a jakarta sub-project. +1, I agree. snip/ +1 On 8/8/05, Felipe Leme [EMAIL PROTECTED] wrote: snip/ Regarding the other taglibs, I agree, it might make more sense for all of them to be direct sub-projects of the new project, instead of having an intermediate taglibs sub-project. But that's something we can decide later one - as we (the Jakarta Taglibs project) decided that we should create new taglibs from scratch (using the legacy code), the structure wouldn't matter at this point. snap/ I will call a vote on taglibs-dev today. While it seems we are agreeing on the flat hierarchy, this is, IMO, important enough to close for the Taglibs project before moving forward. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Web Components/Common project
Hello all, What's the status on the new project proposal? Has the discussion moved to another list or has it just staled? Anyway, the Jakarta Taglib Project has voted how it would like to take part on this new project, and the result was: 1.The Jakarta Taglibs Project would like to be merged into the project 2.The Jakarta Standard Taglib should then be a project of its own 3.The remaining taglibs would be gradually migrated to the new project, the most actives first 4.It's not decided yet if the migrated taglibs would have a newer release prior to the migration -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
