Re: [Ant nudge STATUS] Better than we thought...
What would this mean for the Jakarta PMC as many of them are part of Ant? Do these PMC'ers do double duty? -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote on 26/10/2002 10:04:43 PM: > > > > > >> The idea: > >> > >> ant.apache.org would become a valid url > > > > > > > > Good move - presumably could be indendent of the rest of the points ? > > > This has been asked but not answered. I think the answer is probably no > as those are reserved for top level projects. (I prefer the answer to > be yes...but I don't think it is) > > > > >> > >> ant would have its own PMC composed of whomever the committers decide > >> (I guess) > >> ant would report directly to the board > > > > > > > > Pros and cons - appears to me that the main issue is general > > discontinuity of the value perception - committers look at a PMC and > > see it as an overhead and something to push into the furthests reaches > > of their minds - board members see this is the accountability > > mechanisms - I'm still thinging about this one - I know there is > > something wrong with the model but I don't have througts together yet. > > Understandable. Another benefit: greater self determination. Although > its in a less tangible way as Jakarta committers have great deal of > this. But you need to think not only about ant but in a global kind of > manner (the ASF as a whole) > > > > >> > >> unresolved (but I think open...or maybe I'm wrong) > >> relationship between ant and Jakarta (I'm assuming it would answer to > >> Jakarta only in name/branding) > > > > > > > > Good move - leverage Jakarta (brand etc.). > > agreed. > > > > >> > >> jakarta.apache.org/ant still valid url? > > > > > > > > Should be. > > agreed > > >> > >> greater access to the members/board > > > > > > > > Questionable given the PMC concept verus community disconnect I'm seeing. > > well principally you should be interested in this communication. > Another PRO... > more opportunity for ant committers to become recognized and achieve > membership. > > > > >> > >> Disadvantage > >> reporting directly to the board (from a laziness perspective...I > >> think you have to actually "report" though I could be wrong) > >> you'd be the first to make the transition > > > > > > > > My impression is that this something comming (which I happen to think > > is long overdue). > > which this would help achieve.. > > > > >> > >> Ant is the project I personally would like to see be top level most. > >> Suggestion: > >> Someone who understands the proposed process of this happening draft > >> a formal proposal to be voted on.. > > > > > > > > I'm not on the ant list but I would be definaterly keen to see such a > > proposal cross posted to community@ > > yes. or just moved there. > > > > > Cheers, Steve. > > > >> > >> -Andy > >> > >> > >> > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ForwardSourceID:NT00086AEA
Re: [PROPOSAL] Tapestry joins Jakarta
"Andrew C. Oliver" <[EMAIL PROTECTED]> wrote on 27/10/2002 12:20:26 AM: > Mr Ship, > > I totally disagree with Pier's statement (and you'll find many here will > feel the same as I on this). > The opinion of Tapestry joining is very good. > Realize Apache is more like a confederation than anything. So different > people feel > differently. We're still ironing out a new process as Pier said, > however most folks I've > spoken to have felt that the Apache voting rules must be adopted as a > first step not > later. Dion and I have both committed to helping you with this > transition (though I don't > think he ever stated so publically...Dion?). And I'll be happy to This counts as publicly volunteering :) > subscribe to the tapestry > list if you desire and help you build the structure. > > The steps as I see them: > > 1. Adopt apache voting rules > 2. Vote to join and relicense (in one swoop) > 3. Submit a formal proposal 3a. PMC confers > 4. You're in [snip] > Me & Dion > 1. Find a sponsoring member > 2. Assist you in reorganizing > 3. Assist you in your propoasal > 4. Make our case > 5. Assist you in getting your sources/structures here. 6. Assist in liaising with incubator 7. Assist in 'The Apache Way' details. > Thats as clearly as i can lay it out. Hopefully others will chime in > constructively and clear up anything I got wrong or is fuzzy ;-) -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers
Re: Dear incubator
Since the discussion was initiated here on [EMAIL PROTECTED], I'd prefer we kept it here until there is a way forward via incubator, rather than move it off to yet another list. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote on 27/10/2002 11:30:10 AM: > Dear incubator, > > I feel like I'm speaking to the wizard of Oz posting to a list I can't > see ;-) > > Tapestry (tapestry.sourceforge.net) is a web app framework similar in > use and scope to Velocity/turbine and JSP/Struts, but certainly very > different in approach. > > dIon Gillard and I have both agreed to help with the transition. > However we both feel the first step is for the tapestry community > (to whom's mail list I am now subscribed) to adopt apache voting rules ( > http://httpd.apache.org/dev/guidelines.html) before joining. once > they've demonstrated this transition and identified 3 core > committers, we should identify whether they go through some new > process or identify the new incubator process. Whatever the case > they should not be unduely lubricated through the guidelines, nor > unduely inhibited by the transition. I think we're all up to this > challenge and this could (hopefully) set a very nice precident. > > To this end and to the ends of providing more interaction between > the various elements here at apache, I would like to suggest Ken > Coar whom I have approached as the "member sponsor" and "advisor" of > the project and has stated his interest. His experience and > abillities will be an asset to this transition as well as provide > greater insight to the rest of the Apache community on the goings on > of a Java/Jakarta project. > > I'd like to start a conversation on what the process/guidelines for > accepting Tapestry should be at the same time and what its path for > acceptance as either a Jakarta project or top level apache project should be. > > I would suggest that this discussion happen on the community at > apache list and move to the general at jakarta list if deemed > appropriate as dion and I cannot participate in the [EMAIL PROTECTED] > list nor can the project principals. > > Thanks for your support, > > Andrew C. Oliver > committer POI, Lucene > contributer Cocoon, JAMES > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > ForwardSourceID:NT0008711E
Ant PMC Issue (was: RE: [proposal] daedalus jar repository (was: primary distribution location))
Noel Bergman writes: > I like the idea of a central repository. It would simplify the issue by > centralizing maintenance of jars and licenses. I just want to know how it > is going to operate. A joint operation between Ant and Maven? > Infrastructure? > > [I won't even get into the question of why those two can't be related > projects under a single PMC] Read the Ant missionit specifically states the Ant build system as it's scope. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution
Now I've gone from digest to individual emails, keeping up might be easier... [EMAIL PROTECTED] wrote on 27/02/2003 03:08:17 AM: > -- > From: Leo Simons <[EMAIL PROTECTED]> > yep. So don't drop the binary until you have a) policy, b) desire and c) > an ok to make apache into > a redistribution point of third-party software. Just b) doesn't cut it. The issue for the ASF is that we already *are* distributing third-party software via cvs and viewcvs. jdom, w3c stuff like dom2, jaxp, JLex, tidy etc > Licensing policy is quite tricky and lots of things need to be done > before the ASF should even consider Now there's an understatement. > For example, the docs started at > http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing should be made > into an authoritive source on > www.apache.org that unambiguously answers "yes" or "no" with regard to > > "can we link to software under license X?", And what does 'linking' mean for languages used by the ASF, e.g. Java, PHP, Perl, scripting languages like Javascript? > "can we redistribute software under license X in source form and/or > binary form?", > "how do we provide these licenses when we redistribute or link to > software under license X?", > "what other steps doe we take when we redistribute or link to software > under license X?" e.g. credits, details in documentation, etc. > Not sure if your project can distribute JUnit? Then don't, even if that > makes life terribly inconvenient. That seems to be the opposite of most projects current stance. > sourcecode under its own license. Yes, binary, but it is the best first > step and it solves a real need. Just to play devils advocate, what is that need, Given that there current is a repository distributing ASF binaries with their license. This is not a facetious comment, but a desire to explore what the need is for an ASF-blessed repository. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [off-topic-just for fun] - Maps and zoom-in
From: Rodent of Unusual Size <[EMAIL PROTECTED]> > > Dirk-Willem van Gulik wrote: > > The map on: > > > >http://cvs.apache.org/~dirkx/sgala.html > > > > has had a wee enhancement; if you zoom in far enough; the boring digital > > terrain map of etoto5 gets replaced by mapblast. Depending on which part > > of the world you're in, the projection is about right :-) That map shows only one person in Australia...how are the people determined? -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository (was:primary
From: Conor MacNeill <[EMAIL PROTECTED]> > [EMAIL PROTECTED] wrote: > > > > Read the Ant missionit specifically states the Ant build system as > > it's scope. > > Hi Dion, > > Your subject got my attention :-) Is there an Ant PMC issue here? We're Nope, no ant pmc issue from me. > certainly open to working with other projects within Apache and beyond. Is > Ant's scope statement preventing the Maven developers from working on an > Apache jar repository with Ant? Am I missing something? Nope, you're not missing something. Noel just asked in passing why Maven and Ant aren't under the same PMC. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [off-topic-just for fun] - Maps and zoom-in
From: Rodent of Unusual Size <[EMAIL PROTECTED]> > > Dirk-Willem van Gulik wrote: > > The map on: > > > >http://cvs.apache.org/~dirkx/sgala.html > > > > has had a wee enhancement; if you zoom in far enough; the boring digital > > terrain map of etoto5 gets replaced by mapblast. Depending on which part > > of the world you're in, the projection is about right :-) That map shows only one person in Australia...how are the people determined? -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Costin Manolache <[EMAIL PROTECTED]> writes: > Few simple questions: > > Should we use 2 different dirs for src and binary distribution ? Or > maybe 3 dirs ( src, bin, doc ) ? Why duplicate the existing distributions? They're available, mirrored and well understood. > Are "milestone" builds acceptable ? Should we get some weekly gump > builds from HEAD into the repository ? FWIW, Milestone and even 'snapshot' builds have proven necessary for projects using Maven. > What policy should we use for removing older versions ( or we just keep > everything ) ? It needs to be driven by usage. If someone is still using ant 1.1, fine keep it available. There's nothing worse than a build failing because the repository has changed. > Since the versioned jar/unversioned dir format is used - I think various > PMCs should try to get the various projects to use the same format > internally. That's a project decision. I don't see anyone should be forcing the projects to change their build process to match the repository. That's why the ibiblio repository has manual admin as an option (at the moment it's the only one). > I would prefer the reverse ( versioned dirs / unversioned jars ) - but I > can live with the reverse if it does have a "majority" support. So asking the projects which format they would like for a repository they don't currently use? Sounds like asking for uninformed opinions. I'd be happier to come ask them to participate in a discussion here. > Could we put at least this option to a vote, just to have a record that > it isn't just a random decision but what the committers really want ? Why not ask the users of the repository. The committers wont be the main users. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution
Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote on 27/02/2003 10:18:26 AM: > > On Thu, 27 Feb 2003 [EMAIL PROTECTED] wrote: > > > > "can we link to software under license X?", > > > And what does 'linking' mean for languages used by the ASF, e.g. Java, > > PHP, Perl, scripting languages like Javascript? > > Actually - in a lot of cases - that is not 'our' problem. Best we can do > is ask the owner/author of the IP/License for which resolving such is > important for his-or-her take on that; and then make sure the answer is > filed properly in the ASF books. Yep. If the ASF wants to use third-party code, it must verify the license usage is legal. Given the discussions lately re: LGPL, this sort of issue is extremely important. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: can Apache distribute third party libraries?
Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote on 27/02/2003 10:08:20 AM: > > On Thu, 27 Feb 2003, Leo Simons wrote: > > > there exists some confusion within the apache community about the > > redistribution of library sources and binaries by apache. The question > > I took an action on the last board meeting to start making an initial list > of those licenses and a procedure to keep that list up to date/extend it. > > Expect some action on that in the next days/week. Cool. I've done a lot of reading of licenses lately, and would appreciate any info you've got. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and community
-Sam Ruby <[EMAIL PROTECTED]> wrote: - > Now that the initial board discussion on the Maven resolution has been > held, a few thoughts... > 1) It was made quite clear to me by a number of directors that it is > expected that I have an interest and opinion on topics that come before > the board. I received repeated requests not to abstain on this vote, > but I held my ground. I believe that over the years I have amply > demonstrated a preference to "let a thousand flowers bloom", but in this > case my integrity was called into question in a way that I very much did > not appreciate. > > 2) The question that is foremost in my mind on the Maven proposal is as > follows: what does the ASF as a whole gain by yielding a specific scope > and responsibility to the set of five developers mentioned in the > proposed Maven resolution? If these people want to work together, they There are more than five members of the Maven team. Please see http://jakarta.apache.org/turbine/maven/team-list.html for a full list of committers and contributors. There are around 30 contributors to the effort overall. The ASF gains nothing new from these people, as they are mostly existing committers. The code is (c) ASF, so they gain no code from the proposal. The ASF would gain more assurance that the code being created is overseen by people directly responsible and involved in its creation, rather than the responsibility falling to the Jakarta PMC, who I'm sure haven't got the time and energy to cover it. They would also gain a focussed community of software developers with a passionate group of users. > can certainly do so in a number of venues, so what do they or the ASF > benefit from doing so here? There are quite a few projects here (ASF) using Maven as a build tool. Maven heavily relies on other ASF code (Ant, Jakarta's Jelly, Jexl, Commons etc). There are obvious benefits to those projects in Maven's continued working with them, as we have done in the past. > 3) A challenge to the Maven developers: what would it take to convert > Xalan to use Maven? The reason for this challenge is simple: to > demonstrate the the antipathy towards other ASF efforts is damaging not > only to the ASF, but to Maven itself. Last things first: 'antipathy' == 'A strong feeling of aversion or repugnance'. I'm not very happy that you feel the 'Maven developers', all 30 or so people involved in a significant way, feel this way about 'other ASF efforts'. Given the involvement of most of the proposed PMC members in other ASF efforts I'm having trouble seeing how it is justified. I'm trying not to take it personally. As for the challenge, I, personally, don't think that Maven needs to 'convert' other projects to use it. Other projects should use Maven if they feel it fits their needs. I personally don't feel that other projects (Forrest, Gump, Centipede, Ant, Make, Nant etc) should try to convert people. I'd rather people experimented and made up their own mind. I'd hate for someone to force a build tool on me. That said, Xalan could quite easily start using Maven as a build or site generation tool, but, Maven doesn't currently cover as much of Xalan's build process as a pure java project, and hence there would be work to determine how this would be best achieved. I see no problem or issue there. If the Xalan team would like help I'm offering. > P.S., and this is primarily to Jason: please don't try to twist any of > this into coersion. #2 and #3 above are simply a question and a > challenge. They are not a prerequisite for board approval, or even > necessarily for my one vote out of nine directors on the subject when it > comes up again. It is my belief that a number of efforts made by the > Maven community can, will, and do benefit the ASF. I simply want to > maximize the potential for this to occur. That is my interest. Just so I understand that last bit, you'd like to 'maximize the potential' for the 'efforts made by the Maven community' to 'benefit the ASF'. Right? -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and community
Sam Ruby <[EMAIL PROTECTED]> wrote on 27/02/2003 11:39:47 PM: > [EMAIL PROTECTED] wrote: > > > > The ASF gains nothing new from these people, as they are mostly > > existing committers. The code is (c) ASF, so they gain no code from > > the proposal. The ASF would gain more assurance that the code being > > created is overseen by people directly responsible and involved in > > its creation, rather than the responsibility falling to the Jakarta > > PMC, who I'm sure haven't got the time and energy to cover it. They > > would also gain a focussed community of software developers with a > > passionate group of users. > > The proposed resolution is not the only organization which would achieve > that goal. It might happen to be the best one, but it certainly isn't > the only one. I'm not suggesting it is. I'd be interested to hear others. > I do believe that a number of potentially fruitful discussions about > potential synergies have been shut down during this process. This > troubles me. I haven't seen that from my side, so I can't comment. > I do not believe that all Maven developers feel the same way. Need I > cite a few IRC logs to show that that a number of them, particularly > some of those listed as the proposed PMC, do? Or at the very least, > look the other way when such sentiments are expressed? I'm sure you could find lots of things on IRC logs that don't quote very well. That's the nature of IRC; casual conversation. Reading an IRC log is like eavesdropping. > > Given the involvement of most of the proposed PMC members in other > > ASF efforts I'm having trouble seeing how it is justified. I'm trying > > not to take it personally. > > As I have tried not to take the numerous and repeated comments that Gump > sucks or is an embarrasment to the ASF personally. There's a difference here. Gump is a piece of software. 'Maven developers' are people, myself included. And I'll ignore those blog entries about Jelly sucking too :) > > As for the challenge, I, personally, don't think that Maven needs to > > 'convert' other projects to use it. Other projects should use Maven > > if they feel it fits their needs. I personally don't feel that other > > projects (Forrest, Gump, Centipede, Ant, Make, Nant etc) should try > > to convert people. I'd rather people experimented and made up their > > own mind. I'd hate for someone to force a build tool on me. > > Here we strongly agree. > > That's why I am concerned when I see statements to the effect that > threre is no need for certain other efforts (for example, an ASF jar > repository). I'm happy for the ASF to have a jar repository. I personally haven't seen a need clearly expressed about why we need an ASF only repository. Desire, sure. Need? That hasn't been clearly articulated, and we seem to be discussing low level details without working out/discussing the reasons first. I've had several discussions with Noel Bergman offline about the idea, and posted recently to this list about it. Other developers can get as involved as they would like, but I don't think I've been forcing things on people. > > Just so I understand that last bit, you'd like to 'maximize the > > potential' for the 'efforts made by the Maven community' to 'benefit > > the ASF'. Right? > > I certainly would like to see that. To be clear, I wouldn't pursue that > to the expense of the self determination of people who have contributed > to Maven. Nor to the expense of the self determination of those that > wish to pursue "competing" efforts. A lot of things could come out of projects, such as Maven, that would be of wider benefit to the ASF. When this happens, I hope people step up and offer to get involved and suggest ways of working together. As an example, take the jar repository. Leo has cross-posted to turbine-maven-dev to solicit feedback, and I've had emails from Noel Bergman as well. Whether anything comes of it, who knows, but from my angle all the right noises are being made. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
Costin Manolache <[EMAIL PROTECTED]> wrote on 27/02/2003 08:28:05 AM: > On Wed, 26 Feb 2003, Noel J. Bergman wrote: > > > differing views on how to make use of the repository. Costin and I seem to > > be of the option that a significant portion of the value of the repository > > comes from sharing and centralizing the managment of ASF-acceptable third > > party jars. > > Not entirely true, but close. > > I think third party jars that are found compatible with ASF license - i.e. > freely redistributable - are very valuable as they will allow projects > to better manage their dependencies. You know that ASF jars aren't 'freely' distributable, right? The license specifies some conditions on binary distribution. > I don't believe in a single repository or a single policy - the download > tools must be smart and be able to deal with different kinds of > repositories ( apache, sourceforge, maven, etc ). Heck - if the tool can > display the license and ask for an "I agree" and if this satisfies the > requirements of some licenses - it should be supported. That's what > makes a good tool - flexibility and ability to accept multiple inputs. Sure, that's a tool that can handle lots of repositories. But what about the apache repo? > Well, Maven doesn't seem to be that concerned with duplication, and values > the competition :-) To paraphrase Jason - what's wrong with multiple > competing repositories ? A smart tool should be able to support multiple > policies - or choose to restrict the users to a particular set. Sure, feel free. > To take one example - the jar naming - I understand very well that Maven > people decided on this thing. And I understand that a lot of people > consider this a good decision - and a lot of other people don't. If this > becomes an apache-wide policy, I strongly disagree that Maven can decide > for apache policies. I don't think we've tried to. > In other words - as long as maven decisions affect only maven - I don't > care. But if it affects other projects, and the repository certainly does > - then the PMCs of those projects or the apache community are the ones > that decide. Sure, but please take into account the work we've already done. > +1 on the oversight committee for non-apache jars. Believe me, the oversight bit is the hardest part. > A strong -1 on oversight for apache jars. We already have PMCs for each > project, and those should oversee the distribution of their own files. Even by other projects? -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
Greg Stein <[EMAIL PROTECTED]> wrote on 27/02/2003 11:33:28 AM: > On Thu, Feb 27, 2003 at 10:12:35AM +1100, [EMAIL PROTECTED] wrote: > >... > > > sourcecode under its own license. Yes, binary, but it is the best first > > > step and it solves a real need. > > > > Just to play devils advocate, what is that need, Given that there current > > is a repository distributing ASF binaries with their license. > > > > This is not a facetious comment, but a desire to explore what the need is > > for an ASF-blessed repository. > > The ASF doesn't "need" to have a repository. But it cannot operate or > condone a repository that has or allows license violations. Sure. I don't think anyone was suggesting that such a repository be created. > The ASF is primarily concerned with the original, authoritative distribution > of its code. For proper authenticity, security, mirroring, etc, that > distribution has a set of requirements and policy which has been defined by > the infrastructure team. The current 'distributions' are mainly in zipped source or binary form, right? Is there a precedent for non-zipped binaries? > Beyond the original distribution, then it's all gravy. What facilities do we > want to provide our users and downstream developers? How can we simplify > their lives? Ted points out that it is reasonable to state that the ASF is > creating problems (classpath and whatnot), so maybe you could even say we > "must" create a repos simply as a way to help recover from the mess that we > have made. *shrug* > > > It does seem like people are narrowing in on some proposals, designs, etc. I > might suggest it is about time to Wiki-ize the current thoughts so that you > have something concrete to reference in further mailing list discussion. And > to iterate on or to provide some alternatives. Sounds like a plan. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Ben Hyde <[EMAIL PROTECTED]> wrote on 28/02/2003 01:46:43 AM: > [EMAIL PROTECTED] wrote: > > You know that ASF jars aren't 'freely' distributable, right? The > > license > > specifies some conditions on binary distribution. > [snip good stuff] > Are you arguing that the ASF should stop striving to keep licenses > compatible? No. Where did you get that idea? -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scrambling jar files?
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote on 28/02/2003 11:06:51 AM: > I just ran into this and found that might be worth injecting into the > jar repositories discussions. > > http://nbbuild.netbeans.org/scrambler.html That one is listed up @ http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Scrambling jar files?
FWIW, Maven has been following up with Sun on a click-through approach to allowing BCL code to be distributed. Geir is the man on the ground for us. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au "Noel J. Bergman" <[EMAIL PROTECTED]> wrote on 28/02/2003 12:06:04 PM: > > I just ran into this and found that might be worth injecting into the > > jar repositories discussions. > > http://nbbuild.netbeans.org/scrambler.html > > Yes. That is what I was referring to when I mentioned click-through > licenses on netbeans.org, and Costin seems to be aware of it as well. > >--- 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: Maven and community
-"Noel J. Bergman" <[EMAIL PROTECTED]> wrote: - > Dion, > > > The reason for this challenge is simple: to > > > demonstrate the the antipathy towards other > > > ASF efforts is damaging not only to the ASF, > > > but to Maven itself. > > 'antipathy' == 'A strong feeling of aversion or repugnance'. > However you want to label it, Jason's harshly phrased statements yesterday > regarding collaboration with other ASF projects (and people) expressed an > attitude that some people, including myself, obviously didn't view > positively. In fairness, my reaction is influenced as much by my views on > software development as by his words. Nor did I miss his somewhat contrite > reply to Ken Coar. I would hope that his comments are not representative of > Maven. I would prefer to believe that his comments are not even > representative of himself. You don't like Jason's attitude, fine, take that up with Jason. Personality conflicts are a natural part of life. Representing Jason as all Maven developers is a leap beyond that I can't fathom. [snip] > A development tool exists for the purpose of servicing other projects. I > viewed Sam's comments as expressing the concern that if personalities were > to get in the way of collaborating to produce something that better serves > other projects, then that would be damaging. With Ant, the ASF set the So if/when it happens I expect people to get involved. Preempting it seems a little premature. > standard (for better or worse) for Java build tools. With Maven, that is > extended, enhanced, embedded to handle web-based project management. You > said that there is a great deal of synergy between Ant and Maven. It is > natural to feel that these are related projects, and that collaboration > would not only be beneficial, but highly desired by all parties. The Collaboration does happen, now. It's not a future waiting to happen. Is there something that's not happening that specifically needs to be looked at? > antagonistic response, with neither provocation nor justification, was > disconcerting to say the least. It is unsurprising then to have concerns > regarding a productive relationship with an entity exhibiting that attitude. Jason is an 'entity'? I figured he was a person with all the usual good and bad points, much like you and I. It seems you are confusing your view of Jason, which you admit is limited to a short exchange here, with the team of people developing Maven. I've worked with Jason for quite a while now and he speaks his mind, and when he's wrong, he's the first to admit it. If you're interested in the Maven community and what it is, please join us on turbine-maven-user@jakarta.apache.org and turbine-maven-dev@jakarta.apache.org -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
As an aside, one of the issues we had when coming up with Maven's repository format, is that often artifacts (jars, wars, ears etc), willget left on the filesystem outside of a repository. Think rpms for example. Having a file encode --.type has been very useful for us. Yes, it's often different from what the project creates and distributes, but I (and others) have been bitten bycommons-logging.jar, struts.jar, junit.jar so many times, that seeing log4j-1.2.5.jar is a godsend.--dIon Gillard, Multitask ConsultingBlog: http://www.freeroller.net/page/dion/WeblogWork: http://www.multitask.com.au-Nick Chalko <[EMAIL PROTECTED]> wrote: -To: community@apache.orgFrom: Nick Chalko <[EMAIL PROTECTED]>Date: 03/01/2003 06:54AMSubject: Re: [proposal] daedalus jar repositoryNoel J. Bergman wrote:>Nick,>>As long as you want to start with first principles ...>> >>>project/[subproject]/version/(jar|zip|gz|docs|liscenses)>>is very good.>>>>>>How much should be encoded in a URI, and how much in data associated with>the URI? You seem to be trying to encode all of the data into the URI>naming space. Why not have a single URI for the target, and then trigger>behavior based upon the content? That would seem more extensible and less>fragile.> >>This would also unify with Costin's thoughts regarding tool-neutral>standards for the repository and project descriptors. The URI tells the>repository what you want, and it responds with the information known about>it, such as the locations of its parts, dependency information, build>instructions, etc. The URI could encode optional filter information about>what we want in the response. Depending upon whether the resource were>dynamic or static, the filter might or might not be honored.>>Seems to me that some of the prior art associated with JNLP should be>brought into the picture, as well as everything that Maven has learned about>repositories. And REST in terms of the web interaction.> >>Also, shouldn't URIs also support movement of the resource, e.g., when a>sub-project moves from underneath a project? For that matter, is the>project hierarchy really useful in the URI, or just a unique name?> >>Thoughts?> >Your approach seems very powerfull, I like it.I was trying for a "Valid" repositry being just a filesystem. I think we can add the rest later as optionl support elements.A filesystem only approach lets other people build "compatible" repositories without tools or keeping a catalog.xml or whatever uptodate.> --- Noel>>>->To unsubscribe, e-mail: [EMAIL PROTECTED]>For additional commands, e-mail: [EMAIL PROTECTED]> >-- Nick Chalko Show me the code. Centipede Ant + autodownloadable build plugins + needed jars autodownload. http://krysalis.org/centipede--To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF repository URI syntax
Nick, can you explain why there is a need for a subproject and not a sub-subproject etc?--dIon Gillard, Multitask ConsultingBlog: http://www.freeroller.net/page/dion/WeblogWork: http://www.multitask.com.au-Nick Chalko <[EMAIL PROTECTED]> wrote: -To: community@apache.orgFrom: Nick Chalko <[EMAIL PROTECTED]>Date: 03/01/2003 09:38AMSubject: ASF repository URI syntaxI think in general ./ or ./index.html should return a human readable form and ./index.xml should give machine readable form of the following* / o list of projects in the repository* /project o list of subprojects o list of versions available if there is no subprojects* /project/[subproject]/ o list of versions available* /project/[subproject]/version/ o list of artifacts available.* /project/[subproject]/version/artifact. o downloads the actual artifact.I think this a reasonable base set that support both a simple filesystem or an smart server.These are just ideas to get the discussion of the protocol started.Comments.R,Nick-To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
RE: ASF repository URI syntax
Yes. Stable URIs are a must. Hence the subproject piece of the directory structure was left out of the maven repository and we went with only. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au -"Noel J. Bergman" <[EMAIL PROTECTED]> wrote: - To: From: "Noel J. Bergman" <[EMAIL PROTECTED]> Date: 03/02/2003 09:05AM Subject: RE: ASF repository URI syntax > i think that maybe organization / project would be better that > /project/[subproject/..]. More stable, less fragile. Still provides for qualified the naming space, and is more in keeping with how we've been doing package naming. I don't know if it needs to be a directory hierarchy, though. The naming separator could be anything. --- 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: [proposal] daedalus jar repository (was: primary distribution location)
Nick Chalko <[EMAIL PROTECTED]> wrote on 01/03/2003 05:09:50 AM: > A somewhat standard layout is the important part. > > If we are changing current practice I think > > project/[subproject]/version/(jar|zip|gz|docs|liscenses) > is very good. Sub project is, IMHO, way too fragile to be part of the URI. This is why we left it out of maven. Same for cvs name. Projects often move 'up' and change their cvs repo. > All kinds of artifacts for a particular version in one dir. Seems the > easiest to me. My personal preference is to have the version in the artifact name for use later on. This is, I know, an unpopular view, but one that has saved many people time in the long run. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and community
Hey Costin, tell me if I'm reading this right: Costin Manolache <[EMAIL PROTECTED]> wrote on 01/03/2003 05:59:56 AM: > On Fri, 28 Feb 2003, Noel J. Bergman wrote: > > > > Collaboration does happen, now. It's not a future waiting to happen. > > > Is there something that's not happening that specifically needs to be > > > looked at? > > > > That's the irony. As far as I can see, most of the build processes could > > converge around Ant and Maven. It isn't hard to see how the domains served > > by Gump and Centipede could be subsumed by Ant and Maven, given the > > additional development that you've told me is already happening. The > > thought behind my earlier question about the PMC, which initiated this > > spiral, was that having Ant and Maven under a PMC would help that effort. > > I tried to stay out of this discussion. > > The points that I care about is where Maven tries to set a standard > that will affect the other build tools. The repository is one example, > the descriptors is the other. > > If the apache community can reach an agreement on base standards - > with the participation of all projects and people who are involved or > care about the build process - then we're fine. And it is even better > if we have multiple tools to support the repo and descriptors and try > to make the build process easy. If one project sets a 'standard' that's a bad thing. If we design by committee, that's ok. > I am worried that Maven will use agressive propaganda and the ASF brand > to compete against Ant. All I've seen so far suggest that. And I think > that would be bad. However - agressive propaganda has a tendency to > backfire, and smart people usually see beyond it. So what is there to worry about? If Maven hypes itself and then falls short of expectations, what the heck, it looks like it's only hurt itself. > I'm talking about all the "landslide move", "all others are crap", > "convert all your projects to maven", the removal of ant build files in > projects to force people to use maven, attacks to persons who are > involved with competing projects, etc ( I know that people learned that > some of those tactics don't work well - and I'm sure I'll see more ) The fact that Maven generates ant build files for use without Maven doesn't help any? > One problem may be that this kind of propaganda may hurt the > ASF brand and all projects involved - competition on "easy to use" > or features or speed is good in itself. If people start hype'ing Maven to the detriment of the ASF, I'm sure someone will step in. FWIW, most of the Maven developers don't want to push Maven onto other developers, and we've actively stayed out of the 'Please give us a proposal as to why we should adopt Maven' discussions. People will either want it or not. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
"Noel J. Bergman" <[EMAIL PROTECTED]> wrote on 01/03/2003 06:45:42 AM: [snip] > How much should be encoded in a URI, and how much in data associated with > the URI? You seem to be trying to encode all of the data into the URI > naming space. Why not have a single URI for the target, and then trigger > behavior based upon the content? That would seem more extensible and less > fragile. It would also seem to rule out any consistency of naming across projects, and make the user browsing of a repository a logistical nightmare. > This would also unify with Costin's thoughts regarding tool-neutral > standards for the repository and project descriptors. The URI tells the > repository what you want, and it responds with the information known about > it, such as the locations of its parts, dependency information, build > instructions, etc. The URI could encode optional filter information about > what we want in the response. Depending upon whether the resource were > dynamic or static, the filter might or might not be honored. Sounds like that rules out the simple filesystem mirroring that works so well everywhere. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
Costin Manolache <[EMAIL PROTECTED]> wrote on 02/03/2003 03:12:55 AM: > On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote: > > > Having a file encode --.type has been > very useful for us. > > > > Yes, it's often different from what the project creates and > distributes, but I (and others) > > have been bitten by > > commons-logging.jar, struts.jar, junit.jar so many times, that > seeing log4j-1.2.5.jar is a > > godsend. > > Yes, but I already mentioned that it can easily break features that work: > if a project uses Classpath attributes in the manifest ( a legal option > that simplifies setup - you may like it or not ) - then some things will > stop working. Having a versioned copy of the jar file around doesn't break anything that already exists. No-one is saying that people should remove their old stuff. > It will also break any script or program that creates classpaths by using > jar names. As will changing the directory it's in, the file extension etc. > And it will break the explicit CLASSPATH env variables and manifest > attributes once again every time you upgrade - since the jar name will > change. You mean people still specify CLASSPATH env variables. Yick. But, again, if you 'upgrade' you don't have to remove the old files. > It'll also break Ant build files that use the jar name - just do a grep > on jakarta and you'll find how many they are. And many of those are the ones people can't be bothered setting up. Most of commons for example is a PITA to build. I tried recently to quickly get commons-modeler going for a Tomcat connector, and it was a joke. Try building struts from source, the setup is a bitch. > All those problems can only be solved with the active participation > of the projects - by implementing whatever code is needed to support > filenames that change. For Classpath attributes - that's not possible, > so project will have to agree to stop using this (nice IMO ) feature. Not necessarily. If the manifest is built by a tool, it can automatically place the correct names in the classpath entry for you. > It doesn't matter how nice the versioned filename may look or > how much it can simplify maven code - if it breaks the code of the Costin, I'm not speaking about maven code here. In fact, I'm not talking about any code at all. > project ( sometimes in subtle ways - if ant or a project won't find a jar, > it may disable a feature ) > > It is also redundant information - each jar has a well-defined Manifest > that should include version. Really. Go read all the manifests on www.ibiblio.org/maven/*.jar and tell me how many: a) Have a valid manifest b) Have a license in the jar c) Have code from other projects contained within Believe me, the actual jars that are distributed by most projects do not come packaged ready for binary distribution. Take for example commons-logging 1.0.2 and the manifest in it's jar, which has: Class-Path: log4j.jar log4j-core.jar in it. > .so files are versioned - that would be the perfect argument to convince > people to adopt this naming scheme. But think what happens if someone > takes a .so file that was shiped with an application, and renames it to > something he feels is nicer. The app will just stop working. You can't > mess with a project distribution files without the risk of breaking > something. Nor should you just 'mess with a project distribution files' and expect things to still work. > Many people like this naming convention - but they can't impose it > to everyone. I'm more then willing to accept and support this naming Call your jars what you like. Noone is 'imposing' it on you. > scheme - my only condition is to be the result of an informed decision > by the apache developer community. ( the breakages are just 2 simple > examples - there are many other arguments in both sides ) > > BTW - an important thing to keep in mind is that in many cases the > latest version of a .jar may fix security bugs - so it shouldn't > just pick the buggy jar. Having multiple versions of the same What are you talking about here? What 'shouldn't just pick the buggy jar'? If something goes about picking new versions of jars, that I've gone to the trouble to specify, I'm going to be very upset. If I've asked for 'the latest', fair enough. > jar in a system creates huge problems. Having multiple versions of the same jar in many 'systems' is not an issue. Classloader isolation exists for a reason. Imagine a servlet engine where you can only have one copy of struts.jar. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote on 02/03/2003 05:36:38 AM: [snip] > I've gotten bit by the opposite problem (changing version number in a JAR > filename causing broken build scripts) just as often. > > Wouldn't a reasonable approach to this problem be to make searches for > "commons-foo.jar" return the latest released version, while searches for > "commons-foo-x.y.jar" would return that particular version? Then, you can > have it either way. On the former, one might also support a mode that > grabs the latest nightly instead of the latest reslease. Maven has the concept of a 'SNAPSHOT' jar, which is the latest date-timestamped version of an artifact available. If tell Maven you depend on a SNAPSHOT, at each build it checks to make sure you have the latest available, and downloads the new one if needed. This however doesn't fix the problem, as people can change version numbers on jars to anything they want, possibly a fictitious release. 'LATEST' builds are often not reproducible as well. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF repository URI syntax
Nick Chalko <[EMAIL PROTECTED]> wrote on 02/03/2003 05:56:32 AM: > [EMAIL PROTECTED] wrote: > > > Nick, > > > > can you explain why there is a need for a subproject and not a > > sub-subproject etc? > > Good question. > > This also releates to "what is a project" . Jakarta , avalon, turbine. > poi, poi-contrib. > On the one hand we could allow unlimited subprojects. specify that > projects must start with a letter, and version must start with a number. > > Or the other aproach is only one level of projects then you have > jakarta-avalon-fulcrum. > > This is a namespace problem, how do we avoid naming collitions at Apache > I suppose we could say that a "project"="cvs module" In the interest of a URI that's not going to change too much, cvs module is as fragile as subproject in my experience, and whilst a good idea, still leaves the URI too fragile for my liking. > My preference would be for /project/[subproject/..]/version/artifact. Version being in the directory I've already mentioned. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: anyone know the progress of the Maven top level proposal?
I posted to [EMAIL PROTECTED] yesterday asking about the updated scope but have yet to hear a reply. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au -Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: - To: community@apache.org From: Rodent of Unusual Size <[EMAIL PROTECTED]> Date: 03/06/2003 05:23AM Subject: Re: anyone know the progress of the Maven top level proposal? James Strachan wrote: > Just wondered if anyone knew the boards latest view of the 'Maven as top > level project' proposal? Its been a bit quiet lately - have I missed > anything? afaik, jason, dIon, and the board are refining the charter. i think that's the only thing. -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" - 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: open software for testing
For webapps, we have a combo used in Maven of: a) JMeter ( http://jakarta.apache.org/jmeter/ ) and b) Latka ( http://jakarta.apache.org/commons/latka ) - Using JMeter's proxy server you can record a web 'session' . - The Maven Latka plugin can then convert the JMeter output to a latka test case - The Maven Latka plugin can the run those generated test cases. See http://maven.apache.org/reference/plugins/latka/ for more detail. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au Apache Software Foundation <[EMAIL PROTECTED]> wrote on 30/03/2003 12:30:50 AM: > acked; anyone in apache-land know of anything of ours, or > anyone elses', that does this sort of thing? maybe the > CPAN Test::* modules? please respond to the original author > with a bcc to community@ so we can all learn.. > -- > The Apache Software Foundation > > If you have not looked at http://www.apache.org/foundation/preFAQ.html > PLEASE DO SO NOW. There's an excellent chance your question/concern > is addressed therein. If your question concerns licensing, please see > http://www.apache.org/foundation/licence-FAQ.html > > - Message from Kenzo Saito <[EMAIL PROTECTED]> on Mon, 24 > Mar 2003 17:39:02 -0500 - > > To: > > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > Hi, > > I'm not sure if you are able to answer my question or not (I hope you are > though). I work for a software company in Toronto and I am currently trying > to investigate if the exists any sort of open source programs that do > automated testing. Previously we have been using a program called > TestPartner from NuMega. It basically allowed us to test out our GUI, by > recording and playing back scripts. It also allowed us to edit the scripts > using VB for Applications. Since you guys at Apache are experts in the open > source community, I was wondering if you knew of any open source program > that perform automated testing? Any information would be extremely useful. > > Thanks, > Kenzo > > Gregory Kenzo Saito, Product Development Co-op > Cast Software, 35 Ripley Avenue, Unit 1 > Toronto, Ontario Canada M6S 3P2 > Tel: (416) 597 2278 x254 Fax: (416) 597-9594 > [EMAIL PROTECTED], http://www.cast-soft.com > > > > > > - > 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: Follow the example
Ceki Gülcü <[EMAIL PROTECTED]> wrote on 18/09/2003 11:55:43 PM: > Everyone would agree that spreading the good word on ApacheCon US 2003 > will contribute significantly to its success. > > Some projects have begun to do just that. See for example, > >http://www.apache.org >http://jakarta.apache.org >http://jakarta.apache.org/tomcat/index.html > > Thus, I urge all ASF projects (and subprojects) follow their example > and add a prominent icon to their project pages. Please do not wait > until the conference starts. We really need to properly market > ApacheCon US 2003. As an important source of revenue for the > foundation, the success of AC 2003 matters to us all. > > As far as I can tell, the following projects have *not* updated their > web pages. > >Ant >Apr >Avalon >Cocoon >DB >Incubator >James >Maven >mod_perl >PHP >TCL >Web Services >XML > > What can be done to fix this? Many thanks in advance, There's no coverage on some of the top level projects you mention, e.g. no sessions on Ant, Avalon, James & Maven. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EarthQuake near Sumatra
Has anyone heard from dims? -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
