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)
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)
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)
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)
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)
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)
--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]
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 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)
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 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 participation from all build projects ( who want to
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)
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. ducking 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)
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. ducking 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]
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: 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: [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: [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)
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)
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, 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)
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)
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)
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)
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 anyone that
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)
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]
[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: community@apache.org 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)
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)
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)
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)
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)
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)
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)
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)
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 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]
