Re: ASF Repository Structure
Noel J. Bergman wrote: Why not just ":///artifact-name", where artifact name is as qualified as necessary, and is permanent? The project name, sub-project relationships, versioning, etc., could all be handled by the descriptor contents. So http:repo.apache.org/ant would return a discriptor such as For the smart repository approach, if you want to add additional contraints use a REST approach that allows parameters to be specified, e.g., HTTP GET / POST parameters. A static repository would just give you the entire descriptor, and you would parse out the content that you need. --- 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]
ASF repository URI syntax
I 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 Structure
Why not just ":///artifact-name", where artifact name is as qualified as necessary, and is permanent? The project name, sub-project relationships, versioning, etc., could all be handled by the descriptor contents. For the smart repository approach, if you want to add additional contraints use a REST approach that allows parameters to be specified, e.g., HTTP GET / POST parameters. A static repository would just give you the entire descriptor, and you would parse out the content that you need. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Jar Repository Requirements.
Nick Chalko wrote: This is a top of my head list of requirements for the Apache Jar Repository (AJR) * AJR shall o only host artifacts approved by a PMC o be accessible to the public via http o be mirrorable. allow browsing and downloding of artifacts by humans via normal web browser * AJR should o provide metadata about a project, + its components + its dependencies + its artifacts + list of version available + url's to find specific versions of an artifact. o Provide tools for the management of the project metadata o Allow for low cost maintance by hand without tool support. * AJR should not o * AJR shall not o Host any artifact in violation of a license, or IPR. Lets improve the list and post it on the wiki. R, Nick - 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 Structure
Noel J. Bergman wrote: The point of agreement is the format of the URI and the schema for the descriptor files, and everything is mapped from there. Then I propose the URI be /projectname/[subproject]/[version]/artifactname Which would allow a simple filesytem backend or an advanced smart server. One of my goals it to be able to host my own Apache Jar Repository (AJR) compatible files by placing nick.jar in /var/www/html/myrepo/myproj/1.0.2/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache Jar Repository Requirements.
This is a top of my head list of requirements for the Apache Jar Repository (AJR) * AJR shall o only host artifacts approved by a PMC o be accessible to the public via http o be mirrorable. * AJR should o provide metadata about a project, + its components + its dependencies + its artifacts + list of version available + url's to find specific versions of an artifact. o Provide tools for the management of the project metadata o Allow for low cost maintance by hand without tool support. * AJR should not o * AJR shall not o Host any artifact in violation of a license, or IPR. Lets improve the list and post it on the wiki. R, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF Repository Structure
Noel J. Bergman wrote: The point of agreement is the format of the URI and the schema for the descriptor files, and everything is mapped from there. Then I propose the URI be /projectname/[subproject]/[version]/artifactname Which would allow a simple filesytem backend or an advanced smart server. One of my goals it to be able to host my own Apache Jar Repository (AJR) compatible files by placing nick.jar in /var/www/html/myrepo/myproj/1.0.2/ -- 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]
ASF Repository Structure
Nick, My apologies for reformatting your reply, but I thought that it made sense to rename the thread, and still keep the context intact. How did you perceive my strawman to be incompatible with a filesystem only approach? If the URI for an addressable entity results in an XML file, for example, than a file system only repository would delivery the contents of that file. Now, should you happen to be using a dynamic server, you could modify the response to only deliver content requested. Consider this: if I have the XML descriptor for a given entity, I can look in it for the particular version I care about, using the version labeling used by that project, and find a currently valid URI to download the package over an appropriate transport. This can be done entirely by the client tools. Of course, if the server were smart enough to understand a more specific request, it could hand me just what I want to know, and not force me to have to parse as much, or even adjust a mirror list based upon geo-matching and some request balancing heuristics. To replicate the server, you could use rsync. Whatever is there is moved. The server doesn't actually have to care about the structure. The real structure is encoded in the contents of the descriptor files. Actually, a better way of saying this is that the structure of the repository could be decoupled from the structure of the file system. In my mind, only client tools are required to understand what the descriptors say about the repository structure; the repository server understanding it is a bonus. This also removes the need to agree upon anything related to the downloadable file names. You don't have to agree on project-subproject-developer-lunarphase-version-platform.ext. The point of agreement is the format of the URI and the schema for the descriptor files, and everything is mapped from there. This should allow federation with other repository systems, e.g., CPAN, if I am not missing something key. So if I had a project that used BSF and some hypothetical perl engine, I could have a descriptor that told the tool to grab the BSF and perl jars using that scheme, a platform-specific perl engine (hypothesizing that the perl engine would be a JNI bridge) from elsewhere, and Perl modules via CPAN. So this approach should be totally agnostic with respect to tools, languages, projects and platforms. I'm not saying that this is a great idea, just that it sounds good to me so far. I'm keen to hear what others say about it. --- Noel -Original Message- From: Nick Chalko [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 14:54 To: community@apache.org Subject: Re: [proposal] daedalus jar repository 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. -- Nick Chalko -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 14:46 To: community@apache.org Subject: RE: [proposal] daedalus jar repository (was: primary distribution location) Nick, As long as you want to start with first principles ... > >If we have a layout and metadata we agree on - any tool could work. > >If it is an ant task or a perl program or we just rsync - it doesn't > >matter. > A somewhat standard layout is the important part. > 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? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additiona
Re: [proposal] daedalus jar repository
Noel 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: [proposal] daedalus jar repository (was: primary distribution location)
Nick, As long as you want to start with first principles ... > >If we have a layout and metadata we agree on - any tool could work. > >If it is an ant task or a perl program or we just rsync - it doesn't > >matter. > A somewhat standard layout is the important part. > 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? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Maven and community
All your projects are belong to us. :-D Excelent. This thread needed a good joke -- 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]
[OT] Re: Maven and community
Costin Manolache wrote: 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. All your projects are belong to us. - Kasper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and community
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. 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. 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 ) 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. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and community
Jason, Did anyone question that you've contributed an immeasurable amount of good? I didn't. What happened was that you responded negatively to an aside about why not to put Ant and Maven under a single PMC. You talked about about not being forced to collaborate, and pulled Gump, centipede, the Board, other developers, etc., into the mix. > The fact of the matter is you barely know me at all and > without context they probably did seem out of place. Whatever other out-of-band thoughts were in your mind, you over-reacted. And every other response followed from your reactions. > I am not an entirely unreasonable person I'm just highly > opinionated. > Let it rest. Works for me. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and community
> Representing Jason as all Maven developers is a leap > beyond that I can't fathom. As I said, I would expect that his comments weren't reflecting Maven's as a group, and I know that they don't reflect yours. > 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. Nope. I simply pointed out why someone might have concern about a project based upon the strongly worded sentiments of one of its leaders. > Jason is an 'entity'? I figured he was a person with all > the usual good and bad points, much like you and I. Absolutely. :-) But since the concern had been generalized to the community, albiet not by me, that sentence wasn't refering to Jason personally. In any event ... not to drift further afield in unproductive directions ... > 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. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Costin Manolache wrote: On Fri, 28 Feb 2003, Nicola Ken Barozzi wrote: Seeing the interest it has raised, I tend to think think it's time to get the act together and start working on it. I'd like to propose this for incubation ASAP, so to not loose momentum. ... Codebases or part of codebases that could convole in the effort: ... I don't think the main issue is codebases. What we need is a minimal common ground on naming conventions for the repository ( so projects can get in sync with the repository ), and an agreement on a metadata format ( descriptors for dependencies and versions and so on ). I think discussion on codebase will just create a mess. The goal is to have a jar repository and get some consistency among our projects. I agree. If we have a layout and metadata we agree on - any tool could work. If it is an ant task or a perl program or we just rsync - it doesn't matter. 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. All kinds of artifacts for a particular version in one dir. Seems the easiest to me. Costin - 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: Maven and community
On Fri, 2003-02-28 at 02:04, Noel J. Bergman 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. I don't see how my comments could not be seen as representative of myself. I make no apology for speaking my mind, being somewhat ruthless and even vicious at times. Most people who meet me find I'm generally amicable. I am not averse to collaboration but like everyone, whether they care to admit it or not, I am selective. An example of this for me outside of software is my participation in activities around my community. I don't have any children of my own but I help take of my neighbour's children, go to parent/teacher meetings and I'm generally interested in the education of children. I like to setup little workshops for kids for building radios or whatever. I was once asked to work with this person who was the embodiment of popular trends in education in the province I live in. In a nutshell the theory is a child's self-esteem is more important critical thinking. That it's ok if Bobby can't spell 'button' as long as he feels good about himself. To me that is utter nonsense. Self esteem emanates from the ability to think critically and deal with the world around you. Creating a artificial bubble around a child serves no useful purpose and you are basically crippling the child for life. That's my personal view and I felt so strongly that this is a digusting notion and will only server to cause widespread irrepairable damage. So I told this person to screw off and that I would have nothing I feel much the same way about creating an artifical bubble of community around projects that have no substance. That quality software comes first and it is not borne out of community. If the software is good, serves a purpose and is useful a community will form. I feel that collaboration with some individuals and groups would only serve to poison worthy efforts. They are my personal feelings and I'm certainly not going to ignore them. I don't have to like everyone, I don't have to respect everyone. I get singled out for a single line of dialog and get labeled as a hostile anti collaborator but I have actually done some good around here and have worked successfully with many individuals to get things done. > You know me well enough to know that I view collaboration as the efficient > reuse of expertise, creativity and resources towards the synergistic > development of the best result. No matter how right I think I am, I could > be wrong about something; no matter how wrong I think someone else is, there > could be the seed of a really good idea there if I am willing to give it > further exploration after shrugging off the first reaction to dismiss it. > Usually there is an amalgam that is better than the original "pure" ideas. I don't just decide arbitrarily not to collaborate. I look at all I can get my hands on and make a decision. And I most certainly agree that all ideas are recombinations of existing ideas with the odd original extension. > 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 > 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 > antagonistic response, with neither provocation nor justification, was > disconcerting to say the least. Would you please give it a rest. The fact of the matter is you barely know me at all and without context they probably did seem out of place. My qualms are with a very select group. Take a look at some of the other things I've done. I don't have a blanket-venom policy for everyone. I can also work productively when there are disagreements. Geir and I have often had it out over bits and pieces in Velocity but we always eventualy align and compromise and Ve
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Fri, 28 Feb 2003, Nicola Ken Barozzi wrote: > Seeing the interest it has raised, I tend to think think it's time to > get the act together and start working on it. I'd like to propose this > for incubation ASAP, so to not loose momentum. > ... > > Codebases or part of codebases that could convole in the effort: > > ... I don't think the main issue is codebases. What we need is a minimal common ground on naming conventions for the repository ( so projects can get in sync with the repository ), and an agreement on a metadata format ( descriptors for dependencies and versions and so on ). I think discussion on codebase will just create a mess. The goal is to have a jar repository and get some consistency among our projects. If we have a layout and metadata we agree on - any tool could work. If it is an ant task or a perl program or we just rsync - it doesn't matter. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Are you arguing that the ASF should stop striving to keep licenses compatible? No. Where did you get that idea? Probably entirely from my own paranoia that people would rather write code than deliver easy to adopt software. My apologies. - ben - 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]
Jakarta Newsletter
Hi, For those of you that don't know I'm behind the effort for a monthly(ish) newsletter from the folks at jakarta. The original aim was to help developers stay informed of whats going on in the rest of Jakarta without them having to monitor every list, each subproject would send in tidbits of the interesting stuff that had been going on. Its an opportunity to let other developers know of changes / plans / decisions that aren't necessarily worth going out to a project specific announcements list. To get a feel for the contents you can browse previous newsletters here: http://jakarta.apache.org/site/news/. But it doesn't have to be solely Jakarta related: Last month we had an entry from db.apache.org letting us know that some of our components were moving to that umbrella which seemed reasonable. There also seems to be a general feeling that projects such as Ant, Avalon, James should still be invited to contribute to the letter even though they're not strictly jakarta projects any more. Thanks to all this and a long running intention to invite the xml team to contribute I thought it was time to invite one and all to contribute. If this all works out then I guess we can talk about breaking away from the Jakarta name and format changes but for now I thought it would be good to just test the water and plug the contributions into the next issue of the Jakarta Newsletter (next week sometime). So what does it take to contribute? Pretty simple really - just email me with a summary of what's been going on in your favorite project during the last month and it will get included so long as I spot it flying past (stick Newsletter somewhere in the subject line to get better odds). Sending text inline has been quite successful so far although patches to the xdoc (once I've started it) would make life easier. Alternatively we could start up a Wiki page and have people add to it as they see fit. Its a good plan to let the people at the project know so that effort is not duplicated. I plan to pull together any contributions on monday and post the first draft on general@jakarta.apache.org, more drafts will appear as more contributions come in and by the end of next week I hope to be ready to post the finished copy on [EMAIL PROTECTED] If you want to discuss the newsletter generally then I'm sub'd to community@apache.org and general@jakarta.apache.org which seem to be the best places to aim. Thanks in advance, Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Henri Gomez wrote: FYI, the JPackage project where I'm also involved, as set up a Java RPM centric distribution where you could find many (still not all) apache's java projects. http://.jpackage.org/ Hi, Henry. I'm using them and they are awful to simplify maintenance of linux rpm based machines. I'm currently using them in all the server that my company manages. Thanks for it. We splitted the package in 2 categories, free and non-free. free packages are those that can be build from sources AND could be freely distributed non-free packages are those with licences which prevent them from being freely distributed (including ALL the Sun external but mandatory libraries like activation, mail...) For those interested, take a look at http://www.jpackage.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Henri Gomez wrote, On 28/02/2003 15.08: Leo Simons wrote: Hi all, (sorry for the massive crosspost up front, as this is a proposal that should in the end come from the various PMCs towards the infrastructure team I'm doing lots of CCing, just once) FYI, the JPackage project where I'm also involved, as set up a Java RPM centric distribution where you could find many (still not all) apache's java projects. http://.jpackage.org/ ... I'm happy Leo started this discussion, and I'm even more happy that it's gaining positive attention. Seeing the interest it has raised, I tend to think think it's time to get the act together and start working on it. I'd like to propose this for incubation ASAP, so to not loose momentum. We have already some volunteers, from many camps: (Maven) dIon Gillard ([EMAIL PROTECTED]) (Ant) Costin Manolache ([EMAIL PROTECTED]) (James) Noel J. Bergman ([EMAIL PROTECTED]) (Ruper) Nick Chalko ([EMAIL PROTECTED]) (Version) Adam Jack ([EMAIL PROTECTED]) (XML) Ted Leung ([EMAIL PROTECTED]) (Gump)Nicola Ken Barozzi ([EMAIL PROTECTED]) Please remove yourselves or add and edit at pleasure. Codebases or part of codebases that could convole in the effort: - Apache Jakarta Turbine Maven - Krysalis Ruper - Krysalis Version - Ted Leung's efforts (don't remember the name) Future coordination efforts with: - JPackage - CJAN Initial Reference Properal (please edit at need, it's a canvas): http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Leo Simons wrote: Hi all, (sorry for the massive crosspost up front, as this is a proposal that should in the end come from the various PMCs towards the infrastructure team I'm doing lots of CCing, just once) FYI, the JPackage project where I'm also involved, as set up a Java RPM centric distribution where you could find many (still not all) apache's java projects. http://.jpackage.org/ We splitted the package in 2 categories, free and non-free. free packages are those that can be build from sources AND could be freely distributed non-free packages are those with licences which prevent them from being freely distributed (including ALL the Sun external but mandatory libraries like activation, mail...) For those interested, take a look at http://www.jpackage.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and community
Just for reference - I'm somewhat surprised at the flack handed out to Jason. He and the other Maven committers are doing an out-and-out brilliant job of bringing together the next generation. My feeling is that these guys are being squeezed unnecessarily - but don't ask me why because I don't know. They have built a active and dynamic community, they are about to change the way a lot of us doing things, and in my opinion - they deserve our out-and-out support (across board, comunity, and project levels). Cheers, Steve. Noel J. Bergman 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 know me well enough to know that I view collaboration as the efficient reuse of expertise, creativity and resources towards the synergistic development of the best result. No matter how right I think I am, I could be wrong about something; no matter how wrong I think someone else is, there could be the seed of a really good idea there if I am willing to give it further exploration after shrugging off the first reaction to dismiss it. Usually there is an amalgam that is better than the original "pure" ideas. 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 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 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. Your reply that the workload of one PMC having to oversee both projects being too high to do properly came across as completely differently in character. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and community
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 know me well enough to know that I view collaboration as the efficient reuse of expertise, creativity and resources towards the synergistic development of the best result. No matter how right I think I am, I could be wrong about something; no matter how wrong I think someone else is, there could be the seed of a really good idea there if I am willing to give it further exploration after shrugging off the first reaction to dismiss it. Usually there is an amalgam that is better than the original "pure" ideas. 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 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 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. Your reply that the workload of one PMC having to oversee both projects being too high to do properly came across as completely differently in character. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Scrambling jar files?
On Thu, 2003-02-27 at 20:16, [EMAIL PROTECTED] wrote: > 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. > -- Two things to note: 1) Brian over on the maven-dev list has functioning code that does the click through thing. Goes to Sun's site and provides the user with the license as is and brings down the JAR. 2) Geir has put me in contact with Bill Shannon and and Tom Kincaid (manager of JavaMail). This hasn't gone too far but I've been keeping a record of the dialog here: http://jakarta.apache.org/turbine/maven/sun-licensing-journey.html -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - 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: Scrambling jar files?
> 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]
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]
Scrambling jar files?
I just ran into this and found that might be worth injecting into the jar repositories discussions. http://nbbuild.netbeans.org/scrambler.html -- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
