Re: math to apache commons was Re: [all] Separate email list for math development?
On 12 Nov 2003, at 12:30, Geir Magnusson Jr. wrote: On Tuesday, November 11, 2003, at 06:51 PM, robert burrell donkin wrote: On 11 Nov 2003, at 12:47, Geir Magnusson Jr. wrote: snip 2) I have a feeling that no one would utter a peep if someone did some GUI extensions to a project here at Jakarta. We've always been willing to stretch the meaning of our charter (hence POI), and if it really came to be a problem, I think we would try to work it out. there seem to be a lot of senior apache members who don't agree with that. i'd rather act to try to start sorting things out before whilst the jakarta community still has a say. You're notion of sorting it out seems to be remove from Jakarta community. That may be what the people involved want to do, which is fine by me, but if they want to stay, it behooves us on the PMC to try and see what we can do to help them out. i'd be happy if someone wanted to approach the board requesting a change to the charter but whilst the charter existing in it's current form, i think we need to abide by it. IMO if math wants to stay here in the jakarta-commons and be managed by the jakarta pmc then the community needs to understand the limitations. i haven't been as involved with math as i'd have liked to have been (or as much as i'd intended when i planted the seed) but seems to have come through some difficult times to emerge as a very healthy community. i've tried to outline the future issues that i think are approaching for the community and offered a solution. i think that a move to apache commons would be a very positive step for math. in general terms, (i might be wrong but) the impression created on the community list was that the decision had already been taken at the ASF level a long time ago to sort out jakarta by reducing it's management responsibilities. the jakarta pmc has taken a *lot* of flak about it's failure to persuade more sub-projects to move. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On 11 Nov 2003, at 11:31, Geir Magnusson Jr. wrote: On Sunday, November 9, 2003, at 05:39 PM, Tim O'Brien wrote: On Sun, 2003-11-09 at 14:24, robert burrell donkin wrote: snip/ so - is there a positive alternative? i'd like to propose that common-maths continues to be affiliated with jakarta-commons but becomes managed by apache commons. +1, I think that now is the right time to move commons math to Apache Commons. What does 'affiliated' mean? i can't recall just now who coined it but here's what i meant by the term. most users interactive with jakarta through the website and newsletter. for them, a product is part of jakarta if it's listed in the products section of the jakarta side bar (and - to a lesser extent - is categorized under jakarta in the newsletter). issues of management shouldn't really need to concern a user too much. if they can click on a link to the product's home page from the jakarta sidebar and join the product's mailing list from the jakarta mailing list page then the product is part of jakarta (as least as far as they are concerned). of course, if a product is managed by another pmc, then the product website will be hosted under a separate virtual host and linked from the main project website. similarly the mailing list will not be @jakarta. but from a user's perspective, the product will still be part of jakarta. affiliation was the term coined to express this kind of relationship. of course, this only applies if product move to top level projects which offer multiple products. it seems to me that this is the only (positive) way that jakarta can be reduced in size until it again become manageable (but maybe this is a matter for the members...) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
I'd say that the discussed scope, at least some visions of it, make it more appropriate for a top level project than apache-commons, but I'll second Henri's advice to cut a 1.0 release from jakarta-commons and draft up a scope/vision document, then make the choice based upon what feels right at the point. I don't think it stretches the jakarta-commons or jakarta-general scope much (or at all, relative to other jakarta projects) to include a set of basic, java-based mathematical utilities--there are certainly plenty of server-side applications of that. A set of basic, not-necessarily-java-based utilities would be more appropriate in apache-commons. A more-than-basic set of utilities, in or out of java, would be more appropriate at the top level IMO. How one defines basic here is obviously an important part of answering this question. On Wed, 12 Nov 2003, Danny Angus wrote: Robert wrote: IMHO we're now starting to forget the original charter. Gier replied: Starting??? :) Please, we've been stretching the charter for *years*. Isn't that a major contributory factor in the, how can I put it.. concern expressed in some quarters about Jakarta? And if so is it not also something we should be addressing by being realistic about issues like this one? You're notion of sorting it out seems to be remove from Jakarta community. That may be what the people involved want to do, which is fine by me, but if they want to stay, it behooves us on the PMC to try and see what we can do to help them out. I'd say that if there is not a _real_ justification for math being in Jakarta which is aligned with Jakarta's mission it is our duty to Jakarta to be realistic about math, and not simply to fudge an artificial accomodation, avoid tough the decisons, and provide ammunition for critics of Jakarta's organisation. I would then feel that I had a moral obligation to the math community to help them find an acceptable new home, and Apache commons seems like a perfectly reasonable suggestion. After all if the math mission really is divergent from our charter then leaving won't be a big wrench, on the other hand if it is aligned well with the charter that is enough justification for math staying. Surely? d. - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On Mon, 10 Nov 2003, Mark R. Diggory wrote: Most Commons projects have arisen from either top level apache projects, xml apache projects or jakarta apache projects. As such they are You'd be surprised that this isn't as common as you think :) Many came out of a junky 'util' project. Struts have been good about factoring out some internal bits, but to a large extent I think the Struts ones are the only ones that have succeeded as spawned projects. Many of the other spawned projects didn't make it out of the sandbox. I think a great deal of thought has to go into why this sort of perceived bifurcation is occurring between Apache Commons and Jakarta Commons. Is there a problem here? Are groups disagreeing with one anothers written mandates? Or perceived mandates? Do people just not like working together? Maybe Jakarta needs to issue a more uptodate position on its content? There certainly are allot of non-server It's confusing. I don't think anyone knows yet what the deal will be with A-C and J-C. There's no board-push to move J-C to A-C, and A-C is really just waiting for things to turn up so far. oriented tools in it, (CLI, Jelly, BCEL, BSF, Gump, Log4j, ORO, Regexp, JMeter . . .) and there really isn't anything that suggest Jakarta or the Jakarta Commons are only for Server related packages. What I do see are different groups of programmers forming separate schools or clicks. [cliques] :) Do you mean language based? Java vs C vs Python vs Perl? Or internal Jakarta based? Tomcat vs Turbine vs Avalon? This might be a big difference in the httpd/Jakarta world. Jakarta treats 'server' quite liberally while httpd has until recently seemed to focus only on port 80/443 server stuff. IMHO, the focus now should be on a release of our current efforts in Jakarta Commons, this will provide a point of reference which we can grow off of and others can experiment with. It will also get us onto a more solid release schedule. This was going to be my question when I started replying. Should Math focus on a tight release of what they currently have under the J-C sunshade [as people seem scared of the word umbrella] and then start trying to figure out what thoughts there are for weird and whacky ideas. Seems to be what you're saying, so +1. We should also consider that we may be working other open source codebases and projects into the Apache project in the future. We should expect we are going to eventually need more room to work on such integration and experimentation outside the scope of what we will want to make modular and available via the Jakarta Commons. I'm convinced I'd like to see a parent project for the Jakarta Commons Math API, I'm not convinced yet that it should be outside Jakarta. I think initially, as least, any parent project of math is going to be very Java centric, we should take things one step at a time and make changes as they are needed. I think there will be some diplomacy etc to figure out just where a Jakarta Math or Apache Math or Mapache would live. Once the Math release in Commons is made, write a couple of scope documents. One for inside Jakarta and one as a TLP for Apache. See which feels the most comfortable. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On Sunday, November 9, 2003, at 05:39 PM, Tim O'Brien wrote: On Sun, 2003-11-09 at 14:24, robert burrell donkin wrote: snip/ so - is there a positive alternative? i'd like to propose that common-maths continues to be affiliated with jakarta-commons but becomes managed by apache commons. +1, I think that now is the right time to move commons math to Apache Commons. What does 'affiliated' mean? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On Sunday, November 9, 2003, at 10:52 PM, Craig R. McClanahan wrote: Regarding separate DEV list -- as I said in my earlier comments, that's totally up to the MATH developers if they want it or not. The fact that it might make my life easier certainly isn't binding. Note also that the httpclient guys were not pushed out; they deliberately chose to have a separate DEV list. That's the way it should work -- being up to the developers involved. +1 Hen Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
Henri Yandell wrote: On Mon, 10 Nov 2003, Mark R. Diggory wrote: Most Commons projects have arisen from either top level apache projects, xml apache projects or jakarta apache projects. As such they are You'd be surprised that this isn't as common as you think :) Many came out of a junky 'util' project. Struts have been good about factoring out some internal bits, but to a large extent I think the Struts ones are the only ones that have succeeded as spawned projects. Many of the other spawned projects didn't make it out of the sandbox. hmm, I see I think a great deal of thought has to go into why this sort of perceived bifurcation is occurring between Apache Commons and Jakarta Commons. Is there a problem here? Are groups disagreeing with one anothers written mandates? Or perceived mandates? Do people just not like working together? Maybe Jakarta needs to issue a more uptodate position on its content? There certainly are allot of non-server It's confusing. I don't think anyone knows yet what the deal will be with A-C and J-C. There's no board-push to move J-C to A-C, and A-C is really just waiting for things to turn up so far. Yes, this is what I'm concerned about. oriented tools in it, (CLI, Jelly, BCEL, BSF, Gump, Log4j, ORO, Regexp, JMeter . . .) and there really isn't anything that suggest Jakarta or the Jakarta Commons are only for Server related packages. What I do see are different groups of programmers forming separate schools or clicks. [cliques] :) Yes Mrs. Smith, my Spell checker ate my English homework... Do you mean language based? Java vs C vs Python vs Perl? Or internal Jakarta based? Tomcat vs Turbine vs Avalon? It seems there is a general movement in ASF to propagate some of the concepts and designs associated with Jakarta and XML projects out to all ASF projects as a whole, unfortunately this is translating into a number of different initiatives that appear to be stepping on each others toes. Apache Incubator vs. Apache Jakarta vs Apache Commons vs Apache XML vs Apache Avalon vs Apache DB This might be a big difference in the httpd/Jakarta world. Jakarta treats 'server' quite liberally while httpd has until recently seemed to focus only on port 80/443 server stuff. IMHO, the focus now should be on a release of our current efforts in Jakarta Commons, this will provide a point of reference which we can grow off of and others can experiment with. It will also get us onto a more solid release schedule. This was going to be my question when I started replying. Should Math focus on a tight release of what they currently have under the J-C sunshade [as people seem scared of the word umbrella] and then start trying to figure out what thoughts there are for weird and whacky ideas. Seems to be what you're saying, so +1. yes We should also consider that we may be working other open source codebases and projects into the Apache project in the future. We should expect we are going to eventually need more room to work on such integration and experimentation outside the scope of what we will want to make modular and available via the Jakarta Commons. I'm convinced I'd like to see a parent project for the Jakarta Commons Math API, I'm not convinced yet that it should be outside Jakarta. I think initially, as least, any parent project of math is going to be very Java centric, we should take things one step at a time and make changes as they are needed. I think there will be some diplomacy etc to figure out just where a Jakarta Math or Apache Math or Mapache would live. Once the Math release in Commons is made, write a couple of scope documents. One for inside Jakarta and one as a TLP for Apache. See which feels the most comfortable. Hen Sounds like a good way to move forward. -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
my 2cents (1) I think it would be best to get a 1.0 release of commons-math as a jakarta-commons subproject before any movement (the good-old KISS acronym comes to mind) (2) I am not sure to what extent math may get developed, as was stated in a different thread previously Java is not the best platform for Numerical Analysis. That being said, I dont forsee commons-math as a serious Numerical Anaylsis lib, rather a convenient and useful tool to explore 'simple' problems. This could be significant in research, in my opinion you dont really need to 'crank' up the system in most cases, and have a handy library that can get some nice results quickly in a Java setting is very valueable. There are plenty of high-scale number crunchers, and most of the best performing ones will always be in F77 due to its static nature. It may very well be that some of the value out of the math project is as an SPI to these backend 'crunchers' which provides a nice Java interface to interact with the rest of the world. (leading me back to the beginning of this rambling...) (3) I am thoroughly confused as to the pros-cons of what moving this the apache-commons level would do. I like the idea of a 100% java framework at this point (leading me back to point #1). In summary, I think it should stay where it is for now. -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
I do agree with much of what you say, but (2) There is significant number of us with an interest in seeing numerically sound implementations of various aspects of mathematics in java (no matter how wonderfully fast F77 implementations may be, Fortran will never be Java, nor would one want it to be). I could retort many reasons why this is an interest to myself and others in the group. Suffice it to say that java implementations do provide an elegant means to explore ideal Design Patterns for Mathematical packages and provide a foundation for exploring how to bridge java with other languages that may be more optimized to handle such computations. These are noble goals. -Mark Matt Cliff wrote: my 2cents (1) I think it would be best to get a 1.0 release of commons-math as a jakarta-commons subproject before any movement (the good-old KISS acronym comes to mind) (2) I am not sure to what extent math may get developed, as was stated in a different thread previously Java is not the best platform for Numerical Analysis. That being said, I dont forsee commons-math as a serious Numerical Anaylsis lib, rather a convenient and useful tool to explore 'simple' problems. This could be significant in research, in my opinion you dont really need to 'crank' up the system in most cases, and have a handy library that can get some nice results quickly in a Java setting is very valueable. There are plenty of high-scale number crunchers, and most of the best performing ones will always be in F77 due to its static nature. It may very well be that some of the value out of the math project is as an SPI to these backend 'crunchers' which provides a nice Java interface to interact with the rest of the world. (leading me back to the beginning of this rambling...) (3) I am thoroughly confused as to the pros-cons of what moving this the apache-commons level would do. I like the idea of a 100% java framework at this point (leading me back to point #1). In summary, I think it should stay where it is for now. -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
Mark R. Diggory wrote: ... There is significant number of us with an interest in seeing numerically sound implementations of various aspects of mathematics in java... Suffice it to say that java implementations do provide an elegant means to explore ideal Design Patterns for Mathematical packages and provide a foundation for exploring how to bridge java with other languages that may be more optimized to handle such computations. These are noble goals. Agreed. I can see the development of higher level APIs as a major goal for [math]. Interestingly, there are quite a few directions to pursue. One major direction is floating point number crunching, in particular - engineering and physics support, including large equation systems, ODE, PDE, numerical integration, continuus optimization, large eigenvalue problems, integral equations - computer geometry support, mainly CSG - computer graphics The other rough direction is discrete math: - number theory - graph theory (we've got [graph]) - planning and discrete optimization - encryption The application branch, somewhat randomly choosen keywords - CAS - data visualization, including curve fitting, descriptive statistics, adaptive filtering and isosurface detection - neural networks and machine learning in general - diagram layout, general graph layout - 3D modelling and rendering - ERP - network simulation Well, the utility of [math] for real world heavy number crunching (the very first point above) will always be limited. Other directions seems to be more interesting in terms of getting people using it in real world applications. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On 11 Nov 2003, at 12:38, Geir Magnusson Jr. wrote: On Sunday, November 9, 2003, at 10:52 PM, Craig R. McClanahan wrote: Regarding separate DEV list -- as I said in my earlier comments, that's totally up to the MATH developers if they want it or not. The fact that it might make my life easier certainly isn't binding. Note also that the httpclient guys were not pushed out; they deliberately chose to have a separate DEV list. That's the way it should work -- being up to the developers involved. +1 IIRC though httpclient voted to leave, the rest of us applied a *lot* of pressure. i don't think that they would have left without that kind of arm-twisting. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On 11 Nov 2003, at 12:47, Geir Magnusson Jr. wrote: On Monday, November 10, 2003, at 05:41 PM, robert burrell donkin wrote: a move to apache commons would allow this progression to happen much more easily. Why? the rules which apply here in the jakarta-commons about components and distributions would make things difficult. within a math group in the apache commons, different products could be developed by the same group of contributors with greater freedom. it would also allow gui visualization components to be developed (which we cannot allow here at jakarta). I just can't understand what you mean. To be clear : 0) What rules make things difficult? the jakarta project has a given scope granted by the board. until recently i though that i could give a rational justification that the projects we have here are at jakarta in scope (given a wide enough interpretation). IMHO we're now starting to forget the original charter. 1) In Jakarta-Commons, the developers have the freedom to develop what they want, when they want to in their projects. Additionally, developers can go off to the sandbox and do whatever they want, and when they feel that they have something solid, as to bring it to the commons community. Did math have any trouble starting, defining their project, or implementing things they way they wanted? there were some troubles but the limited current scope of math is fine. there are developments which are IMO definitely out of jakarta scope. there are also a number of jakarta-commons specific rules that would need to be bent to allow commons-maths to move in some directions that the community might want to take it. 2) I have a feeling that no one would utter a peep if someone did some GUI extensions to a project here at Jakarta. We've always been willing to stretch the meaning of our charter (hence POI), and if it really came to be a problem, I think we would try to work it out. there seem to be a lot of senior apache members who don't agree with that. i'd rather act to try to start sorting things out before whilst the jakarta community still has a say. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
J.Pietschmann wrote: Tim O'Brien wrote: so - is there a positive alternative? i'd like to propose that common-maths continues to be affiliated with jakarta-commons but becomes managed by apache commons. +1, I think that now is the right time to move commons math to Apache Commons. As long as [math] focuses on Java, I don't see what this will buy. If it's simply the commons list becoming too crowded, decide where [math] should go: 1. A companion to [lang], [logging] and [cli], valuing small over completeness and focusing on common tasks - stay at jakarta-commons 2. Grow into a full fledged library or even a system of apps related to numerical calculations - become a stand-alone Jakarta subproject, or even go top-level. J.Pietschmann I suppose I should clarify my opinion on this. Sorry if this is long winded and somewhat confusing. Also, it is just opinion... Most Commons projects have arisen from either top level apache projects, xml apache projects or jakarta apache projects. As such they are basically refactorings of codebases within those projects. As such, they provide a unique subset of functionality from those projects refactored and made available to the community as a whole via the Jakarta Commons. This is a very powerful mechanism and one which the Jakarta Commons is highly tailored for. To stick my neck out there: While some projects within the Jakarta Commons are uniquely evolved out the sandbox, it is clear that ultimately the best refactorings tend to arise after some considerable mucking about in larger projects with pre-existing applications of those code bases as working proofs of concept. Interestingly, this mucking about tends to be a bit more revolutionary when one is an independent project with room to both evolve and reinvent its codebase. This, in my opinion is what the math project is lacking by being only within the commons, some wonderful inventions could arise if theres more room to experiment and redesign, if theres room for Math subprojects and experimental endeavors such as Interpreter Frameworks, GUI Tools, MathML/OpenMath experimental implementations, usage byte code optimization tools... These are all things, which in my mind, don't have the space to grow as a simple jakarta commons library, but are vehicles for which a simple jakarta commons library would take its best shape through the experimentation with. So what I suggest is that Jakarta Commons Math would benefit from having a parent project where there are applications to offer strong working proofs of concept of its usage. Since Jakarta in and of itself has considerable focus on Server Side Java and specifically, tools that work well in its flagship Tomcat platform, there is concern as to if Jakarta is the right place for a project which may include adventures into Swing GUI's bridges with other programming languages and mathematical platforms, etc. I might suggest that there is really a very artificial and illusionary boundary between the concept of application and server. Is a Tomcat instance installed on my desktop a server platform or an application platform. Really, all I know is its a damn good platform for doing just about anything to do with java on! I think a great deal of thought has to go into why this sort of perceived bifurcation is occurring between Apache Commons and Jakarta Commons. Is there a problem here? Are groups disagreeing with one anothers written mandates? Or perceived mandates? Do people just not like working together? Maybe Jakarta needs to issue a more uptodate position on its content? There certainly are allot of non-server oriented tools in it, (CLI, Jelly, BCEL, BSF, Gump, Log4j, ORO, Regexp, JMeter . . .) and there really isn't anything that suggest Jakarta or the Jakarta Commons are only for Server related packages. What I do see are different groups of programmers forming separate schools or clicks. IMHO, the focus now should be on a release of our current efforts in Jakarta Commons, this will provide a point of reference which we can grow off of and others can experiment with. It will also get us onto a more solid release schedule. We should also consider that we may be working other open source codebases and projects into the Apache project in the future. We should expect we are going to eventually need more room to work on such integration and experimentation outside the scope of what we will want to make modular and available via the Jakarta Commons. I'm convinced I'd like to see a parent project for the Jakarta Commons Math API, I'm not convinced yet that it should be outside Jakarta. I think initially, as least, any parent project of math is going to be very Java centric, we should take things one step at a time and make changes as they are needed. Getting off my soapbox now (time for dinner), Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu
math to apache commons was Re: [all] Separate email list for math development?
On Sun, 2003-11-09 at 14:24, robert burrell donkin wrote: snip/ so - is there a positive alternative? i'd like to propose that common-maths continues to be affiliated with jakarta-commons but becomes managed by apache commons. +1, I think that now is the right time to move commons math to Apache Commons. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
Darn it, I just got done making all those little edits to hrefs and the bugzilla! ;-) 1.) Plausible, I understand though that Apache Commons is under subversion, will this be a challenge to migrate to? 2.) How will we relate to Jakarta Commons? certainly we may have dependencies on parts of the commons, but doesn't this leave little room for jakarta commons components to utilize math as a dependency as they are generally expected to be dependent on only other jakarta commons projects. -Mark Tim O'Brien wrote: On Sun, 2003-11-09 at 14:24, robert burrell donkin wrote: snip/ so - is there a positive alternative? i'd like to propose that common-maths continues to be affiliated with jakarta-commons but becomes managed by apache commons. +1, I think that now is the right time to move commons math to Apache Commons. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On 9 Nov 2003, at 22:07, Mark R. Diggory wrote: Darn it, I just got done making all those little edits to hrefs and the bugzilla! ;-) not a problem. they'll do just fine as they are :) there's not reason why users should be bothered by the change (see below). 1.) Plausible, I understand though that Apache Commons is under subversion, will this be a challenge to migrate to? subversion is (by all accounts) very, very cool. everyone here at apache will be using it sooner or later. those nice people over at apache commons will allow commons-maths to use cvs initially (if that's what's needed) but it'd probably be worthing thinking about making the jump straight away. 2.) How will we relate to Jakarta Commons? certainly we may have dependencies on parts of the commons, but doesn't this leave little room for jakarta commons components to utilize math as a dependency as they are generally expected to be dependent on only other jakarta commons projects. commons-maths will still be part of jakarta-commons :) it'll only be managed by the apache-commons pmc. best of both worlds :) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On Sun, 9 Nov 2003, robert burrell donkin wrote: commons-maths will still be part of jakarta-commons :) it'll only be managed by the apache-commons pmc. Which will make it in no way a part of jakarta-commons. Related to or linked from perhaps, but not strictly a part of in any meaningful way. best of both worlds :) - robert - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
On Sun, 9 Nov 2003, robert burrell donkin wrote: On 9 Nov 2003, at 22:07, Mark R. Diggory wrote: 1.) Plausible, I understand though that Apache Commons is under subversion, will this be a challenge to migrate to? subversion is (by all accounts) very, very cool. everyone here at apache will be using it sooner or later. those nice people over at apache commons will allow commons-maths to use cvs initially (if that's what's needed) but it'd probably be worthing thinking about making the jump straight away. You'll also have active support from those in favour of Subversion [coders of which are at Apache] so I'd expect this to move smoothly. 2.) How will we relate to Jakarta Commons? certainly we may have dependencies on parts of the commons, but doesn't this leave little room for jakarta commons components to utilize math as a dependency as they are generally expected to be dependent on only other jakarta commons projects. commons-maths will still be part of jakarta-commons :) it'll only be managed by the apache-commons pmc. I'm with Rod here. It won't be a part of jakarta-commons, though it should still be some kind of link on the Jakarta site. Jakarta Commons ought to have a vote to add dependency on Apache Commons Java projects as an acceptable concpet. This does raise a question in the PMC-setup for the ASF. If a project is meant to be a part of Jakarta and another project, ie) Commons, must there be a 1 to 1 mapping on the PMCs. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
Henri Yandell wrote: 2.) How will we relate to Jakarta Commons? certainly we may have dependencies on parts of the commons, but doesn't this leave little room for jakarta commons components to utilize math as a dependency as they are generally expected to be dependent on only other jakarta commons projects. commons-maths will still be part of jakarta-commons :) it'll only be managed by the apache-commons pmc. I'm with Rod here. It won't be a part of jakarta-commons, though it should still be some kind of link on the Jakarta site. Jakarta Commons ought to have a vote to add dependency on Apache Commons Java projects as an acceptable concpet. This does raise a question in the PMC-setup for the ASF. If a project is meant to be a part of Jakarta and another project, ie) Commons, must there be a 1 to 1 mapping on the PMCs. Hen Another issue to consider between the two groups is the java package namespace: org.apache.commons... -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
