RE: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
-Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 11:18 AM To: Jakarta General List Subject: Clear the air Re: ATTN: Maven developers [was: primary distribution location] Nick Chalko who is one of my own personal favorites (despite him not fixing commons-vfs's funky file error this morning) is talking about a project to extend the maven repository in such a way that all Apache projects could use it. I'd rather not see a forked effort. This is something I'm pretty sure we can all agree on if we focus on the larger effort/benefits rather than details. In the end, the ASF gets to delete the duplicate jars from CVS and all projects can use Maven, Centipede or some ant tasks to resolve their depencies. I hope to have a proposal started on the Wiki tonight (PST). The Maven repository has been an essential tool for me for me. The next step is to play nice with gump. Then do help with dependencies Also to make it easy for projects to brand themselves with version and dependency information. I think Apache can grow a world class solution from the seed of the Maven Repository. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
On Wed, 2003-02-05 at 14:35, Geir Magnusson Jr. wrote: On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote: I hope to have a proposal started on the Wiki tonight (PST). The Maven repository has been an essential tool for me for me. The next step is to play nice with gump. Then do help with dependencies Also to make it easy for projects to brand themselves with version and dependency information. JJAR in commons sandbox had some of these ideas in there... But can you build this into maven rather than in parallel? The stuff in Maven can certainly be split out. As I said to Nick, it can already handle generation changes, evolution and the dependency mechanism in Maven already deals with non-JAR artifacts like WAR files, maven POMs, docs or whatever you want. -- 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: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
Geir Magnusson Jr. wrote, On 05/02/2003 20.35: On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote: I hope to have a proposal started on the Wiki tonight (PST). The Maven repository has been an essential tool for me for me. The next step is to play nice with gump. Then do help with dependencies Also to make it easy for projects to brand themselves with version and dependency information. JJAR in commons sandbox had some of these ideas in there... But can you build this into maven rather than in parallel? We had started using JJAR in Centipede. Then one of our developers decided to write Ruper, that works with Maven repositories. Now we come to the point that we need the features that JJAR gives too, although we have now a clearer picture of what is needed. JJAR functionality and codebase (merging) will be part of the proposal. BTW, we are not Maven developers. -- 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: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
On 5 Feb 2003, Jason van Zyl wrote: On Wed, 2003-02-05 at 14:29, Nick Chalko wrote: I hope to have a proposal started on the Wiki tonight (PST). The Maven repository has been an essential tool for me for me. The next step is to play nice with gump. Then do help with dependencies Also to make it easy for projects to brand themselves with version and dependency information. This can be done with Maven already. We have got a grip on generational transition, transitive dependencies and evolution. The non-trivial part is the collection of the information. The tools are present and I don't mind splitting them out if they want to be used elsewhere. I think Apache can grow a world class solution from the seed of the Maven Repository. I don't actually see why any project can't use the Maven repository right now. I don't yet either. http://www.generationjava.com/jars2/ is a maven repository. If I put Jakarta Commons-Lang there, am I breaking the Apache licence in some way by re-distributing Lang? If not, then the only thing I could see being wrong about ibiblio would be that an ASF project, Maven, uses it as its default repository. Which doesn't seem wrong, but might have some bad aspect I don't see. The Sun licence stuff on there is more quesitonable. I figure as long as ibiblio are aware they are liable, and that they have happily accepted that liability, then it doesn't matter. Or do they pass the liability on to the individual who set it up, [Jason?] ? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
On Wed, 5 Feb 2003, Nicola Ken Barozzi wrote: Geir Magnusson Jr. wrote, On 05/02/2003 20.35: On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote: JJAR in commons sandbox had some of these ideas in there... But can you build this into maven rather than in parallel? We had started using JJAR in Centipede. Then one of our developers decided to write Ruper, that works with Maven repositories. Now we come to the point that we need the features that JJAR gives too, although we have now a clearer picture of what is needed. JJAR functionality and codebase (merging) will be part of the proposal. BTW, we are not Maven developers. Why not work with Jason to extract the current Maven functionality for this feature, then enhance it as a sibling/child of the overall Maven project? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
I'd like to see this broken out of Maven / Centipede whatever, and put into libraries that can be used independent of the build tools. I also think that we need to plan for multiple repositories, whether they be ASF, ibiblio, what have you. There are two ideas going on in this thread. One is about the mechanism -- the repository, version management, dependency tracing, resource retreival etc. The other is about policy -- what kind of stuff can be in a particular repository. If the ASF ultimately decides to run its own repository with ASF policy that's fine. That shouldn't prevent the iBiblio repository (with a different policy) from continuing to exist. I'd hate to see us build mechanism that enforced policy. I'd like to lend a hand if this gets broken out into a separate project. Ted - Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 11:40 AM Subject: Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location] On Wed, 2003-02-05 at 14:35, Geir Magnusson Jr. wrote: On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote: I hope to have a proposal started on the Wiki tonight (PST). The Maven repository has been an essential tool for me for me. The next step is to play nice with gump. Then do help with dependencies Also to make it easy for projects to brand themselves with version and dependency information. JJAR in commons sandbox had some of these ideas in there... But can you build this into maven rather than in parallel? The stuff in Maven can certainly be split out. As I said to Nick, it can already handle generation changes, evolution and the dependency mechanism in Maven already deals with non-JAR artifacts like WAR files, maven POMs, docs or whatever you want. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
I just got off the phone and I got a clear answer as to what Apache could be liable for. If Maven, being an ASF piece of software, is party to illegal assembly then the ASF could be liable. I'd like to thank you and applaud you for being so concientious about this. I would not have thought that the case either. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
+1 ( a bit too long, but good !) Costin Rodent of Unusual Size wrote: okey, i'm wading in here, noting as i do the angels high-tailing it in the other direction.. :-) i'm ccing community@apache because i think portions of this discussion are important to the entire asf developer community, and not just jakarta. (jakarta leads the way again! grin nature=completely non-hostile/) this is my take on the things we need to keep in mind. i may be wrong; where i'm unsure, i'm erring on the side of conservatism. and i'm saying this stuff with my board hat semi-on; that is, i'll be glad to be corrected or overruled by the rest of the board, but in the absence of such i'm breaking new ground with a tentative prototype policy. it's all open to discussion and refinement, but it's semi-official. it's just my take on things at the moment, but it's a stake in the ground. now, then. the (at least!) two things we need to keep in mind are: 1. no asf package (or asf contributor acting ex officio being an apache contributor) may deliberately violate the terms of any licence. 2. no code nor activity is permitted that will virally infect any of the asf's assets, or those of any user of asf packages. those are pretty much non-negociable; any inadvertent violation needs to be corrected AT ONCE as soon as it is identified. violating a licence because 'everyone else is doing it' or 'the licence-owner has never gone after anyone' are not on; we need to do the Right Thing, not the cop-out or expedient one. if, for instance, we violated one of microsoft's licence terms just because everyone else does, the potential harm to the asf is enormous: not only massive monetary liability, but severe damage to our reputation for integrity. so we must not distribute any 3p (third-party) packages from asf systems if it is not permitted by their licences. nor may any of our code automatically go off and fetch such packages and start using them on the user's system if the packages' licences require *any* sort of acknowledgement by the user. that is, if the licence for package 'x' says the user must stand on its head and send a paypal donation before using 'x', none of our code may automatically download 'x' to the user's system. if it's *already* on the user's system, we can use it -- but we can't get into any position in which we are essentially responsible for transmitting someone else's licence terms to the user, and assuming they've agreed to comply with them. (i.e., for now i'm ruling click-through licences as not permissible for our stuff to present.) as far as sun-bin licensed stuff on ibiblio -- it's not an asf system, so the asf is neither liable nor responsible. *if* some asf package requires sun-bin stuff, and silently goes off to ibiblio to download it, though.. that's not allowed. telling the user it needs to download the sun-bin stuff is fine; telling it the stuff can be found on ibiblio.. well, i *think* that's okey, but it's kinda grey. if someone is using an asf package that does *not*, itself, require such stuff, but is using the asf package to build something that does, i think we're pretty much okey there too, since the user needs to explicitly state the dependency. i think it's possible to consider stating the dependency as equivalent to having the stuff already on the system -- but again it's a grey area, and i hope roy can shed some light in this darkness. again, autofetching it by default from a known location -- such as ibiblio or sun -- once the dependency has been stated by the user *should* be okey. i think. i'm not even going to touch the infection issue at this point; it always makes my cephalic nodule hurt horribly. let's just say that we can't do anything that will trigger an infection of the asf's assets -- or those of someone using asf packages. if a licence permits *linking* against a library, there's no prohibition on our packages requiring the library in order to run properly. if a licence allows us to include the library, as a general rule we can package it with our stuff. if by linking with it or including it in our distributions we trigger a clause in its licence that either overrides the asf licence on our stuff, or forces the user to comply with rules more restrictive than the asf licence.. then we mustn't do that. i hope this all makes sense, to some degree. please follow up to [EMAIL PROTECTED] and because recording incremental advances before a final policy is published seems like an appropriate use, i've set up http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing as a work area where we can distill the rules before they get finalised and formally published on www.apache.org. i need to stress that the wiki page is for *recording*, not discussing. if someone wants to take a look at the current state of things, the wiki is good method -- but hammering out
