RE: [proposal] daedalus jar repository (was: primary distribution location)
> 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. Just about any problem in this space can be solved by adding some indirection. In this case an xml file (or a set thereof) with possible versions and alternatives; and using URI pointers to the actual file. If nessesary you can let the URI point to a file with possible mirrors; or list the known mirrors in that same descriptive file. Once system we've used internally was to actually name the files to be downloaded by their MD5. This also made the use of lots of loosely connected/loosely managed mirrors easier. Dw - 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 (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: [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: [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: [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: [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: [proposal] daedalus jar repository (was: primary distribution location)
Noel J. Bergman wrote: Not sure what you mean by "lead" ( do you propose a new PMC with Dion as chair ? ). I'm +1 on Dion - however the layout and recommendations must be decided by the normal apache community process I meant as in "chair", except that it wouldn't be a PMC, so I don't know if the word "chair" would apply. It would be (part of) a President's Committee. Sounds like you'd be a good member, too. ;-) So that makes Dion, Leo and you, so far. <> Who else wants to volunteer? Nick? Morgan? --- Noel I would like to help in whatever way possible. - 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)
> Not sure what you mean by "lead" ( do you propose a new PMC with Dion as > chair ? ). I'm +1 on Dion - however the layout and recommendations must be > decided by the normal apache community process I meant as in "chair", except that it wouldn't be a PMC, so I don't know if the word "chair" would apply. It would be (part of) a President's Committee. Sounds like you'd be a good member, too. ;-) So that makes Dion, Leo and you, so far. <> Who else wants to volunteer? Nick? Morgan? --- 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 <[EMAIL PROTECTED]> wrote: > On Fri, 28 Feb 2003 [EMAIL PROTECTED] wrote: > > > > > > 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. > > Of course. The "maven" word comes up quite > frequently on this thread :-) > The issue is that the repository on daedalus will > affect all apache > projects that choose to use it ( to download and > upload files ). > Certainly a daedalus repository could be of use to many projects. One feature I would LOVE to see is a repository that contained the HEAD versions of every JAR in addition to snapshots, releases, etc. If I could flip a switch in my Maven, Ant, Centipede, etc. script and compile my project against the absolute latest and greatest, that would be an extremely useful sanity check. Whether those HEAD jars are built by Maven, GUMP, Centipede or "Tool X" makes no difference to me. However since GUMP is one of the only tools (perhaps the only tool?) that currently does the job, I find the statement that GUMP "sucks" disingenuous. Is GUMP easy to deploy for your own environment? Not really. Is it useful for building individualy projects a la Maven? No. Does it provide an effective continuous integration environment for Apache? Yes indeed. Does it suck? Hardly. If parts of GUMP are awkward, it's only because continuous integration is a thankless job. Thanks, GUMP. :) - Morgan = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
On Wed, 26 Feb 2003, Noel J. Bergman wrote: > - the ASF repository shall contain ASF jars, which don't >require oversight beyond the issuing PMC. > - the ASF repository should contain shared third party >jars for which the ASF has approved their use and >distribution. > - the ASF repository shall be mirrorable. Tools >intended to work with the ASF repository should >understand mirroring. [If not, they may select >a specific mirror, but I don't believe that we >want them to select the ASF repository as *the* >location.] Yes - finding the closest mirror ( or the fastest mirror ) is technically possible, but I'm sure most people would be ok if they just select one from a list, like they do for sourceforge. The ASF distributions are already mirrorable - all that we need is for the .jars to be included. I'm not very sure why the daedalus repository needs to make the symlinks ( when the main dist for src and binary releases is established ) and how those will be mirrored. > - multiple repositories are good things, and smart >tools should deal with multiple repositories. Supporting multiple kinds of repositories is good - i.e. support the original distribution format. A download tool shouldn't be specific to apache or apache repository - it should be able to get stuff from ibiblio or sourceforge or Sun or IBM ( eventually after displaying the license where it is required ). Multiple repositories for Apache projects are not a bad thing - maven or centipede or RedHat can choose to create other forms of repositories ( that work better with their tools ). I use apt-get to install software on my linux ( and emerge on the other box ) - a rpm or gentoo repository ( that is up to date ) would be great. I usually preffer getting a jar from the "source" - in the original format, with the signatures and guarantee of the producer. > - a smart tool might present a click-through license. >The repository should permit this as necessary. >[netbeans.org does this, by the way] Yes, that's a good example. Not sure if netbeans download tool supports sf or will support ASF repository - or if they provide their own repository with software to download (well, they do - but I don't know how complete it is ). I'm sure eclipse and other IDEs will eventually either support the original repositories ( my prefference ) or their own repositories. The actual layout of the files and location ( ASF mirrors, sf mirrors, etc) is far less important then the metadata format that describes the dependencies. We already have Gump descriptors covering everything in apache - and IMO this should be used either directly or transformed in one of the standard formats for describing dependencies. ( like apt descriptors, etc - there are several de-facto standards that are already supported by tools ). > - ASF projects, however, must not rely upon unapproved >third party jar files in such manner as to compromise >their license integrity, even if that jar is not >distributed via the ASF repository. Exactly. It was made clear ( and nobody objected ) that using tools in the build process is acceptable, and runtime dependencies are the main concern. So in the build process ASF projects may need to get GPL stuff from a GPL repository. This should be optional - IMO - but it seems this is not a legal requirement. > > If this becomes an apache-wide policy, I strongly disagree > > that Maven can decide for apache policies. > > I have proposed that the repository be a build-tool-neutral infrastructure > sub-project, since Dw expressed the willingness to have it under > infrastructure. I propose that Dion Gillard initially lead that effort, > taking advantage of his experience in the area. I don't believe that Dion > is a "Maven will define for all" kind of guy. Yes, the repository effects > all projects, but to me that just means that each PMC that cares to should > represent itself, not that we need to have dozens of people working this > out. Not sure what you mean by "lead" ( do you propose a new PMC with Dion as chair ? ). I'm +1 on Dion - however the layout and recommendations must be decided by the normal apache community process ( which doesn't include the notion of "lead", but proposals and votes ). Again - at least I have absolutely no problem accepting any layout, as long as I am sure it is the result of the apache community decision. Maven made a number of decisions that may be excelent for maven - but they're obviously different from what many apache projects use in their distribution. I'm also fine with a layout and policy that is set by infrastructure, under authority from the board. If a layout/policy is defined - we should do our best to sync the projects and start using the layout ( same thing that happened with the mirroring ) Same for metadata ( that describes dependencies ). However for metadata I think the standard requires participatio
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Thu, 27 Feb 2003 [EMAIL PROTECTED] wrote: > > 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. +1 I was just commenting on the original proposal - that included the dist/ tar.gz. Maybe a better alternative would be to just enhance the current dist layout with a jars/ directory, instead of creating a whole new structure ? And the only remaining issue would be defining the metadata format for dependencies and other info. > > 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. I agree. Even more for projects with longer release cycles ( tomcat, ant, etc ), where betas and milestones are likely to stay around. > > 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. +1 again. I would add "usage and project policies/needs". If a major issue is discovered in a jar - I see a good reason to remove it and add a fixed version. A build failing is better in this case. > > 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 I think projects and repo should use a similar layout. If the documentations and project tools expect "ant.jar", and the repository gets ant-1.5.1.jar - then we have a small problem. ( there are pieces of code that add a certain jar or check for a particular name - all manifests with class-path are vulnerable ). Again - it's maven choice on what to do with its repo, I'm talking only about the ASF repo - and I think it should match with the project layout. If a consensus is reached on a particular naming - it would be very important to get it adopted by projects. But having a projects files in the ASF repo in sync with the project needs ( and code ) is more important. > 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. Quite the contrary - I think the projects know a bit better how their jars should be used. Again - code and build files that checks for a particular name is common ( and I don't see anything very wrong with it ). I strongly disagree with the statement that the third party distributor knows better than the original project authors how the project files should be layout. Sometimes redistributors thay need to make adjustments to match their layout - but that allways causes some pain, and the only way to get around is to have the original project support the layout ( for example - apache httpd and RedHat ). > > 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. No, but they do the work that is used by the users :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
On Fri, 28 Feb 2003 [EMAIL PROTECTED] wrote: > > > 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. Of course. The "maven" word comes up quite frequently on this thread :-) The issue is that the repository on daedalus will affect all apache projects that choose to use it ( to download and upload files ). I don't think distribution of a project's files from apache repository should be handled by anyone other than the project itself. The release manager should sign the files, make the announce about the release and so on. If Maven or other projects want to rip the official distribution apart, rename jar files, etc - in its repository - that's fine. For non-apache jars ( if we get an agreement on including them in the apache repository ) - IMHO distributing them as close as possible to the original layout is the best choice ( assuming the download tools can handle that ). > > +1 on the oversight committee for non-apache jars. > Believe me, the oversight bit is the hardest part. I agree. It must involve the board and the lawyers. > > 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? I think we are still discussing the oversight of the daedalus repository, and who should have the responsibility. I think jakarta PMC should be responsible for the files in the jakarta* directory in the repository. Other projects and peole can of course "oversee" in the sense of checking the files and pointing out problems (like "a project can't run without a non-approved dependency" ) - but I don't think they should make release decisions for jakarta projects. ( same for ant and all other apache projects - jakarta is just an example ) Costin - 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: [proposal] daedalus jar repository (was: primary distribution location)
[EMAIL PROTECTED] wrote: You know that ASF jars aren't 'freely' distributable, right? The license specifies some conditions on binary distribution. All the open source sub-communities have various conventions about how to manage the legal tangles around IPR. We, the foundation, currently have a adopted a framework that strives to assure that commercial interests have a low barrier to adoption - for our stuff. Achieving that requires that we take care that there is the right level of compatibility between the licenses of the various things we depend upon and distributed. I believe we ended up in this place because a number of us had personal experiences where systems we were trying to build could not be deployed without resolving these issues. We used the software, we needed these problems resolved. Other communities have made the choice to leave the issue of assuring compatibility to the users. Some users can resolve these issues by ignoring them, or taking a wait and see attitude, or arguing that they are too low profile to get noticed, or taking shelter inside a different bubble where the rules are strictly enforced (like the gnu bubble, or the microsoft bubble), or getting a team of lawyers to negotiate the one off licenses required. Sourceforge, CPAN, and public libraries take this - 'not my problem' approach. Are you arguing that the ASF should stop striving to keep licenses compatible? - ben - 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 (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 location)
--On Wednesday, February 26, 2003 6:15 PM +0100 Leo Simons <[EMAIL PROTECTED]> wrote: my take: keep everything. Again, policy should be the same as for the contents of /dist/. I dunno if there is an asf-wide policy for that...looking at http://www.apache.org/dist/httpd/old/, those guys don't share my view :D The ASF policy (such as there can be one) is here: http://www.apache.org/dev/mirrors.html HTTP Server hasn't yet rearranged their directory structure. That's mainly because I don't think it's done a release since the policy was agreed-upon. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: RE: [proposal] daedalus jar repository (was: primary distribution location)]
My opinion is that the board should take this suggestion very seriously. Original Message Subject: RE: [proposal] daedalus jar repository (was: primary distribution location) Date: Wed, 26 Feb 2003 14:54:20 -0500 From: "Noel J. Bergman" <[EMAIL PROTECTED]> Reply-To: community@apache.org To: CC: <[EMAIL PROTECTED]> My proposal is that Dion Gillard be asked to chair a repository committee. He is the most familar with the issues, he works with a lot of the Java technologies (Tomcat, Ant, Maven, James, Jetspeed, Struts, Turbine), and although he is a Maven fan, he is agnostic in terms of ensuring that all build technologies would be supported. As for where the committee is located, personally I don't care if it were under Ant, Maven, Jakarta, Infrastructure, or the Blue Moon. But based upon the personality clashes from this morning, and knowing Dion quite well, I propose that Dw's earlier suggestion of infrastructure be followed, and this be an infrastructure sub-project. I just gave Dion a heads-up that I was going to propose this, and he is amenable if that is what people want to do. --- 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)
> you get an ok on [sharing and centralizing the managment > of ASF-acceptable third party jars] from the board and/or > the infrastructure team, and consensus across the community, > and I'll be absolutely 100% behind any such plan. I can't see how it would be acceptable to anyone without all of those. :-) As for your comments regarding the quotes from Dion, he expressed himself, you've replied, and I'm going to stay out of the middle. He can reply if/as he wishes. > you mean not "the guiding principles", but "the authoritive statement". At the point where there is a repository oversight committee under the infrastructure team, I mean guiding principles. The infrastructure team reports directly to the ASF President, and the ASF Board. So at that point, *I* don't have any need to refer to them as more than guiding principles. If the ASF President and Board want to make a stronger statement, that's up to them, but I'm not going to tie their hands with their own document. If we are all in agreement on the idea, then I think what ought to happen would be the formation of the group. People like Dion, yourself, and whomever else wants to be intimately involved in providing this service to the ASF at large. The details related to board approval of jars and licenses, tools, techniques, etc., can be worked out by the repository group (under a sunshine arrangement, of course). --- Noel - 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: you get an ok on that from the board and/or the infrastructure team, and consensus across the community, and I'll be absolutely 100% behind any such plan. scratch that, I'm in a "Just Do It" mood today. Just sent a message to the board (who are reading already anyway, but hey, some people like policy and procedure ;), watch for CC. cheers, - Leo - 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 wrote: As you have seen from some of our exchange and Costin's comments, there are 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. you get an ok on that from the board and/or the infrastructure team, and consensus across the community, and I'll be absolutely 100% behind any such plan. And having an apache only repository is almost useless; even apache uses non-apache code. uhm...no. I need a location where I can put avalon jars and the distribution version of jars used by gump, and I would really like to have this location mirrored into the existing maven @ ibiblio repo, so that it becomes real easy to control what avalon jars are available that way. It's not useless at all! The current 'daedalus' repository seems to be duplicating what's already been done in maven." the difference is in control, location and community. I want to be able to modify the jars in the avalon part of such a repository (control), the ASF wants the asf hardware to be the primary distribution channel for asf software (location), and I want such a repository to be usable and the de-facto standard across ant,maven,centipede,whatever (community). Technically, I'm trying to exactly keep the difference to zero, and have exactly zero thought on how to do it, but just use the existing practices. FWIW, Dion indicates that you are wrong about the "no" regarding JUnit licensing. the "no" is with regard to whether apache wants to get into redistributing JUnit, not with regard to whether it is okay to link to or provide as part of an asf project, or anything like that. IANAL. Like I said the first time :D Licensing policy is quite tricky and lots of things need to be done before the ASF should even consider setting up a centralized easily user-accessible distribution [of third party jars] But that's the whole point, Leo. :-) Given the confusion and effort related to the approved use of third party jars, I see that as a primary benefit of the repository, not even a secondary one. Especially from the standpoint of the Board (and projects) being able to verify that all third party jars have clean license. I'm not sure if you have any idea of how many hours and hours Dion has invested in going through the Maven repository, and its licensing. sure. I know how much I've invested in it so far, and I have only very little knowledge and very little accomplishment in the matter, so he must have invested lots more :D. This is precisely why I'm doing next to no thinking on my own, and just following his lead! By using the repository as the authoritative statement of what is acceptable, projects have both a known authority and a known procedure for securing approval to use another jar. This provides further protection to the ASF by ensuring that not only does each PMC make a conscious decision to use a new jar, but that people who are familar with licensing on a regular basis also get a chance to vett new uses of third party code. you absolutely do not need a repository as an authoritative statement of what is acceptable. What you need for that is an authoritative statement. But yes, having a centralized repository of acceptable third party jars does add an extremely convenient procedure for securing approval of a particular jar. 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" And those would be the guiding principles used by the repository oversight committee to approve new contents. you mean not "the guiding principles", but "the authoritive statement". --- Look, I support the goal, but there's requirements to be satisfied. In order to place any non-asf created third-party jar on www.apache.org, I think we need at a minimum: 1) an ok from the board on providing redistribution of these third party jars* 2) authoritative** confirmation that the redistribution of any such jar under a specific license and/or copyright is in line with the ASL and the ASF licensing policy 3) authoritative** information on what requirements are placed on the redistribution of such a jar so that all relevant licenses and license policies are satisfied, 4) a mechanism for ensuring the satisfaction of these requirements 5) an ok (ie majority vote) from the community on this provision (though consensus would be nice) when (1)-(4) is satisfied you'll get my +1 on (5). I will also try and help out with satisfying (2)-(5) when (1) has been satisfied. I don't really care what process is used to get these requirments satisfied; a committee headed by Dion (sorry if I misspell here ;)) sounds just fine with me. But get (1) in place before spending too much energy on (2)-(5). Certainly, I'm not going to spend more time convincing anyon
Re: [proposal] daedalus jar repository (was: primary distribution location)
+1 Noel J. Bergman wrote: Costin, I agree with pretty much all of your particulars. To summarize, if I might: - the ASF repository shall contain ASF jars, which don't require oversight beyond the issuing PMC. - the ASF repository should contain shared third party jars for which the ASF has approved their use and distribution. - the ASF repository shall be mirrorable. Tools intended to work with the ASF repository should understand mirroring. [If not, they may select a specific mirror, but I don't believe that we want them to select the ASF repository as *the* location.] - multiple repositories are good things, and smart tools should deal with multiple repositories. - a smart tool might present a click-through license. The repository should permit this as necessary. [netbeans.org does this, by the way] - ASF projects, however, must not rely upon unapproved third party jar files in such manner as to compromise their license integrity, even if that jar is not distributed via the ASF repository. If this becomes an apache-wide policy, I strongly disagree that Maven can decide for apache policies. I have proposed that the repository be a build-tool-neutral infrastructure sub-project, since Dw expressed the willingness to have it under infrastructure. I propose that Dion Gillard initially lead that effort, taking advantage of his experience in the area. I don't believe that Dion is a "Maven will define for all" kind of guy. Yes, the repository effects all projects, but to me that just means that each PMC that cares to should represent itself, not that we need to have dozens of people working this out. --- 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)
Costin, I agree with pretty much all of your particulars. To summarize, if I might: - the ASF repository shall contain ASF jars, which don't require oversight beyond the issuing PMC. - the ASF repository should contain shared third party jars for which the ASF has approved their use and distribution. - the ASF repository shall be mirrorable. Tools intended to work with the ASF repository should understand mirroring. [If not, they may select a specific mirror, but I don't believe that we want them to select the ASF repository as *the* location.] - multiple repositories are good things, and smart tools should deal with multiple repositories. - a smart tool might present a click-through license. The repository should permit this as necessary. [netbeans.org does this, by the way] - ASF projects, however, must not rely upon unapproved third party jar files in such manner as to compromise their license integrity, even if that jar is not distributed via the ASF repository. > If this becomes an apache-wide policy, I strongly disagree > that Maven can decide for apache policies. I have proposed that the repository be a build-tool-neutral infrastructure sub-project, since Dw expressed the willingness to have it under infrastructure. I propose that Dion Gillard initially lead that effort, taking advantage of his experience in the area. I don't believe that Dion is a "Maven will define for all" kind of guy. Yes, the repository effects all projects, but to me that just means that each PMC that cares to should represent itself, not that we need to have dozens of people working this out. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
On Wed, 2003-02-26 at 16:28, Costin Manolache wrote: > On Wed, 26 Feb 2003, Noel J. Bergman wrote: > > 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. > > 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. If you want to make an Apache only repository, I don't mind at all. I believe you're wasting your time but I'm not going to spend any time trying to convince anyone. As long as I can put Apache JARs in the Ibiblio repository by moving them myself, or rsyncing them from here doesn't much matter. But in very short order I doubt anyone is going to waste any time making another repository once we get the admin tool and artifact moderation mechanism working. Once we get our resolution sorted out, maven.apache.org setup and 1.0 release I believe there will be something of a landslide and mass migration to Maven. I would predict that what happens here in isolation at Apache will be eclipsed by the desire of the general Maven user base. > 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. I have zero desire to oversee a repository here. I'm focusing on Ibiblio. Dion may want to lend a hand but I'm working on the tools that will allow any Java project anywhere to participate in the structuring of a repository that all Java projects can use, not just one's at Apache. I have no desire to argue or sway anyone here. > > > > Licensing policy is quite tricky and lots of things need to be done > > > before the ASF should even consider setting up a centralized easily > > > user-accessible distribution [of third party jars] > > > > But that's the whole point, Leo. :-) Given the confusion and effort > > related to the approved use of third party jars, I see that as a primary > > benefit of the repository, not even a secondary one. Especially from the > > standpoint of the Board (and projects) being able to verify that all third > > party jars have clean license. I'm not sure if you have any idea of how > > many hours and hours Dion has invested in going through the Maven > > repository, and its licensing. > > +1 - with the same mention that multiple repositories should be supported > by the tools, and apache should contain only apache software and what > is fully redistributable ( and aproved by the board ). I'm +1 as long as there is no rub pushing the whole lot to ibiblio. > > > By using the repository as the authoritative statement of what is > > acceptable, projects have both a known authority and a known procedure for > > securing approval to use another jar. This provides further protection to > > +1 > > > > And those would be the guiding principles used by the repository oversight > > committee to approve new contents. By centralizing it, if there are any > > +1 on the oversight committee for non-apache jars. > 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. > > Costin > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Ant PMC Issue (was: RE: [proposal] daedalus jar repository(was: primary distribution location))
Noel J. Bergman wrote: If the fundamental philosophy of the ASF is Community First, how do you feel that you contributed to that today? Quite simple: the ASF has the honour to host mr. Van Zyl's project on its servers. In return, they get flamed with FUD and ownership. Bah. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
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. 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. > should reply in proxy, so I will quote him: "People *must* know that the > maven team decided a whole lot of things about repositories. And having an > apache only repository is almost useless; even apache uses non-apache code. > The current 'daedalus' repository seems to be duplicating what's already > been done in maven." 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. 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. 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. > > Licensing policy is quite tricky and lots of things need to be done > > before the ASF should even consider setting up a centralized easily > > user-accessible distribution [of third party jars] > > But that's the whole point, Leo. :-) Given the confusion and effort > related to the approved use of third party jars, I see that as a primary > benefit of the repository, not even a secondary one. Especially from the > standpoint of the Board (and projects) being able to verify that all third > party jars have clean license. I'm not sure if you have any idea of how > many hours and hours Dion has invested in going through the Maven > repository, and its licensing. +1 - with the same mention that multiple repositories should be supported by the tools, and apache should contain only apache software and what is fully redistributable ( and aproved by the board ). > By using the repository as the authoritative statement of what is > acceptable, projects have both a known authority and a known procedure for > securing approval to use another jar. This provides further protection to +1 > And those would be the guiding principles used by the repository oversight > committee to approve new contents. By centralizing it, if there are any +1 on the oversight committee for non-apache jars. 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. Costin - 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 distribution location))
Jason van Zyl wrote: What irks the hell out of me is people like Nicola constantly whining about being excluded. Excluded from what? I find this message quite interesting in this context: http://www.mail-archive.com/general@jakarta.apache.org/msg07046.html Expecially your signature. -- 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]
RE: Ant PMC Issue (was: RE: [proposal] daedalus jar repository(was: primary distribution location))
Jason, > > why aren't Ant and Maven two related projects under a single PMC? > Well, because when Ant formed they had no desire to be grouped with > Maven Based upon your attitude today towards Greg, Sam, Nicola (who isn't even here, but was accused of whining), etc., I can't say that I blame them. Jason, I don't know you. I barely know your projects. So why would you want this outburst to be the thing I know the most about you? I'm sorry, Jason, and perhaps I'm not being fair but it seems that you are having an apoplectic fit at very idea of a PMC that oversees build process related projects. This was confusing to me, so I asked. What I am told is that you are concerned about being stuck with Centipede and Gump, for which you have already indicated personal disdain. Well, fine. I don't use either and won't put forth a value judgment, but if they suck they suck. Sam's ego will hold up. Nick seems an affable enough person from the few messages I've read from him. The glaringly obvious point to me is that Ant and Maven have synergy. Dion says, "we very much have synergy with ant, and rely heavily on them." If a hypothetical build process top level project of Ant and Maven were to replace Centipede and Gump with code that serves the ASF's needs and sucks less, who cares? As has often been said, the important thing is the Community, not the code. > If there is no emergent cooperation what is the point in forcing > collaboration? It's just not productive and how does that serve > the purpose of making better software? If the fundamental philosophy of the ASF is Community First, how do you feel that you contributed to that today? How do your comments further the purpose of making better software, the ASF Way? --- 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 Wed, 26 Feb 2003, Nick Chalko wrote: So I am for /projectname/[subproject]/[version]/file[-version].jar That leo suggested. I'm not sure that's what Leo suggested. The [] imply optional. But my main point is Centipede will adapt to whatever Apache uses. Having the version in both dir and jar seems a bit too much. The common practice in many projects ( at least in jakarta ) is to use jakarta-SUBPROJECT-version for packages and dirs in the dist. Changing that would be quite painfull - and require a lot of work. Getting the version number in the jars names is not easy either - it require changing build files, docs, scripts, maybe manifests. But it can be done, if it is clear that this is indeed an informed choice. Having one format in the repo and one in the official releases is IMO the worst choice. A download tool that is flexible and can support both formats - and eventually a descriptor that maps the type of names - is easier and require less work than changing all projects. I agree that it is easier to have the download tool match what is in use. As long as ther version is the project and version are noted somewhere. I am fine. 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: [proposal] daedalus jar repository (was: primary distribution location)
On Wed, 26 Feb 2003, Nick Chalko wrote: > So I am for > /projectname/[subproject]/[version]/file[-version].jar > > That leo suggested. I'm not sure that's what Leo suggested. Having the version in both dir and jar seems a bit too much. The common practice in many projects ( at least in jakarta ) is to use jakarta-SUBPROJECT-version for packages and dirs in the dist. Changing that would be quite painfull - and require a lot of work. Getting the version number in the jars names is not easy either - it require changing build files, docs, scripts, maybe manifests. But it can be done, if it is clear that this is indeed an informed choice. Having one format in the repo and one in the official releases is IMO the worst choice. A download tool that is flexible and can support both formats - and eventually a descriptor that maps the type of names - is easier and require less work than changing all projects. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
Leo, As you have seen from some of our exchange and Costin's comments, there are 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. For what it is worth, I discussed this with Dion Gillard yesterday. He indicated that he didn't have time to respond on the thread, but that I should reply in proxy, so I will quote him: "People *must* know that the maven team decided a whole lot of things about repositories. And having an apache only repository is almost useless; even apache uses non-apache code. The current 'daedalus' repository seems to be duplicating what's already been done in maven." I don't know that I entirely agree with him about the repository duplicating what is done by Maven, because I do believe that the ASF would want to have oversight on what it does accept for use, and the ibiblio repository would be a mirror or a superset of what the ASF site declares as official (for the ASF). Dion does agree, as I think should everyone, with your rules for publication: a) policy b) desire c) approval for the ASF to redistribute Not sure that (a) and (c) aren't redundant, but that depends upon how you define policy. FWIW, Dion indicates that you are wrong about the "no" regarding JUnit licensing. > Licensing policy is quite tricky and lots of things need to be done > before the ASF should even consider setting up a centralized easily > user-accessible distribution [of third party jars] But that's the whole point, Leo. :-) Given the confusion and effort related to the approved use of third party jars, I see that as a primary benefit of the repository, not even a secondary one. Especially from the standpoint of the Board (and projects) being able to verify that all third party jars have clean license. I'm not sure if you have any idea of how many hours and hours Dion has invested in going through the Maven repository, and its licensing. By using the repository as the authoritative statement of what is acceptable, projects have both a known authority and a known procedure for securing approval to use another jar. This provides further protection to the ASF by ensuring that not only does each PMC make a conscious decision to use a new jar, but that people who are familar with licensing on a regular basis also get a chance to vett new uses of third party code. > 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" And those would be the guiding principles used by the repository oversight committee to approve new contents. By centralizing it, if there are any issues that need to go back to the Board, there is a controlled mechanism so that it doesn't become a lot of noise at their level. And as the approved list grows, projects can spend less time worrying over licening, and just use approved jars. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
My proposal is that Dion Gillard be asked to chair a repository committee. He is the most familar with the issues, he works with a lot of the Java technologies (Tomcat, Ant, Maven, James, Jetspeed, Struts, Turbine), and although he is a Maven fan, he is agnostic in terms of ensuring that all build technologies would be supported. As for where the committee is located, personally I don't care if it were under Ant, Maven, Jakarta, Infrastructure, or the Blue Moon. But based upon the personality clashes from this morning, and knowing Dion quite well, I propose that Dw's earlier suggestion of infrastructure be followed, and this be an infrastructure sub-project. I just gave Dion a heads-up that I was going to propose this, and he is amenable if that is what people want to do. --- Noel - 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: do that, but the big disadvantage with deviating from the existing maven/centipede/ruper practice is that it deviates from that practice, thus requiring work and reducing compatibility. If you feel like holding a vote, by all means feel free, I'll probably vote -1 for deviating from the existing format (unless you've got a good argument rather than preference; I share your preference but it is just that ;) Speaking for Centipede, the format of the repository is of little matter. Proabably only a day or two to update ruper. Since no one is use the Apache Jars Repository there is no campatability issue The important thing is making the structure is relatively stable, while allowing for growth. We need to apply sams thoughts on coping with change http://www.intertwingly.net/stories/2002/03/15/copingWithChange.html to this directory strucutre. So I am for /projectname/[subproject]/[version]/file[-version].jar That leo suggested. cheers, - Leo - 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)
Costin Manolache wrote: What policy should we use for removing older versions ( or we just keep everything ) ? my take: keep everything. Again, policy should be the same as for the contents of /dist/. I dunno if there is an asf-wide policy for that...looking at http://www.apache.org/dist/httpd/old/, those guys don't share my view :D What about a "at least 6 months and 2 versions back" ? quoting yourself, how about: "+1 for each project/PMC choosing what to publish/remove." And you and I can recommend to each project/PMC our respective preferred policy. If you feel like holding a vote, by all means feel free, I'll probably vote -1 for deviating from the existing format (unless you've got a good argument rather than preference; I share your preference but it is just that ;) There are few good arguments for both ways. yep. I think the best argument is "common practice", and that's something which can be measured to a degree. If we host external packages - some licenses prohibit modifications of the binary distribution ( I read this as "you can't rename jars"). I think anyone who uses or accepts a license that dictates filenames is silly, but that could be just me :D It also seems to be a very common practice - almost all projects I know use unversioned jars. you and I work on different projects I guess! If anyone feels like it, one could do actual statistical analysis on http://cvs.apache.org/~leosimons/jars-in-cvs/ though one would have to compensate for the smart projects which don't keep binaries in CVS... I would say this beats the argument on the maven practice ( that ruper is also supporting ). I see no reason why a download tool can't accomodate both. me neither, but it sounds like more work again ;) On the other side - the practice on .so library supports the versioned jars, as well as the ability to have all .jars in a single dir and use the manifest to select the right version. not to mention apt, rpm, CPAN, PEAR (ie CPAN 4 PHP), OpenBSD, ... I think a vote would be necesary - I'll probably propose it in the projects I participate in. Probably a global jakarta vote would also make sense - at least to gather what's the majority things and recommend it. I say go for it (though I hope everyone shares my opinion :D) Since I don't think there is an absolute "right" - I obviously preffer a majority decision, that would justify some pushing and work to get it adopted. uhuh. There's that word again, "work". A good scientist is a lazy scientist. Does that hold for programmers? (Are programmers scientists?) I say go for it though. Actually I just said it for the second time. Not lazy enough yet, me. cheers, - Leo, sometime-to-be-scientist, and planning to be a good one - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Wed, 26 Feb 2003, Leo Simons wrote: > >Should we use 2 different dirs for src and binary distribution ? Or maybe > >3 dirs ( src, bin, doc ) ? > > > based on current practice at http://www.ibiblio.org/maven, the answer to > both is "no". A quick > glance at the java projects @ http://www.apache.org/dist/ also seems to > result in a "no". The > most standard practice seems to be to append -src or -bin, resulting in > filenames of Well, the current practice at maven is one argument for "no", but its just one argument. The second argument is much better :-) > /dist/${project}/${subproject}/${version}/${package}-${version}-bin.${fomat} > /dist/${project}/${subproject}/${version}/${package}-${version}-src.${fomat} +1 then. > >Are "milestone" builds acceptable ? Should we get some weekly gump builds > >from HEAD into the repository ? > That's up to each project to decide I think. My opinion is that once you > provide a distribution of > a file, you need to keep providing it at the same URL for a timespan > close to eternity. This seems a > good argument to not place milestones or weeklies here. "up to each project" sounds fine. There are cases of long release cycles where milestones make sense. The main point for milestones and weeklies is to allow projects to use an intermediary between Gump ( HEAD of everything ) and "latest release" of everything ( that can be old ). There are many cases like commons-el/jasper or tomcat/modeler where this middle ground is better. +1 for each project/PMC choosing what to publish/remove. > >What policy should we use for removing older versions ( or we just keep > >everything ) ? > > > my take: keep everything. Again, policy should be the same as for the > contents of /dist/. I dunno > if there is an asf-wide policy for that...looking at > http://www.apache.org/dist/httpd/old/, those guys > don't share my view :D What about a "at least 6 months and 2 versions back" ? > >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. > >I would prefer the reverse ( versioned dirs / unversioned jars ) - but I > >can live with the reverse if it does have a "majority" support. > >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 ? > > > we could do that, but the big disadvantage with deviating from the > existing maven/centipede/ruper > practice is that it deviates from that practice, thus requiring work and > reducing compatibility. > If you > feel like holding a vote, by all means feel free, I'll probably vote -1 > for deviating from the existing > format (unless you've got a good argument rather than preference; I > share your preference but it > is just that ;) There are few good arguments for both ways. If we host external packages - some licenses prohibit modifications of the binary distribution ( I read this as "you can't rename jars"). It also seems to be a very common practice - almost all projects I know use unversioned jars. I would say this beats the argument on the maven practice ( that ruper is also supporting ). I see no reason why a download tool can't accomodate both. On the other side - the practice on .so library supports the versioned jars, as well as the ability to have all .jars in a single dir and use the manifest to select the right version. I think a vote would be necesary - I'll probably propose it in the projects I participate in. Probably a global jakarta vote would also make sense - at least to gather what's the majority things and recommend it. Since I don't think there is an absolute "right" - I obviously preffer a majority decision, that would justify some pushing and work to get it adopted. Costin - 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 Tue, 25 Feb 2003, Leo Simons wrote: files in /dist/java-repository besides perhaps HEADER.html and README.htmls... Few simple questions: Should we use 2 different dirs for src and binary distribution ? Or maybe 3 dirs ( src, bin, doc ) ? based on current practice at http://www.ibiblio.org/maven, the answer to both is "no". A quick glance at the java projects @ http://www.apache.org/dist/ also seems to result in a "no". The most standard practice seems to be to append -src or -bin, resulting in filenames of /dist/${project}/${subproject}/${version}/${package}-${version}-bin.${fomat} /dist/${project}/${subproject}/${version}/${package}-${version}-src.${fomat} where ${subproject} can be ".", and the /${version} part in the path is often ommitted. Are "milestone" builds acceptable ? Should we get some weekly gump builds from HEAD into the repository ? That's up to each project to decide I think. My opinion is that once you provide a distribution of a file, you need to keep providing it at the same URL for a timespan close to eternity. This seems a good argument to not place milestones or weeklies here. What policy should we use for removing older versions ( or we just keep everything ) ? my take: keep everything. Again, policy should be the same as for the contents of /dist/. I dunno if there is an asf-wide policy for that...looking at http://www.apache.org/dist/httpd/old/, those guys don't share my view :D 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. I would prefer the reverse ( versioned dirs / unversioned jars ) - but I can live with the reverse if it does have a "majority" support. 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 ? we could do that, but the big disadvantage with deviating from the existing maven/centipede/ruper practice is that it deviates from that practice, thus requiring work and reducing compatibility. If you feel like holding a vote, by all means feel free, I'll probably vote -1 for deviating from the existing format (unless you've got a good argument rather than preference; I share your preference but it is just that ;) cheers, - Leo - 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 distribution location))
On Wed, 2003-02-26 at 10:55, Noel J. Bergman wrote: > > I wouldn't phrase it quite that way, but as long as the question is on the > table: why aren't Ant and Maven two related projects under a single PMC? Well, because when Ant formed they had no desire to be grouped with Maven which is perfectly fine. Why isn't it perfectly fine? And when we made our proposal we wanted to be separate. What irks the hell out of me is people like Nicola constantly whining about being excluded. Excluded from what? We didn't cut of hands and throw you in a closet. All those projects can do whatever they want? If there is no emergent cooperation what is the point in forcing collaboration? It's just not productive and how does that serve the purpose of making better software? > And what is underlying Jason's emotional response to that idea? > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- 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: Ant PMC Issue (was: RE: [proposal] daedalus jar repository (was: primary distribution location))
Conor, I could be wrong, but I don't believe that Dion was refering to the repository; rather he was commenting in response to my aside regarding Ant and Maven: On Wed, Feb 26, 2003 at 09:48:42PM +1100, [EMAIL PROTECTED] wrote: > 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. Jason's reply to Greg Stein, where Greg quoted the entire antecedent, and Jason just quoted my aside, lends further weight to my belief that the discussion was about the projects and not the repository. I understand some of the reasons why they aren't one project, but they are clearly in the same space. I've heard Maven refered to as "the Ant v2 that will never happen", indicating a perception of some people as to how the projects relate. That naturally raises, at least in the mind of users, the question of cooperation and co-development of those two related projects. > Is there an Ant PMC issue here? I wouldn't phrase it quite that way, but as long as the question is on the table: why aren't Ant and Maven two related projects under a single PMC? And what is underlying Jason's emotional response to that idea? --- Noel - 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 distribution location))
[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 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? Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 location)
On Tue, 25 Feb 2003, Noel J. Bergman wrote: > > all PMCs whose committers 'commit' to the repository should maintain > > some oversight. > > Infrastructure hasn't considered that a good model for the Wiki, and I don't > know that it would work any better for the repository. Someone needs to > take responsibility for the oversight. Ok. I think jakarta PMC should have the oversight over all directories starting with "jakarta". Same for the other PMCs. Directories that don't start with a PMC name should be under the oversight of infrastructure or board or any other entitiy that understands the licensing policy of apache. Is this acceptable ? > Yes, that does. But I am expecting that people will want common things like > JUnit, which I understand to be acceptable so long as the IBM license is > there. Once the binary distinction of ASF v non-ASF is dropped, then the > simplicity of it being OK because it is all ASF-licensed code turns into the > policing scenario that Maven is currently practicing, through Dion Gillard. I think all non-apache jars should have the oversight of board or some other entity that can make an authoritative decision on accepting/rejecting packages ( or at least licenses ). > But using the repository to hold third party jars for which the ASF has > specifically ascertained appropriate license rights exist seems to be what > gives us the most bang, because it is the third party libraries that are the > most potentially time consuming and "risky". Rather than each project have > to deal with each third party jar, using the repository for that purpose > would both share the burden of acquiring suitable license rights, and > ensuring that they were acquired. +1 > So, yes, the ASF-only distinction simplifies repository policing, but using > it as the central location for authorized third party jars simplifies > overall policing of third party license issues for the ASF as a whole. As long as the policing is done by the right people. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Tue, 25 Feb 2003, Leo Simons wrote: > files in /dist/java-repository besides perhaps HEADER.html and > README.htmls... Few simple questions: Should we use 2 different dirs for src and binary distribution ? Or maybe 3 dirs ( src, bin, doc ) ? Are "milestone" builds acceptable ? Should we get some weekly gump builds from HEAD into the repository ? What policy should we use for removing older versions ( or we just keep everything ) ? 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. I would prefer the reverse ( versioned dirs / unversioned jars ) - but I can live with the reverse if it does have a "majority" support. 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 ? This is my biggest issue with the repository conventions. Costin - 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 wrote: all PMCs whose committers 'commit' to the repository should maintain some oversight. Infrastructure hasn't considered that a good model for the Wiki, and I don't know that it would work any better for the repository. Someone needs to take responsibility for the oversight. they _have_ accepted this as a model for distribution management. The wiki is a very different topic. The www.apache.org/dist/ setup is something 'conventional', with a filesystem and permission management and SSH encryption and stuff. It is tried and tested, and perfectly secure (to the extend daedalus itself is secure). I'm not suggesting we place non-ASF jars online, which simplifies license issues rather by a large amount. Yes, that does. But I am expecting that people will want common things like JUnit, AIUI, there is currently a "no" on the ASF providing a redistribution point for things like JUnit in the style of a maven repository. At least not a definitive "yes". which I understand to be acceptable so long as the IBM license is there. IANAL, but I understand the same thing ;) Once the binary distinction of ASF v non-ASF is dropped, then the simplicity of it being OK because it is all ASF-licensed code turns into the policing scenario that Maven is currently practicing, through Dion Gillard. 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. But using the repository to hold third party jars for which the ASF has specifically ascertained appropriate license rights exist seems to be what gives us the most bang, because it is the third party libraries that are the most potentially time consuming and "risky". Rather than each project have to deal with each third party jar, using the repository for that purpose would both share the burden of acquiring suitable license rights, and ensuring that they were acquired. www.apache.org/dist is the authoritive place for distribution of apache software. It is _not_ currently intended for redistribution, authoritive or not, of "ASF-endorsed" or "ASF-acceptable" software. Quite binary, yes (ant it is not something I made up, but what I took away from comments from Dirk or someone else entitled to make "official" statements). Changing this setup is something to be done only very cautiously after consulting with the projects that mirror our stuff and answering lots of other questions. I can see the argument as to why we would want to do such a thing, but I think it is best to hold this off for at least a month or two even if we were to decide to do it. Slow & controlled evolution :D So, yes, the ASF-only distinction simplifies repository policing, but using it as the central location for authorized third party jars simplifies overall policing of third party license issues for the ASF as a whole. Licensing policy is quite tricky and lots of things need to be done before the ASF should even consider setting up a centralized easily user-accesible distribution point of materials not copyrighted by the ASF that can be called "authoritive" either by definition or default. 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?", "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?" and similar questions, so it is crystal clear what we can and cannot include and policy can be formulated and applied. Something like http://www.fsf.org/licenses/license-list.html#SoftwareLicenses for the ASL. Until these answers exist and are well-known throughout the community and relevant PMCs, we need to be as conservative as possible. Not sure if your project can distribute JUnit? Then don't, even if that makes life terribly inconvenient. Want to be sure? Ask the board to pour resources into getting answers. But we need to be sure before we act. I'm sure it is okay for the ASF to distribute jars from its own hardware based on its own sourcecode under its own license. Yes, binary, but it is the best first step and it solves a real need. cheers! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
> all PMCs whose committers 'commit' to the repository should maintain > some oversight. Infrastructure hasn't considered that a good model for the Wiki, and I don't know that it would work any better for the repository. Someone needs to take responsibility for the oversight. > I'm not suggesting we place non-ASF jars online, which > simplifies license issues rather by a large amount. Yes, that does. But I am expecting that people will want common things like JUnit, which I understand to be acceptable so long as the IBM license is there. Once the binary distinction of ASF v non-ASF is dropped, then the simplicity of it being OK because it is all ASF-licensed code turns into the policing scenario that Maven is currently practicing, through Dion Gillard. But using the repository to hold third party jars for which the ASF has specifically ascertained appropriate license rights exist seems to be what gives us the most bang, because it is the third party libraries that are the most potentially time consuming and "risky". Rather than each project have to deal with each third party jar, using the repository for that purpose would both share the burden of acquiring suitable license rights, and ensuring that they were acquired. So, yes, the ASF-only distinction simplifies repository policing, but using it as the central location for authorized third party jars simplifies overall policing of third party license issues for the ASF as a whole. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
well, I put in place a basic readme (actually, HEADER.html) and a sample package to indicate what I think would be the right organisation. I've basically copied over the layout used by the maven repo at ibiblio and explained how that works. This info should be sufficient for people to start adding symlinks (note: I recommend we put no files in /dist/java-repository besides perhaps HEADER.html and README.htmls... just symlinks) or writing scripts that do stuff like auto-nagging in case of license issues. cheers, - Leo - 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 wrote: Which PMC is going to oversee the repository? all PMCs whose committers 'commit' to the repository should maintain some oversight. I don't think there's an "official" precedent wrt how this works @ apache. It might be possible to get the infrastructure peeps to take on the additional burden of oversight, and maybe some peeps will want to join the infrastructure team to that effect. How are files going to be committed? anyone with an account on daedalus and part of the apcvs group can place/modify the files there using SCP/SSH. People who commit files will also have the option to chmod those committed files so that they are editable by a smaller group of people. Just like with the existing distribution setup. Who is going to ensure that the correct licenses are present and honored? IMO, the person who places a file in the repository should ensure the presence of a license, just as is currently the case with distributions (pattern emerging here ;). It is responsibility of the ASF as a whole to make sure the rest of the world honours its license. For the next few weeks at least, I'll be monitoring the repository closely. I hope/expect more people will step up to help out. once again, I'm not suggesting we place non-ASF jars online, which simplifies license issues rather by a large amount. I also think it should be easy enough to automate this somewhat: for each ${blah}.jar, check there's a corresponding ${blah}.LICENSE*, and e-mail the owner of the .jar if there isn't. Should be easy enough; my plan basically consists of following the maven+infrastructure lead on stuff like that, as that's where the expertise is atm. (Looking at http://www.ibiblio.org/maven/, they chose a pattern of ./${blah}/licenses/${blah}.license, which is easily machine-parsable.) 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? A joint operation between all projects that want to have their jars in the repo and all projects interested in maintaining such a repo for other reasons, and the infrastructure team. In effect, _exactly_ the same de-facto guidelines that apply to http://www.apache.org/dist/ apply to this repo as well. We've not needed things set in stone wrt distribution policy before (or do we? :D), so I wonder whether we should start to do so now. Let's go with the flow, shall we? [I won't even get into the question of why those two can't be related projects under a single PMC] lets not :D in summary, the answers to the questions you are posing should be the same for /dist/java-repository as for /dist/ as a whole. If those answers don't exist for /dist/, well if answers are needed they should be sought, but IMV that hasn't got too much to do with this specific repo and more with the general case. IE "Is there lack of policy with regard to www.apache.org/dist/?" is a different thread. And I guess Dirk is the one to give the answer to that one ;) cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
On Mon, 24 Feb 2003, Noel J. Bergman wrote: > > I thought this was for Apache only jars. Just a place for projects to > > place there "Released jars" as a compliment to the zip and qz > > distributions. So there should be no license issues. > > Well, I'm still waiting to hear about some of this. From Dion's review, he > mentioned to me that he believes that the ASF license requires each project > to include a copy of the license, with the project name, for each ASF > licensed jar that it uses. Not just one blanket copy for all. This can be easily validated by having a certain file name strucutre. Another reason to keep them separate is that occasionally a license file will -also- reference some other license (when some BSD/MIT piece of code was imported) or an acknowledgement. These are unique to a project. So one license file per granule makes sense. Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Sam Ruby wrote: - Leo (avalon pmc member acting sort-of on behalf of "the java peeps" using the lazy consensus model and the Just-Do-It-in-the-event-of-consensus mindset :D) I like that mindset. Note: the essence of lazy consensus is that such actions are immeditely rolled back if an issue is raised. I plan to do exactly that. heh. Me too :D cheers! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
> I thought this was for Apache only jars. Just a place for projects to > place there "Released jars" as a compliment to the zip and qz > distributions. So there should be no license issues. Well, I'm still waiting to hear about some of this. From Dion's review, he mentioned to me that he believes that the ASF license requires each project to include a copy of the license, with the project name, for each ASF licensed jar that it uses. Not just one blanket copy for all. This is caused by the decision of projects to change item #4, e.g.,: - http://www.ibiblio.org/maven/avalon-apps/licenses/license.html - http://www.ibiblio.org/maven/ant/licenses/license.html - http://cvs.apache.org/viewcvs/jakarta-james/LICENSE.txt?rev=1.1&content-type =text/vnd.viewcvs-markup As for the rest, I don't have anything to add to what Greg Stein said. I've questions about how this is going to work. Since someone is starting this process, I am hoping that they've through through some of the answers. And just judging from some of the replies thus far, I'm not at all sure that everyone has the same ideas about what is going to happen with this repository. --- Noel - 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 wrote: Note: the essence of lazy consensus is that such actions are immeditely rolled back if an issue is raised. I plan to do exactly that. I assume that you mean roll it back if an issue is raised, because obviously you wouldn't have put it up if you had an objection. :-) Which PMC is going to oversee the repository? How are files going to be committed? Who is going to ensure that the correct licenses are present and honored? I thought this was for Apache only jars. Just a place for projects to place there "Released jars" as a compliment to the zip and qz distributions. So there should be no license issues. Should be relative low commit levels, if the nightly stay with gump. I would suppose that since this is cross project the Jakarta PMC will have to oversee it. -- 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)
On Mon, 2003-02-24 at 19:13, Noel J. Bergman wrote: > > Note: the essence of lazy consensus is that such actions > > are immeditely rolled back if an issue is raised. I plan > > to do exactly that. > > I assume that you mean roll it back if an issue is raised, because obviously > you wouldn't have put it up if you had an objection. :-) > > Which PMC is going to oversee the repository? How are files going to be > committed? Who is going to ensure that the correct licenses are present and > honored? You'll want to post something to maven-dev. Dion has this worked out as he went through every last artifact in the repository. There's a file with info about the license and all that jazz. The artifacts that are not directly uploaded to the central repository will get verified before getting kicked into the repository proper. > 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? If apache projects dump their artifacts into a directory I'll get setup what needs to be done on the ibiblio side. > [I won't even get into the question of why those two can't be related > projects under a single PMC] > > --- Noel > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [proposal] daedalus jar repository (was: primary distribution location)
> Note: the essence of lazy consensus is that such actions > are immeditely rolled back if an issue is raised. I plan > to do exactly that. I assume that you mean roll it back if an issue is raised, because obviously you wouldn't have put it up if you had an objection. :-) Which PMC is going to oversee the repository? How are files going to be committed? Who is going to ensure that the correct licenses are present and honored? 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] --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Mon, 24 Feb 2003, Leo Simons wrote: > Leo Simons wrote: > > > Normally, I'd just ask the infrastructure peeps to > > > > umask 002 > > mkdir /www/www.apache.org/dist/java-repository > > chown :apcvs /www/www.apache.org/dist/java-repository > > > > and get things started, but given the unusual (well, maybe not ;) > > amount of controversy > > okay, so it looks like controversy is actuallly just perceived > controversy, just a reaction or two, and all positive. Root, could you > invoke your infinite power and execute the above commands on the > daedalus machine? Looks like Sam Ruby did this about a half-hour ago. Brian - 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: Leo Simons wrote: Normally, I'd just ask the infrastructure peeps to umask 002 mkdir /www/www.apache.org/dist/java-repository chown :apcvs /www/www.apache.org/dist/java-repository and get things started, but given the unusual (well, maybe not ;) amount of controversy okay, so it looks like controversy is actuallly just perceived controversy, just a reaction or two, and all positive. Root, could you invoke your infinite power and execute the above commands on the daedalus machine? It doesn't look like it took much power. Any ASF member could do it. I'm an ASF member. Done. thanks & cheers, - Leo (avalon pmc member acting sort-of on behalf of "the java peeps" using the lazy consensus model and the Just-Do-It-in-the-event-of-consensus mindset :D) I like that mindset. Note: the essence of lazy consensus is that such actions are immeditely rolled back if an issue is raised. I plan to do exactly that. - Sam Ruby - 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: Normally, I'd just ask the infrastructure peeps to umask 002 mkdir /www/www.apache.org/dist/java-repository chown :apcvs /www/www.apache.org/dist/java-repository and get things started, but given the unusual (well, maybe not ;) amount of controversy okay, so it looks like controversy is actuallly just perceived controversy, just a reaction or two, and all positive. Root, could you invoke your infinite power and execute the above commands on the daedalus machine? thanks & cheers, - Leo (avalon pmc member acting sort-of on behalf of "the java peeps" using the lazy consensus model and the Just-Do-It-in-the-event-of-consensus mindset :D) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Fri, 21 Feb 2003, Conor MacNeill wrote: > Brian Behlendorf wrote: > > > > +1. I see nothing wrong with the plan. Hopefully Ant can be made smart > > enough to pull the jars down from mirrors, too. > > > > Patches always welcome, Brian :-) The mirror CGI script should be able to handle this fairly easily. It could be adapted, for example, to send an HTTP redirect to an appropriate mirror when a request for http://www.apache.org/dyn/go.cgi/java-respistory/dist/file.jar is received. Joshua. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Brian Behlendorf wrote: +1. I see nothing wrong with the plan. Hopefully Ant can be made smart enough to pull the jars down from mirrors, too. Patches always welcome, Brian :-) Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Thu, 20 Feb 2003, Leo Simons wrote: > Based on the above, I suggest we create such a machine-readable > repository @ > daedalus.apache.org:/www/www.apache.org/dist/java-repository +1. I see nothing wrong with the plan. Hopefully Ant can be made smart enough to pull the jars down from mirrors, too. Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]