Re: [proposal] daedalus jar repository
On Mon, Feb 24, 2003 at 04:39:21PM -0800, Nick Chalko 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. If we choose to distribute non-ASF jars, then they should be clearly delineated from the ASF-owned jars. Obviously the ASF jars would all fall under our license. For any non-ASF jars, then the repository *MUST* have a clear license that demonstrates we are allowed to perform this (re)distribution. The Sun license is particularly notorious in this regard. > 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. You're thinking at the wrong level :-). Apache Jakarta is *one* project, with numerous sub-projects. But the words "cross project" still holds. I suspect that Ant, Avalon, James, etc will all want to distribute jars from the repository. Each of those PMCs will (nominally) have some oversight responsibilities. To be honest, I don't know what the most effective arrangement would be. I could easily see the infrastructure team being responsible. Each project releases their code to www.apache.org/dist/PROJECT/, and the infrastructure guys simply index that code a bit differently thru the central repos. *shrug* There is still some thinking to happen, I believe :-) (but pending a "real" solution, it would be pretty easy to just drop a bunch o' jars somewhere; but long term there will need to be solutions about the licenses, responsibility, versioning, etc etc) Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
On Mon, 24 Feb 2003, Greg Stein wrote: > To be honest, I don't know what the most effective arrangement would be. I > could easily see the infrastructure team being responsible. Each project > releases their code to www.apache.org/dist/PROJECT/, and the infrastructure > guys simply index that code a bit differently thru the central repos. The infrastructure folks would propably be quite happy to do this; provided that there is enough metadata to 'know' what is required; where the license is, who is the 'owner' of the jar etc, etc - i.e. do automated validation; and email a human when something is fishy (followed by semi automatic wacking/disabling if not taken care off in a resonable period of time). Some of the jar-dependencies and ant-dependency resolver which has been floating around in the XML world recently has metadata placeholders which would be an excepelent fit for that. Dw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
On Thu, Feb 27, 2003 at 10:12:35AM +1100, [EMAIL PROTECTED] wrote: >... > > sourcecode under its own license. Yes, binary, but it is the best first > > step and it solves a real need. > > Just to play devils advocate, what is that need, Given that there current > is a repository distributing ASF binaries with their license. > > This is not a facetious comment, but a desire to explore what the need is > for an ASF-blessed repository. The ASF doesn't "need" to have a repository. But it cannot operate or condone a repository that has or allows license violations. The ASF is primarily concerned with the original, authoritative distribution of its code. For proper authenticity, security, mirroring, etc, that distribution has a set of requirements and policy which has been defined by the infrastructure team. Beyond the original distribution, then it's all gravy. What facilities do we want to provide our users and downstream developers? How can we simplify their lives? Ted points out that it is reasonable to state that the ASF is creating problems (classpath and whatnot), so maybe you could even say we "must" create a repos simply as a way to help recover from the mess that we have made. *shrug* It does seem like people are narrowing in on some proposals, designs, etc. I might suggest it is about time to Wiki-ize the current thoughts so that you have something concrete to reference in further mailing list discussion. And to iterate on or to provide some alternatives. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
Greg Stein <[EMAIL PROTECTED]> wrote on 27/02/2003 11:33:28 AM: > On Thu, Feb 27, 2003 at 10:12:35AM +1100, [EMAIL PROTECTED] wrote: > >... > > > sourcecode under its own license. Yes, binary, but it is the best first > > > step and it solves a real need. > > > > Just to play devils advocate, what is that need, Given that there current > > is a repository distributing ASF binaries with their license. > > > > This is not a facetious comment, but a desire to explore what the need is > > for an ASF-blessed repository. > > The ASF doesn't "need" to have a repository. But it cannot operate or > condone a repository that has or allows license violations. Sure. I don't think anyone was suggesting that such a repository be created. > The ASF is primarily concerned with the original, authoritative distribution > of its code. For proper authenticity, security, mirroring, etc, that > distribution has a set of requirements and policy which has been defined by > the infrastructure team. The current 'distributions' are mainly in zipped source or binary form, right? Is there a precedent for non-zipped binaries? > Beyond the original distribution, then it's all gravy. What facilities do we > want to provide our users and downstream developers? How can we simplify > their lives? Ted points out that it is reasonable to state that the ASF is > creating problems (classpath and whatnot), so maybe you could even say we > "must" create a repos simply as a way to help recover from the mess that we > have made. *shrug* > > > It does seem like people are narrowing in on some proposals, designs, etc. I > might suggest it is about time to Wiki-ize the current thoughts so that you > have something concrete to reference in further mailing list discussion. And > to iterate on or to provide some alternatives. Sounds like a plan. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
Noel J. Bergman wrote: Nick, As long as you want to start with first principles ... project/[subproject]/version/(jar|zip|gz|docs|liscenses) is very good. How much should be encoded in a URI, and how much in data associated with the URI? You seem to be trying to encode all of the data into the URI naming space. Why not have a single URI for the target, and then trigger behavior based upon the content? That would seem more extensible and less fragile. This would also unify with Costin's thoughts regarding tool-neutral standards for the repository and project descriptors. The URI tells the repository what you want, and it responds with the information known about it, such as the locations of its parts, dependency information, build instructions, etc. The URI could encode optional filter information about what we want in the response. Depending upon whether the resource were dynamic or static, the filter might or might not be honored. Seems to me that some of the prior art associated with JNLP should be brought into the picture, as well as everything that Maven has learned about repositories. And REST in terms of the web interaction. Also, shouldn't URIs also support movement of the resource, e.g., when a sub-project moves from underneath a project? For that matter, is the project hierarchy really useful in the URI, or just a unique name? Thoughts? Your approach seems very powerfull, I like it. I was trying for a "Valid" repositry being just a filesystem. I think we can add the rest later as optionl support elements. A filesystem only approach lets other people build "compatible" repositories without tools or keeping a catalog.xml or whatever uptodate. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nick Chalko Show me the code. Centipede Ant + autodownloadable build plugins + needed jars autodownload. http://krysalis.org/centipede - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
As an aside, one of the issues we had when coming up with Maven's repository format, is that often artifacts (jars, wars, ears etc), willget left on the filesystem outside of a repository. Think rpms for example. Having a file encode --.type has been very useful for us. Yes, it's often different from what the project creates and distributes, but I (and others) have been bitten bycommons-logging.jar, struts.jar, junit.jar so many times, that seeing log4j-1.2.5.jar is a godsend.--dIon Gillard, Multitask ConsultingBlog: http://www.freeroller.net/page/dion/WeblogWork: http://www.multitask.com.au-Nick Chalko <[EMAIL PROTECTED]> wrote: -To: community@apache.orgFrom: Nick Chalko <[EMAIL PROTECTED]>Date: 03/01/2003 06:54AMSubject: Re: [proposal] daedalus jar repositoryNoel J. Bergman wrote:>Nick,>>As long as you want to start with first principles ...>> >>>project/[subproject]/version/(jar|zip|gz|docs|liscenses)>>is very good.>>How much should be encoded in a URI, and how much in data associated with>the URI? You seem to be trying to encode all of the data into the URI>naming space. Why not have a single URI for the target, and then trigger>behavior based upon the content? That would seem more extensible and less>fragile.> >>This would also unify with Costin's thoughts regarding tool-neutral>standards for the repository and project descriptors. The URI tells the>repository what you want, and it responds with the information known about>it, such as the locations of its parts, dependency information, build>instructions, etc. The URI could encode optional filter information about>what we want in the response. Depending upon whether the resource were>dynamic or static, the filter might or might not be honored.>>Seems to me that some of the prior art associated with JNLP should be>brought into the picture, as well as everything that Maven has learned about>repositories. And REST in terms of the web interaction.> >>Also, shouldn't URIs also support movement of the resource, e.g., when a>sub-project moves from underneath a project? For that matter, is the>project hierarchy really useful in the URI, or just a unique name?> >>Thoughts?> >Your approach seems very powerfull, I like it.I was trying for a "Valid" repositry being just a filesystem. I think we can add the rest later as optionl support elements.A filesystem only approach lets other people build "compatible" repositories without tools or keeping a catalog.xml or whatever uptodate.> --- Noel>>>->To unsubscribe, e-mail: [EMAIL PROTECTED]>For additional commands, e-mail: [EMAIL PROTECTED]> >-- Nick Chalko Show me the code. Centipede Ant + autodownloadable build plugins + needed jars autodownload. http://krysalis.org/centipede--To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
[EMAIL PROTECTED] wrote: As an aside, one of the issues we had when coming up with Maven's repository format, is that often artifacts (jars, wars, ears etc), will get left on the filesystem outside of a repository. Think rpms for example. Having a file encode --.type has been very useful for us. Yes, it's often different from what the project creates and distributes, but I (and others) have been bitten by commons-logging.jar, struts.jar, junit.jar so many times, that seeing log4j-1.2.5.jar is a godsend. I totally share this experience and support the concept. -- 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: [proposal] daedalus jar repository
On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote: > Having a file encode --.type has been very useful > for us. > > Yes, it's often different from what the project creates and distributes, but > I (and others) > have been bitten by > commons-logging.jar, struts.jar, junit.jar so many times, that seeing > log4j-1.2.5.jar is a > godsend. Yes, but I already mentioned that it can easily break features that work: if a project uses Classpath attributes in the manifest ( a legal option that simplifies setup - you may like it or not ) - then some things will stop working. It will also break any script or program that creates classpaths by using jar names. And it will break the explicit CLASSPATH env variables and manifest attributes once again every time you upgrade - since the jar name will change. It'll also break Ant build files that use the jar name - just do a grep on jakarta and you'll find how many they are. All those problems can only be solved with the active participation of the projects - by implementing whatever code is needed to support filenames that change. For Classpath attributes - that's not possible, so project will have to agree to stop using this (nice IMO ) feature. It doesn't matter how nice the versioned filename may look or how much it can simplify maven code - if it breaks the code of the project ( sometimes in subtle ways - if ant or a project won't find a jar, it may disable a feature ) It is also redundant information - each jar has a well-defined Manifest that should include version. .so files are versioned - that would be the perfect argument to convince people to adopt this naming scheme. But think what happens if someone takes a .so file that was shiped with an application, and renames it to something he feels is nicer. The app will just stop working. You can't mess with a project distribution files without the risk of breaking something. Many people like this naming convention - but they can't impose it to everyone. I'm more then willing to accept and support this naming scheme - my only condition is to be the result of an informed decision by the apache developer community. ( the breakages are just 2 simple examples - there are many other arguments in both sides ) BTW - an important thing to keep in mind is that in many cases the latest version of a .jar may fix security bugs - so it shouldn't just pick the buggy jar. Having multiple versions of the same jar in a system creates huge problems. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
On Sat, 2003-03-01 at 11:12, Costin Manolache wrote: > On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote: > > It is also redundant information - each jar has a well-defined Manifest > that should include version. > Unfortunately practice and observation show this not to be the case in many situations. Many of Sun's own JARs carry zero useful manifest information. Manifests certainly need to be improved but they aren't even close to consistent or useful. -- 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
On Sat, 1 Mar 2003, Stefano Mazzocchi wrote: > Date: Sat, 01 Mar 2003 12:08:36 +0100 > From: Stefano Mazzocchi <[EMAIL PROTECTED]> > Reply-To: community@apache.org > To: community@apache.org > Subject: Re: [proposal] daedalus jar repository > > [EMAIL PROTECTED] wrote: > > As an aside, one of the issues we had when coming up with Maven's > > repository format, is that often artifacts (jars, wars, ears etc), will > > get left on the filesystem outside of a repository. > > > > Think rpms for example. > > > > Having a file encode --.type has been very > > useful for us. > > > > Yes, it's often different from what the project creates and distributes, > > but I (and others) have been bitten by > > commons-logging.jar, struts.jar, junit.jar so many times, that seeing > > log4j-1.2.5.jar is a godsend. > > I totally share this experience and support the concept. > I've gotten bit by the opposite problem (changing version number in a JAR filename causing broken build scripts) just as often. Wouldn't a reasonable approach to this problem be to make searches for "commons-foo.jar" return the latest released version, while searches for "commons-foo-x.y.jar" would return that particular version? Then, you can have it either way. On the former, one might also support a mode that grabs the latest nightly instead of the latest reslease. > -- > Stefano Mazzocchi <[EMAIL PROTECTED]> > Pluralitas non est ponenda sine necessitate [William of Ockham] > Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository
> Wouldn't a reasonable approach to this problem be to make searches for > "commons-foo.jar" return the latest released version, while searches for > "commons-foo-x.y.jar" would return that particular version? Then, you can > have it either way. On the former, one might also support a mode that > grabs the latest nightly instead of the latest reslease. This sounds reasonable, and it's pretty much what the apache download mirroring does, using a symlink called "project-foo-current.format" to the latest release, and still maintaining numbered versions for those that care. Extending this concept to nightlies (nightlys?) could be achieved by using "project-foo-nightly.format". I'm assuming, without reading all the mail on this topic, that this idea is bound to fit with any structure or naming scheme anyone might wish to propose. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
On 1 Mar 2003, Jason van Zyl wrote: > On Sat, 2003-03-01 at 11:12, Costin Manolache wrote: > > On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote: > > > > > It is also redundant information - each jar has a well-defined Manifest > > that should include version. > > > > Unfortunately practice and observation show this not to be the case in > many situations. Many of Sun's own JARs carry zero useful manifest > information. Manifests certainly need to be improved but they aren't > even close to consistent or useful. That may be a consequence of the lack of tools to support it. With servlet2.3+ requiring containers to process the manifest, and if more tools and projects start using it - this may slowly change. But I agree - relying only on manifest is not reasonable at this moment. One idea would be to distribute a filename.jar.MANIFEST next to each jar that doesn't have a proper manifest - and have tools check for this file ( in addition to the manifest inside the jar ). It would allow us to add the missing info from the manifest - and use the real manifest where it is available. Again - it's all a matter of tool and product support. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
Costin Manolache wrote: On 1 Mar 2003, Jason van Zyl wrote: On Sat, 2003-03-01 at 11:12, Costin Manolache wrote: On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote: It is also redundant information - each jar has a well-defined Manifest that should include version. But I agree - relying only on manifest is not reasonable at this moment. One idea would be to distribute a filename.jar.MANIFEST next to each jar that doesn't have a proper manifest - and have tools check for this file ( in addition to the manifest inside the jar ). It would allow us to add the missing info from the manifest - and use the real manifest where it is available. Again - it's all a matter of tool and product support. Centipede builds a manifest for all jars. Krysalis Version, will look into a manifest for version information. The tools are starting to come. If we build it (the repo) they (the tools) will come. 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
> Craig R McClanahan writes: > Wouldn't a reasonable approach to this problem be to make searches > for "commons-foo.jar" return the latest released version, while > searches for "commons-foo-x.y.jar" would return that particular > version? Then, you can have it either way. On the former, one might > also support a mode that grabs the latest nightly instead of the > latest reslease. I'd prefer to be explicit to avoid any possible confusion, but I also see the need to grab the latest released versions of a jar. With that said, how about doing something along the lines that we've done in Maven. We indicate that we want to use the latest version of a jar by using "SNAPSHOT" as the version identifier. Of course, this identifies only the most recent jar (usually a dev release); however, there is no reason why another identifier could not be used to indicate the latest released version of a jar, perhaps "RELEASE"? For example: To grab the latest released version: commons-foo-RELEASE.jar To grab the latest nightly build: commons-foo-SNAPSHOT.jar And of course, to grab a specific version: commons-foo-x.y.jar This avoids any possible ambiguities. -Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
Costin Manolache <[EMAIL PROTECTED]> wrote on 02/03/2003 03:12:55 AM: > On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote: > > > Having a file encode --.type has been > very useful for us. > > > > Yes, it's often different from what the project creates and > distributes, but I (and others) > > have been bitten by > > commons-logging.jar, struts.jar, junit.jar so many times, that > seeing log4j-1.2.5.jar is a > > godsend. > > Yes, but I already mentioned that it can easily break features that work: > if a project uses Classpath attributes in the manifest ( a legal option > that simplifies setup - you may like it or not ) - then some things will > stop working. Having a versioned copy of the jar file around doesn't break anything that already exists. No-one is saying that people should remove their old stuff. > It will also break any script or program that creates classpaths by using > jar names. As will changing the directory it's in, the file extension etc. > And it will break the explicit CLASSPATH env variables and manifest > attributes once again every time you upgrade - since the jar name will > change. You mean people still specify CLASSPATH env variables. Yick. But, again, if you 'upgrade' you don't have to remove the old files. > It'll also break Ant build files that use the jar name - just do a grep > on jakarta and you'll find how many they are. And many of those are the ones people can't be bothered setting up. Most of commons for example is a PITA to build. I tried recently to quickly get commons-modeler going for a Tomcat connector, and it was a joke. Try building struts from source, the setup is a bitch. > All those problems can only be solved with the active participation > of the projects - by implementing whatever code is needed to support > filenames that change. For Classpath attributes - that's not possible, > so project will have to agree to stop using this (nice IMO ) feature. Not necessarily. If the manifest is built by a tool, it can automatically place the correct names in the classpath entry for you. > It doesn't matter how nice the versioned filename may look or > how much it can simplify maven code - if it breaks the code of the Costin, I'm not speaking about maven code here. In fact, I'm not talking about any code at all. > project ( sometimes in subtle ways - if ant or a project won't find a jar, > it may disable a feature ) > > It is also redundant information - each jar has a well-defined Manifest > that should include version. Really. Go read all the manifests on www.ibiblio.org/maven/*.jar and tell me how many: a) Have a valid manifest b) Have a license in the jar c) Have code from other projects contained within Believe me, the actual jars that are distributed by most projects do not come packaged ready for binary distribution. Take for example commons-logging 1.0.2 and the manifest in it's jar, which has: Class-Path: log4j.jar log4j-core.jar in it. > .so files are versioned - that would be the perfect argument to convince > people to adopt this naming scheme. But think what happens if someone > takes a .so file that was shiped with an application, and renames it to > something he feels is nicer. The app will just stop working. You can't > mess with a project distribution files without the risk of breaking > something. Nor should you just 'mess with a project distribution files' and expect things to still work. > Many people like this naming convention - but they can't impose it > to everyone. I'm more then willing to accept and support this naming Call your jars what you like. Noone is 'imposing' it on you. > scheme - my only condition is to be the result of an informed decision > by the apache developer community. ( the breakages are just 2 simple > examples - there are many other arguments in both sides ) > > BTW - an important thing to keep in mind is that in many cases the > latest version of a .jar may fix security bugs - so it shouldn't > just pick the buggy jar. Having multiple versions of the same What are you talking about here? What 'shouldn't just pick the buggy jar'? If something goes about picking new versions of jars, that I've gone to the trouble to specify, I'm going to be very upset. If I've asked for 'the latest', fair enough. > jar in a system creates huge problems. Having multiple versions of the same jar in many 'systems' is not an issue. Classloader isolation exists for a reason. Imagine a servlet engine where you can only have one copy of struts.jar. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote on 02/03/2003 05:36:38 AM: [snip] > I've gotten bit by the opposite problem (changing version number in a JAR > filename causing broken build scripts) just as often. > > Wouldn't a reasonable approach to this problem be to make searches for > "commons-foo.jar" return the latest released version, while searches for > "commons-foo-x.y.jar" would return that particular version? Then, you can > have it either way. On the former, one might also support a mode that > grabs the latest nightly instead of the latest reslease. Maven has the concept of a 'SNAPSHOT' jar, which is the latest date-timestamped version of an artifact available. If tell Maven you depend on a SNAPSHOT, at each build it checks to make sure you have the latest available, and downloads the new one if needed. This however doesn't fix the problem, as people can change version numbers on jars to anything they want, possibly a fictitious release. 'LATEST' builds are often not reproducible as well. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
Dion, can you please use the newly created [EMAIL PROTECTED] mailing list (thanks, Sam) for this sort of topics? Thanks and cheers, Erik Sam Ruby wrote: I'm in a "just do it" kind of mood. I just created a [EMAIL PROTECTED] mailing list. Noel is the initial moderator. If/when there is an infrastructure.apache.org set up, I'll move the list to there. (currently it is [EMAIL PROTECTED]). If there is significant dissent, or the list falls into disuse, I'll simply delete the list. - Sam Ruby [EMAIL PROTECTED] wrote: "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote on 02/03/2003 05:36:38 AM: [snip] I've gotten bit by the opposite problem (changing version number in a JAR filename causing broken build scripts) just as often. Wouldn't a reasonable approach to this problem be to make searches for "commons-foo.jar" return the latest released version, while searches for "commons-foo-x.y.jar" would return that particular version? Then, you can have it either way. On the former, one might also support a mode that grabs the latest nightly instead of the latest reslease. Maven has the concept of a 'SNAPSHOT' jar, which is the latest date-timestamped version of an artifact available. If tell Maven you depend on a SNAPSHOT, at each build it checks to make sure you have the latest available, and downloads the new one if needed. This however doesn't fix the problem, as people can change version numbers on jars to anything they want, possibly a fictitious release. 'LATEST' builds are often not reproducible as well. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: As an aside, one of the issues we had when coming up with Maven's repository format, is that often artifacts (jars, wars, ears etc), will get left on the filesystem outside of a repository. Think rpms for example. Having a file encode --.type has been very useful for us. Yes, it's often different from what the project creates and distributes, but I (and others) have been bitten by commons-logging.jar, struts.jar, junit.jar so many times, that seeing log4j-1.2.5.jar is a godsend. A big +1 to get version in jar file name : For instance in jpackage we install all 'small jars in ' : /usr/share/java/ And make use of symlink : /usr/share/java/log4j-1.2.7.jar /usr/share/java/log4j.jar -> /usr/share/java/log4j-1.2.7.jar When there is many jars in a project, we're using subdir : /usr/share/java/jsse/jcert-1.0.3.01.jar /usr/share/java/jsse/jcert.jar -> jcert-1.0.3.01.jar /usr/share/java/jsse/jnet-1.0.3.01.jar /usr/share/java/jsse/jnet.jar -> jnet-1.0.3.01.jar /usr/share/java/jsse/jsse-1.0.3.01.jar /usr/share/java/jsse/jsse.jar -> jsse-1.0.3.01.jar As such you could have many differents versions at the same time in the repository : ie : tyrex-0.9.7.jar (for TC 4.0.x) tyrex-1.0.jar (for TC 4.1.x) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution
Now I've gone from digest to individual emails, keeping up might be easier... [EMAIL PROTECTED] wrote on 27/02/2003 03:08:17 AM: > -- > From: Leo Simons <[EMAIL PROTECTED]> > yep. So don't drop the binary until you have a) policy, b) desire and c) > an ok to make apache into > a redistribution point of third-party software. Just b) doesn't cut it. The issue for the ASF is that we already *are* distributing third-party software via cvs and viewcvs. jdom, w3c stuff like dom2, jaxp, JLex, tidy etc > Licensing policy is quite tricky and lots of things need to be done > before the ASF should even consider Now there's an understatement. > For example, the docs started at > http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing should be made > into an authoritive source on > www.apache.org that unambiguously answers "yes" or "no" with regard to > > "can we link to software under license X?", And what does 'linking' mean for languages used by the ASF, e.g. Java, PHP, Perl, scripting languages like Javascript? > "can we redistribute software under license X in source form and/or > binary form?", > "how do we provide these licenses when we redistribute or link to > software under license X?", > "what other steps doe we take when we redistribute or link to software > under license X?" e.g. credits, details in documentation, etc. > Not sure if your project can distribute JUnit? Then don't, even if that > makes life terribly inconvenient. That seems to be the opposite of most projects current stance. > sourcecode under its own license. Yes, binary, but it is the best first > step and it solves a real need. Just to play devils advocate, what is that need, Given that there current is a repository distributing ASF binaries with their license. This is not a facetious comment, but a desire to explore what the need is for an ASF-blessed repository. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution
On Thu, 27 Feb 2003 [EMAIL PROTECTED] wrote: > > "can we link to software under license X?", > And what does 'linking' mean for languages used by the ASF, e.g. Java, > PHP, Perl, scripting languages like Javascript? Actually - in a lot of cases - that is not 'our' problem. Best we can do is ask the owner/author of the IP/License for which resolving such is important for his-or-her take on that; and then make sure the answer is filed properly in the ASF books. Dw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution
Dirk-Willem van Gulik <[EMAIL PROTECTED]> wrote on 27/02/2003 10:18:26 AM: > > On Thu, 27 Feb 2003 [EMAIL PROTECTED] wrote: > > > > "can we link to software under license X?", > > > And what does 'linking' mean for languages used by the ASF, e.g. Java, > > PHP, Perl, scripting languages like Javascript? > > Actually - in a lot of cases - that is not 'our' problem. Best we can do > is ask the owner/author of the IP/License for which resolving such is > important for his-or-her take on that; and then make sure the answer is > filed properly in the ASF books. Yep. If the ASF wants to use third-party code, it must verify the license usage is legal. Given the discussions lately re: LGPL, this sort of issue is extremely important. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [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]
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]
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)
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)
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)
> 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, 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)
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)
> 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)
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)
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)
> 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)
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)
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: 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)
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: [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: [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)
+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)
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)
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]
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)
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)
[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)
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)
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 participatio
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. <> 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. <> 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)
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, 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)
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)
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)
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)
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)
"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)
> 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: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
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. Bah. The Board can easily change the scope if there are better ways to organize the software that we [the ASF] produce. Existing charters shouldn't get in the way of What Is Right. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On Wed, 2003-02-26 at 09:34, Greg Stein wrote: > 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. > > Bah. The Board can easily change the scope if there are better ways to > organize the software that we [the ASF] produce. > > Existing charters shouldn't get in the way of What Is Right. "What Is Right" ? So that's going to be the board deciding what is right? What project's themselves want is not right enough? That is frightening. What happened to project self direction/determination? > Cheers, > -g -- 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)
Jason van Zyl wrote: On Wed, 2003-02-26 at 09:34, Greg Stein wrote: On Wed, Feb 26, 2003 at 09:48:42PM +1100, [EMAIL PROTECTED] wrote: [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. Bah. The Board can easily change the scope if there are better ways to organize the software that we [the ASF] produce. Existing charters shouldn't get in the way of What Is Right. "What Is Right" ? So that's going to be the board deciding what is right? What project's themselves want is not right enough? That is frightening. What happened to project self direction/determination? The board changes things like scope based on resolutions provided to it. If the committers to Ant and Maven wanted to cooperate, then a joint proposal could be authored for consideration by the board. The idea of such committer initiated proposals do not concern me, unless such proposals attempt to establish responsibility for items that are within the scope of other, existing projects. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On Wed, 2003-02-26 at 10:28, Sam Ruby wrote: > Jason van Zyl wrote: > > On Wed, 2003-02-26 at 09:34, Greg Stein wrote: > >>On Wed, Feb 26, 2003 at 09:48:42PM +1100, [EMAIL PROTECTED] wrote: > > [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. > >> > >>Bah. The Board can easily change the scope if there are better ways to > >>organize the software that we [the ASF] produce. > >> > >>Existing charters shouldn't get in the way of What Is Right. > > > > "What Is Right" ? > > > > So that's going to be the board deciding what is right? What project's > > themselves want is not right enough? That is frightening. What happened > > to project self direction/determination? > > The board changes things like scope based on resolutions provided to it. > If the committers to Ant and Maven wanted to cooperate, then a joint > proposal could be authored for consideration by the board. > > The idea of such committer initiated proposals do not concern me, unless > such proposals attempt to establish responsibility for items that are > within the scope of other, existing projects. Oh, you mean like the Avalon resolution which cross-cuts several other projects like Turbine and Struts. That one didn't seem to bother you. Don't make vague assertions when it's your personal agenda here Sam that's driving the cart. Or how about we make a tautalogical resolution like the Ant or Cocoon resolutions which got passed. I'm fine with changing the resolution to something like those of Ant or Cocoon: "The Maven Project will deal with the Maven system". But again those didn't really bother you either. But Maven's does. Or how about we add an addendum where the project has to have decent code and some _tests_ and actual users. That would pretty leave Maven standing by itself. It is not for you to personally decide who and who shouldn't work together because that's what's happening and that's complete bullshit. I know the board relies on you for their primary source information with anything to do with Jakarta and I think the time has come for you to be called on stacking the deck when what occurs doesn't line up with your little vision of how OSS should work. It is soley up the project participants to decide who they want to work with. Not you. I hope for your sake that you adhere to your word when you said you would abstain from the vote on Maven's PMC if there was a conflict of interest because there is a conflict of interest. And if you reply to this don't exerpt the bits you don't like as you usually do. > - Sam Ruby > > > - > 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)
On Wed, 2003-02-26 at 10:43, Jason van Zyl wrote: > > Or how about we make a tautalogical resolution like the Ant or Cocoon > resolutions which got passed. I'm fine with changing the resolution to > something like those of Ant or Cocoon: "The Maven Project will deal with > the Maven system". But again those didn't really bother you either. But > Maven's does. Or how about we add an addendum where the project has to > have decent code and some _tests_ and actual users. That would pretty > leave Maven standing by itself. > I'll qualify this as I'm didn't intend to lump Ant in here. I'm specifically talking about Gump, Centipede and Ruper which as far as I'm concerned are an embarassment and Maven developers should not be forced into working with bodies of code we feel are not very good. -- 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)
Jason, [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. >>Bah. The Board can easily change the scope if there are better ways to >>organize the software that we [the ASF] produce. > So that's going to be the board deciding what is right? What project's > themselves want is not right enough? That is frightening. What happened > to project self direction/determination? I perceived Greg's comment as saying that if Ant and Maven wanted to cooperate under a PMC, that the Board could change the scope of the PC charter. Why is this frightening to you? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On Wed, 2003-02-26 at 10:54, Noel J. Bergman wrote: > Jason, > > [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. > >>Bah. The Board can easily change the scope if there are better ways to > >>organize the software that we [the ASF] produce. > > So that's going to be the board deciding what is right? What project's > > themselves want is not right enough? That is frightening. What happened > > to project self direction/determination? > > I perceived Greg's comment as saying that if Ant and Maven wanted to > cooperate under a PMC, that the Board could change the scope of the PC > charter. Why is this frightening to you? Because this is not what's happening. Sam is trying to force a collalition because of some sense of "Rightness". We would like to be left alone and if a natural level of cooperation emerges in time so be it. But it shouldn't be dictated from the start which is the impression I'm getting. > > --- 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)
Jason, I am the one who raised the issue about Ant and Maven. I have made the observation before. Dion said that it was the Ant PMC that was in the way. Greg Stein replied that the Ant charter could be changed if that was the only issue. You jumped down Greg's throat about the Board taking away project self-determination. Sam replied that you had misinterpreted Greg's comments. So you jumped down Sam's throat with what appears to be an assault based upon prior context, because it certainly cannot be inferred from what Sam said to you this morning. Since I am the one who asked why Ant and Maven aren't related projects under a PMC, you might was well yell at me for having the temerity to ask a rather obvious question. But for all of your railing this morning, you never actually answered the question. What you did say was that: "I'll qualify this as I'm didn't intend to lump Ant in here. I'm specifically talking about Gump, Centipede and Ruper which as far as I'm concerned are an embarassment and Maven developers should not be forced into working with bodies of code we feel are not very good." Well, I didn't ask about Gump, Centipede or Ruper. I asked about Ant and Maven. Start there. And as far as I'm concerned, if Build Project X sucks (a logical antecedent for the sake of discussion), then an Ant/Maven PMC could resolve that by correction/replacement as part of their on-going development. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On Wed, 2003-02-26 at 11:02, Noel J. Bergman wrote: > Jason, > > I am the one who raised the issue about Ant and Maven. I have made the > observation before. Dion said that it was the Ant PMC that was in the way. > Greg Stein replied that the Ant charter could be changed if that was the > only issue. You jumped down Greg's throat about the Board taking away > project self-determination. Sam replied that you had misinterpreted Greg's > comments. So you jumped down Sam's throat with what appears to be an > assault based upon prior context, because it certainly cannot be inferred > from what Sam said to you this morning. My comments cannot be misinterpreted. My observations relate strictly to the behaviour of the board in their relationship with Sam. I'm definitely trying to draw out into the open how things work. I don't get the feeling in this case project self determination is winning out because it's clashing with Sam's philosophy. Some of my comments include bits of other conversations which I am trying to draw into this one. > Since I am the one who asked why Ant and Maven aren't related projects under > a PMC, you might was well yell at me for having the temerity to ask a rather > obvious question. But for all of your railing this morning, you never > actually answered the question. I just answered it in another email. > What you did say was that: "I'll qualify this as I'm didn't intend to lump > Ant in here. I'm specifically talking about Gump, Centipede and Ruper which > as far as I'm concerned are an embarassment and Maven developers should not > be forced into working with bodies of code we feel are not very good." > > Well, I didn't ask about Gump, Centipede or Ruper. I asked about Ant and > Maven. Start there. And as far as I'm concerned, if Build Project X sucks > (a logical antecedent for the sake of discussion), then an Ant/Maven PMC > could resolve that by correction/replacement as part of their on-going > development. I don't feel that the grouping of the two projects would necessarily make a better anything. Ant is currently on its own, and Maven has remained on its own. If a natural level of cooperation is going to occur it's not going to matter if we are grouped under the same PMC or not. Just as James as separated from Avalon, your level of cooperation will probably continue on the same path it always did. Doesn't matter where your projects are or if you are governed by the same PMC or not. > --- 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)
On Wed, 2003-02-26 at 11:02, Noel J. Bergman wrote: > > Since I am the one who asked why Ant and Maven aren't related projects under > a PMC, you might was well yell at me for having the temerity to ask a rather > obvious question. But for all of your railing this morning, you never > actually answered the question. > To expand, I think ultimately all that matters is that a project be given the space it wants in an attempt to let it flourish. If the Maven developers want to be left entirely alone why is that a concern? If we compete head-on with Ant why is that a concern? If we compete head-on with Centipede and it's satellite of related projects what's the concern? If we don't want to use Gump or talk to any of the Centipede so what? Compete with us! You cannot force relationships between groups when the desire to do so does not emanate in mutual proportion from both parties. We don't want to grouped under the same PMC as Ant. How's that? We want to go alone and I think we've done a pretty decent job so far. If we falter and require, desire or ask for help later on than we can do so. If we desire to collaborate or merge with other projects than we can do so. Give each project its own space and let the network of interaction form of its own accord. If it is easy to shuffle PMCs and alliances then let it occur when there is reason too. All I and any of the Maven developers want to do is try to make it better. But from day one I have had nothing but pressure from Sam Ruby. Starting from him asking me to use a huge mess of an xslt transformed gob of XML as the model for Maven to using Gump as tool of coercion to force unnatural paths of evolutuion. I ignored the first request and I continue to ignore gump because anything not taking the project into primary consideration won't work. > - > 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)
From: "Noel J. Bergman" <[EMAIL PROTECTED]> > Well, I didn't ask about Gump, Centipede or Ruper. I asked about Ant and > Maven. Start there. And as far as I'm concerned, if Build Project X sucks > (a logical antecedent for the sake of discussion), then an Ant/Maven PMC > could resolve that by correction/replacement as part of their on-going > development. I thought the whole reason that Ant, Avalon, Cocoon, James et al moved top level (out of Jakarta) was to get rid of top level umbrella PMCs so that each project has its own PMC. This is all Maven is trying to do. Any kinds of integration/merging is an internal decision for the Ant and Maven communities isn't it? I see Ant/Maven integration as a totally separate issue from who makes up the PMC to look after the Maven project. I don't see why why we'd need another top level PMC looking after both Ant and Maven as they are separate projects afterall. James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
I must stay that I find this entire exchange bewildering. I have provided infrastrure support for Maven and an occasional patch here and there. When asked about either Maven becoming a top level project or leaving the ASF entirely, I provided what I thought were helpful answers. I welcomed Jason as a committer to Alexandria (where Gump was at the time, and Maven initially formed). I supported his movement of Maven from Alexandria to Turbine. And now I have indicated that I will abstain when the actual board vote is held on Maven becoming a top level project. - Sam Ruby Jason van Zyl wrote: On Wed, 2003-02-26 at 11:02, Noel J. Bergman wrote: Since I am the one who asked why Ant and Maven aren't related projects under a PMC, you might was well yell at me for having the temerity to ask a rather obvious question. But for all of your railing this morning, you never actually answered the question. To expand, I think ultimately all that matters is that a project be given the space it wants in an attempt to let it flourish. If the Maven developers want to be left entirely alone why is that a concern? If we compete head-on with Ant why is that a concern? If we compete head-on with Centipede and it's satellite of related projects what's the concern? If we don't want to use Gump or talk to any of the Centipede so what? Compete with us! You cannot force relationships between groups when the desire to do so does not emanate in mutual proportion from both parties. We don't want to grouped under the same PMC as Ant. How's that? We want to go alone and I think we've done a pretty decent job so far. If we falter and require, desire or ask for help later on than we can do so. If we desire to collaborate or merge with other projects than we can do so. Give each project its own space and let the network of interaction form of its own accord. If it is easy to shuffle PMCs and alliances then let it occur when there is reason too. All I and any of the Maven developers want to do is try to make it better. But from day one I have had nothing but pressure from Sam Ruby. Starting from him asking me to use a huge mess of an xslt transformed gob of XML as the model for Maven to using Gump as tool of coercion to force unnatural paths of evolutuion. I ignored the first request and I continue to ignore gump because anything not taking the project into primary consideration won't work. - 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: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On 26 Feb 2003, Jason van Zyl wrote: > So that's going to be the board deciding what is right? What project's > themselves want is not right enough? That is frightening. What happened > to project self direction/determination? I am not sure where you've got that impression from; and I hope it is not based on anything happening within the ASF - virtually all projects and committer groups actively drive their own destinies; and draft their own charters and define their own scope. That does not mean that the board, or other community figures, occasionally help out and make suggestions - but by and large things are driven directly by comitters - which by and large need little help in communicating and coordinating. I've not seen anything else. DW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On 26 Feb 2003, Jason van Zyl wrote: > Because this is not what's happening. Sam is trying to force a > collalition because of some sense of "Rightness". We would like to be > left alone and if a natural level of cooperation emerges in time so be > it. But it shouldn't be dictated from the start which is the impression > I'm getting. I am not sure why you are jumping at specifically Sam's throath. At more than one occasion has he offered to abstain from voiting in cases like this. Most of this thread seems to be driven my a very carefully worded remark from Noel - who rightfully pointed out that there is a fair amounth of overlap in the jar repository activities, the ant building tool and the Maven building tool. And that perhaps some sort of coordination or collaboration would be good for everyone - and eventually beneficial for the whole ASF community. A board can help in a coordinating role to make these things happen. If Sam is suggesting ways for groups to work together - then I think that is good - and valuable. It reminds me of a dutch expression for which I do not know the US equivalent - such as the trust of the host is in his guests - for so much can he trust his guests. Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On Wed, 2003-02-26 at 12:19, Dirk-Willem van Gulik wrote: > On 26 Feb 2003, Jason van Zyl wrote: > > > So that's going to be the board deciding what is right? What project's > > themselves want is not right enough? That is frightening. What happened > > to project self direction/determination? > > I am not sure where you've got that impression from; and I hope it is not > based on anything happening within the ASF - virtually all projects and > committer groups actively drive their own destinies; and draft their own > charters and define their own scope. Cool, that's all I wanted to hear. > That does not mean that the board, or other community figures, > occasionally help out and make suggestions - but by and large things are > driven directly by comitters - which by and large need little > help in communicating and coordinating. > > I've not seen anything else. > DW > > > - > 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)
On 26 Feb 2003, Jason van Zyl wrote: > If we compete head-on with Ant why is that a concern? No and yes - in that order. Short term, propably not; long term - seems a waste of resources; espcially if you are not competing exactly head to head but slightly diverse into different areas. Which then do not connect as well as they could. But then again - short term it is propably good to see some competition to figure out what works in a quicker paced social environment. But longer term - a lot of energy may go to waste. > We don't want to grouped under the same PMC as Ant. How's that? Now that was never the suggestion - interesting notion :-) But you folks all do want to be grouped under one Apache banner - now what does that then mean ? Ultimately where does one see the -whole- of the ASF to slowly go towards; or if that is too large a question - most of the java code. Is there any synergy - or is the most we can hope for a 'sourceforge' which a little more license sanity and peer controlled commit ? I think synergy is worth aiming for; reinventing the wheel (and mainting it) in several places is propably not worth it in the long run. Dw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
> > It reminds me of a dutch expression for which I do not know the US > > equivalent - such as the trust of the host is in his guests - for so > > much can he trust his guests. Actually just found "Ill doers are ill deemers" or better perhaps "Evil dooers are evil dreaders". Not sure if it is exactly right do - seems to start too much on the back side. Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On 26 Feb 2003, Jason van Zyl wrote: > > Since I am the one who asked why Ant and Maven aren't related projects under > > a PMC, you might was well yell at me for having the temerity to ask a rather > > obvious question. But for all of your railing this morning, you never > > actually answered the question. > > > > To expand, I think ultimately all that matters is that a project be > given the space it wants in an attempt to let it flourish. If the Maven > developers want to be left entirely alone why is that a concern? > > If we compete head-on with Ant why is that a concern? > > If we compete head-on with Centipede and it's satellite of related > projects what's the concern? > > If we don't want to use Gump or talk to any of the Centipede so what? > Compete with us! You cannot force relationships between groups when the > desire to do so does not emanate in mutual proportion from both parties. I have no problem with maven doing whatever it pleases. The subject of this thread was about the jar repository on daedalus - and about who will oversee it. Maven can choose to not participate - but it can't choose to put it under its charter. I see no problem if Ant, Gump, Centipede cooperate on the jar repository - and maven doesn't. AFAIK Gump and Centipede does not compete with ant or with each other - quite the contrary. If maven wants to compete with ant or gump - that's great, competition is a good way to improve. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On Wed, Feb 26, 2003 at 09:46:16AM -0500, Jason van Zyl wrote: > On Wed, 2003-02-26 at 09:34, Greg Stein wrote: >... > > Bah. The Board can easily change the scope if there are better ways to > > organize the software that we [the ASF] produce. > > > > Existing charters shouldn't get in the way of What Is Right. > > "What Is Right" ? > > So that's going to be the board deciding what is right? What project's > themselves want is not right enough? That is frightening. What happened > to project self direction/determination? People have said this in followups, but I'll specifically clarify my intent. If the projects at the ASF are hampered by their charters from doing the right thing, then they can simple ask the Board to get them changed. It is an easy process for the Board. There is no reason for you to suspect anything wonky from me, and your attitude towards my email is quite bewildering. To be honest, your response and the rest of the followups don't sit well with me at all. The Board exists to help projects in their work. We exist to protect the ASF to ensure that it will continue to exist, to help projects. Our intent is to let projects do whatever they feel is right and correct, subject to the constraints of the operation of the ASF and to what we feel may be injurious to the overall health of the ASF. I do think you're unfairly calling the Board a tool of Sam. Speaking for myself, that is a negative input to my own decision-making process. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
Costin Manolache wrote: I see no problem if Ant, Gump, Centipede cooperate on the jar repository - and maven doesn't. uhm, I would like to see all of the above and the rest of us cooperate on this thing. The value of everyone's work on setting up and maintaining such a repo decreases rapidly with decrease of support in the actual tools used for interfacing with the repo. I for one don't feel like having to maintain multiple repos. But OTOH, I don't feel like spending more energy arguing than it would take to set up those multiple repos. 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)
On Wed, Feb 26, 2003 at 10:43:05AM -0500, Jason van Zyl wrote: >... > Or how about we make a tautalogical resolution like the Ant or Cocoon > resolutions which got passed. I'm fine with changing the resolution to > something like those of Ant or Cocoon: "The Maven Project will deal with > the Maven system". And the Board already told Cocoon that it did not like that tautology. For the Cocoon case, the Board was comfortable in creating the PMC and letting them get started, with the caveat that they must submit a refined charter to the Board. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
> I think synergy is worth aiming for; reinventing the wheel (and mainting > it) in several places is propably not worth it in the long run. That's my core philosophy of software development. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
Greg Stein wrote: The Board exists to help projects in their work. We exist to protect the ASF to ensure that it will continue to exist, to help projects. Our intent is to let projects do whatever they feel is right and correct, subject to the constraints of the operation of the ASF and to what we feel may be injurious to the overall health of the ASF. my opinion: the board peeps are doing pretty well. For sure, they've helped out avalon in an admirable way. Enough slamming the board already: you guys rock! Big well-deserved thank you. enough posts from me for the day. (I'm starting to compare myself to Andy :D) cheers! - Leo PS: sorry for all the warm fuzziness. I ate too much chocolate. PPS: the relevant dutch saying: "Hoge bomen vangen veel wind". I'll leave it to Dirk to translate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
Leo Simons wrote: But OTOH, I don't feel like spending more energy arguing than it would take to set up those multiple repos. Maybe this is a bikeshed and some one should just do it. However I do feel the Apache Jar Repository is going to be a very popular bike shed. So some planning is waranted. 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: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
okey, this ticked my bogometer. Jason van Zyl wrote: > > My comments cannot be misinterpreted. an interesting position. :-) > My observations relate strictly to the behaviour of the board > in their relationship with Sam. indeed: your observations. subjective opinion, in other words, not the one true reality. > I'm definitely trying to draw out into the open how things work. so far you're not doing a very good job, because you seem to be hitting very wide of the mark. to put it rather more bluntly, jason, don't try to tell *me* how i'm affected by something; it's not your place, nor are you competent to do so. (no-one is except myself.) saying that it 'appears to you' that something is affecting me a certain way, however, is perfectly acceptable. please sprinkle a few more 'imho's through your posts, because otherwise the wording doesn't seem to even imply them. as for the board taking sam as the sole source of input about things regarding jakarta: i'm sure a little reflection on your part will reveal that as hyperbole. if it were true, none of the other board members would be subscribed to and participating on all the jakarta mailing lists that we are. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
