Re: [VOTE] Apache JSecurity/Ki Project Rename - Final Vote
+1 Apache Shiro On 4-Jun-09, at 6:45 AM, Les Hazlewood wrote: Hi All, This is the final vote for the Apache JSecurity/Ki project's new name between the two proposed finalists. Please vote for only one of the following two (alphabetically-ordered) names: Apache Aseca - relevant letters in Application SECurity Api Apache Shiro - castle in Japanese Voting ends Wednesday June 10th, Midnight (GMT-8) to allow some time after the weekend for additional votes. Thank you for your vote! Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
On 28-Apr-09, at 1:24 AM, Niclas Hedhman wrote: On Tue, Apr 28, 2009 at 1:14 PM, Jason van Zyl jvan...@sonatype.com wrote: Not mocking, just clarifying that on the aggregate level what is distributed via the standard Apache mechanism easily has its analog source equivalent which can be built. Ok, I think we are in general agreement. Are you personally of the opinion that -sources.jar are not adequate as formal ASF releases? They are not, they do not need to be, and they would be useless for the purpose they serve. As long as the main distributables (like these at http://apache.org/dist/maven/) are accompanied by a source distribution which can be built. I have the opinion it is currently not, but I don't mind seeing a change... Right now the -sources.jars produced work with the default configurations of all the IDEs, if you want to figure out how to change all the IDEs then you're welcome to tackle that. I can tell you the number of users who have asked to be able to build from a - sources.jar over the last 5 years though. That would be zero. What is found at http://apache.org/dist/maven/ I believe is sufficient and adding the requirement of self-building -sources.jar is not required. That's not what their primary purpose is. A standard assembly descriptor that produced a standard Apache release from the top-level of a directory structure would be useful. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
On 28-Apr-09, at 11:50 AM, Henning Schmiedehausen wrote: Calm down, Jason. No one was attacking Maven. I'm not upset, seriously. This is standard fare here, and only pointing out having any solution which involves Maven might better be on a path that actually involves Maven developers. The Apache Software Foundation requires a project (not just an incubator podling. All projects) to release source in a form that can be used to recreate the binaries. For the current state of the Shindig release, this is not possible. Noone was saying anything else. For Apache, we release source code that is immediately consumable to users by downloading an artifact from our servers through www.apache.org/dist and potentially be able to rebuild the artifact. In general, this is a tarball / zip of the contents of a Subversion tag. Everything beyond that is - optional - a convenience to our users This especially goes to - binary archives (whether these are .jar archives in Java or Binary builds for a platform in non-Java land) - source/javadoc in another, better consumable form for IDEs Supporting these is nice to users, but the required part is the tarball that I can go into and say build-command (be it ant, maven or make) and get something that can be used. This is not the case for Shinig in its current state. Whether this is acceptable or not to the Incubator PMC members is another question. Ciao Henning On Mon, Apr 27, 2009 at 09:49, Jason van Zyl jvan...@sonatype.com wrote: On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote: On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton vincent.sive...@gmail.com wrote: You need to do a checkout of the tag to build it. The source artifacts provide only java source, no build file. -1. As others have pointed out, the ASF releases Open SOURCE, not Open Binaries and part of the policy is that the distributed artifact is first and foremost a buildable source tarball. Without it, it is not a release. You may have system requirements (thou shalt need Maven 2.0.6 or 2.0.9 ) and you should provide full build instructions to produce the projects binary. And if you distribute a binary, it should be the same thing that gets produced by following your instructions. And the above is not really up for debate either. At the end of the day, people will rely on tarballs, checksums (download integrity) and signatures (manipulation integrity), and those are the primary artifacts that Apache Infrastructure will archive and get mirrored around the world. Maven artifacts are really nice to have for Maven users, but is exactly that; Nice to have. Now, you are free to go banging on Maven's door that their built-in workflow doesn't support the Apache policy very well. Don't spread FUD like that. You don't have any idea how Maven releases work so I'll take a moment and explain it to you. For a release like Maven we have N modules, where each module produces a JAR, and each of those is released. Each JAR carries with it the POM inside it, but is in a form which can be automatically utilized by IDE integration to automatically be downloaded and integrated with debuggers. All the legal bits are in the JARs and legally intact as it were. The blue print to actually build that individual JAR is in the JAR by default in Maven. You can't just unpack that source JAR and build it and that's for a couple reasons: the first is that it's generally useless and the second is that we create a source archive of the entire release with all the modules which is what we recommend. As with Maven, the tagged sources for the build are distributed along with the binaries. This is a matter of setting up a source assembly, not hard to do. That said, show me any non-Maven project that makes individual JARs that have the capability of rebuilding themselves. There aren't any here at Apache. What gets produced is a overall source archive. And show me anything as advanced and useful to developers where grabbing the source JARs for debugging is transparent or materializing sources from binary artifact coordinates is a button click. Again, nothing does that besides Maven and the corresponding IDE integrations. So Maven adheres to any standard for the overall release but goes way above and beyond to actually produce something far more useful for actually doing work. So please don't try to explain to people what Maven does when you don't actually understand it yourself. What gets released as the N modules is complementary to aggregate release which is compliant with Apache. So if Shindig doesn't have the overarching source archive that's not hard to add. But there is not a single non-Maven build at Apache where a JAR emanating from multi-JAR build where that JAR carries with it the information to build itself. You are confusing an aggregate release with the releases of the individual components which
Re: [VOTE] Approve the release of Shindig Incubator 1.0
On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote: On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton vincent.sive...@gmail.com wrote: You need to do a checkout of the tag to build it. The source artifacts provide only java source, no build file. -1. As others have pointed out, the ASF releases Open SOURCE, not Open Binaries and part of the policy is that the distributed artifact is first and foremost a buildable source tarball. Without it, it is not a release. You may have system requirements (thou shalt need Maven 2.0.6 or 2.0.9 ) and you should provide full build instructions to produce the projects binary. And if you distribute a binary, it should be the same thing that gets produced by following your instructions. And the above is not really up for debate either. At the end of the day, people will rely on tarballs, checksums (download integrity) and signatures (manipulation integrity), and those are the primary artifacts that Apache Infrastructure will archive and get mirrored around the world. Maven artifacts are really nice to have for Maven users, but is exactly that; Nice to have. Now, you are free to go banging on Maven's door that their built-in workflow doesn't support the Apache policy very well. Don't spread FUD like that. You don't have any idea how Maven releases work so I'll take a moment and explain it to you. For a release like Maven we have N modules, where each module produces a JAR, and each of those is released. Each JAR carries with it the POM inside it, but is in a form which can be automatically utilized by IDE integration to automatically be downloaded and integrated with debuggers. All the legal bits are in the JARs and legally intact as it were. The blue print to actually build that individual JAR is in the JAR by default in Maven. You can't just unpack that source JAR and build it and that's for a couple reasons: the first is that it's generally useless and the second is that we create a source archive of the entire release with all the modules which is what we recommend. As with Maven, the tagged sources for the build are distributed along with the binaries. This is a matter of setting up a source assembly, not hard to do. That said, show me any non-Maven project that makes individual JARs that have the capability of rebuilding themselves. There aren't any here at Apache. What gets produced is a overall source archive. And show me anything as advanced and useful to developers where grabbing the source JARs for debugging is transparent or materializing sources from binary artifact coordinates is a button click. Again, nothing does that besides Maven and the corresponding IDE integrations. So Maven adheres to any standard for the overall release but goes way above and beyond to actually produce something far more useful for actually doing work. So please don't try to explain to people what Maven does when you don't actually understand it yourself. What gets released as the N modules is complementary to aggregate release which is compliant with Apache. So if Shindig doesn't have the overarching source archive that's not hard to add. But there is not a single non-Maven build at Apache where a JAR emanating from multi-JAR build where that JAR carries with it the information to build itself. You are confusing an aggregate release with the releases of the individual components which is what Maven users need to consume. We account for both for the case where a user grabs the distribution to use, and the case where someone is building a Maven plugin (most often in an IDE where Maven is not installed) and transparently grabs the dependencies -- the individual JARs from a Maven release -- so they can build their project. We do the necessary and the nice to have. More working developers actually care about the nice to have. They won't be surprised, and IIRC there has been a lot of discussion over there to make it happen. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Ace
On 6-Apr-09, at 12:33 AM, Richard S. Hall wrote: Jason, Although, we keep trying to point out that OBR != p2, you seem to keep missing that point. The argument is not lost on me. That they are not that far apart insofar as providing a repository system with an API to retrieve and manipulate artifacts is the point you are missing. They are not that wildly different and one could either of the easily evolve into the other. That's why I keep pointing it out because when anyone said OBR at EclipseCon the word provisioning always followed in the next sentence. Followed by a comparison with p2. I think both technologies are relevant in any discussion about provisioning OSGi. OBR is a simple repository model and API for accessing it, that's all it is...it is not a provisioning system. As such, OBR has been done for a long time. All other functionality should be hopefully be buildable as layers on top, such as what Luminis has done with their provisioning work. You act like there is some gotcha that OBR is not an OSGi spec, but OBR has always existed outside of the OSGi specs, so who cares? The proposal literally only mentions the letters OBR once as a dependency and nothing more. It is hardly the main selling point. No one was shouting about OBR or p2, that was only you. In a year from now when anyone is talking about provisioning OSGi what do you think the main underlying technologies bases will be? They will be OBR and p2. Either one of them will be expanded and changed and they will be the basis of most if not all provisioning technologies. I think you know that as well as I do. Also, the notion that we should just lay down because we can't compete with some big company and all these man years they have invested is somewhat ridiculous. If we all bought into that, then none of us would be here. As I also stated there are lots of small companies involved as well. I'm just saying pick your battles. Do you think a business manager is going to say Hmm, this system has 5 man years of work in it and is used by a lot of people ... Well let's not consider that because that's ridiculous. Anyone trying to use the technology will not use that argument as a reason not to use it. I'm just saying it's a possible reason for not wanting to develop something else. If this was a proprietary solution not accessible, and not extensible then an open solution would be great, but that's not the case with p2. I would argue it's more of a proprietary case for OBR given the constraints to participate in the forming and implementation of the specification. If you just wanted to point out that p2 should be mentioned as a competing technology in the proposal, I think you could have accomplished that in a more reasonable manner. Maybe. I'm not a dancer. Lastly, it is somewhat difficult for me to take community building lessons from someone who claims to have had an OSGi awakening and is willing to cull all of their own personal projects as a result, yet I can count on probably a couple fingers how many discussions you've instigated (or even responded to) regarding OSGi, OBR, or any topic in the Felix community in all the years it has existed. Heh. I _never_ claimed to be a an example of a good community builder. I wouldn't take any community building lessons from me. I write stuff, if you want to use it great. If you don't it's no skin off my back. That's the extent of my community building skill. On the OSGi front I probably wouldn't be involved in many discussion on the Felix list because I use Equinox. So I don't think that's overly odd. - richard On 4/5/09 2:11 PM, Jason van Zyl wrote: I'm suggesting that you two groups figure out how to work together on a very hard problem. I'm also saying that you are unlikely to out do the 5 man years in p2 already. As I said in the previous email if you want to make a competing system that's fine. But don't couch the proposal as something that's new and hasn't been addressed elsewhere because it has. You might want to be more clear in the proposal about p2 being a competitor, also make it clear that OBR has gone back to specification, and what it is you're actually working from. So when a user or potential developer looks at this and says what specification are you working from they can see there isn't one yet, and if they ask what about p2?, then it's clear you decided not to collaborate with them. I think you can even point out that they didn't collaborate with you either. Give people all the information. When I walked into the OSGi BOF at Eclipse I was dumbfounded. The same dose of sniping and grin fucking as other groups I've worked with which was disappointing but I guess I'm not surprised. There were attacks abound at EclipseCon. The way p2 came into existence probably could have been handled better, no doubt. But I don't
Re: [PROPOSAL] Apache Ace
I know the OBR specification was written years ago, and I'm aware Felix shipped with an implementation of it. As I said Oleg and I looked at it. I honestly just found p2 more useful and couldn't find any real examples of anyone using OBR. I don't know what happened in OSGi land and I honestly don't care about the politics. Something went awry if none of you can work together on this stuff. There is the OSGi Alliance which everyone appears to belong to yet there is a massive dichotomy in the provisioning space. For the record in technology land I'm also trying to cull things I started for which others have made something better. I'll give up the DI bits that I made for Maven and use Guice, and I'll give up the OSGi like runtime model I was working on and just use Equinox. Both projects I started some 5 years ago but someone made something better. I got leap frogged, such is life. OBR may have started first but there's something to be said for IBM, EclipseSource, Yoxos, and Genuitec using this stuff in day-to-day production. Much of it is not pretty but that's what happens when you have to ship software for living. I just hope that someone in the mix tries to reconcile the different camps. I think there is a good opportunity to use the massive amount of information that the p2 community has gained trying to make a system that services such a gigantic community like Eclipse users along with the server side work that's been done. I think p2 embodies my favorite quote about developing software: People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks I think the incomplete work of OBR which has good ideas and the massive amount of practical work in p2 can be combined to make a better system. On 4-Apr-09, at 7:47 PM, Richard S. Hall wrote: On 4/4/09 7:09 PM, Jason van Zyl wrote: On 4-Apr-09, at 12:30 PM, Marcel Offermans wrote: Hello Martin, On Apr 4, 2009, at 20:39 , Martin Cooper wrote: On Thu, Apr 2, 2009 at 12:52 PM, Marcel Offermans marcel.offerm...@luminis.nl wrote: Hello all, I would like to formally present the incubator proposal for Apache Ace, a software distribution framework based on OSGi that allows you to manage and distribute artifacts, like e.g. software components. The full proposal can be found on the wiki at: http://wiki.apache.org/incubator/AceProposal I'm looking forward to all questions and feedback, positive or negative. Could you comment on how this compares to Equinox p2? It'd be interesting to understand the similarities and differences. Let's start with the similarities. Both systems are designed to distribute software components, and both are based on OSGi. Equinox p2 was designed to replace the aging Update Manager in Eclipse. It focusses on installing Eclipse-based applications from scratch and updating them and can be extended to manage other types of artifacts. If you look at the agent part, it is geared towards desktop environments Not true. Jeff McAffer's demo at EclipseCon is a case in point. He provisioned an EC2 node using p2. Jeff's goal from the start with p2 was provisioning server's. Anyone looking at the mailing lists would know this. Much of what he showed was the dynamic discovery of nodes for provisioning from the server side. Now Pascal may have focused on desktop and SDK provisioning but Pascal was not the only one involved. Jeff is very much focused on server side provisioning as am I. (their agent download is about 12 MB) and focusses on having a user on the target system selecting the components or plugins that need to be installed or updated. Looking at the server side, they manage update sites that contain the files the agent can download. As far as I know they don't yet have tooling to show an overview of all targets, nor ways to directly monitor or manage them. Apache Ace was designed to be a framework for provisioning based on OSGi standards (whenever available). The agent is small (100kB) and is based on OSGi's DeploymentAdmin which also allows you to install any type of artifact in an extensible way. Being that small, it can also run on small targets like embedded systems and mobile phones. We also don't assume a user on the target system. On the server side, we support OSGi's Bundle Repository (OBR) and we can actively manage targets and push software onto them without user interaction. Also, you can have a central overview of these targets and their complete life cycle. There are even mechanisms
Re: [PROPOSAL] Apache Ace
On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote: Hello Jason, On Apr 5, 2009, at 1:09 , Jason van Zyl wrote: Equinox p2 was designed to replace the aging Update Manager in Eclipse. It focusses on installing Eclipse-based applications from scratch and updating them and can be extended to manage other types of artifacts. If you look at the agent part, it is geared towards desktop environments Not true. Jeff McAffer's demo at EclipseCon is a case in point. He provisioned an EC2 node using p2. [...] Jeff is very much focused on server side provisioning as am I. Let me rephrase that, it's geared more towards desktop and server environments, as compared to smaller (embedded, mobile) environments. That was the point I was trying to make here. Note though, I'm no Equinox p2 expert. :) Then why are you proposing this when you don't even know what p2 is capable of? We started working on this system when p2 did not even exist. I even remember talking to Jeff in those days about our system, but they decided to make their own, so you could equally well make this argument the other way round. I'll use the same story I used on Richard. I created a DI and runtime system 5 years ago. So what. Guice and Equinox have a massive user community, professional support is available for both and so I will cull the technologies I developed. I don't think it really matters so much who was first but who got to a production system first that is known and support by thousands of users. It's just my opinion but anyone doing provisioning with OSGi has had their asses handed to them on a plate by the p2 guys. In my opinion, p2 is fine if you are already doing everything the Eclipse way and are targetting desktops and servers. There are however other types of systems that need provisioning, and Apache Ace tries to cater for those too. Again you haven't really even looked at p2. What is the Eclipse way ? You're going to make/keep another system entirely because it's the Eclipse way ? I've seen JBoss and Tomcat servers provisioned with p2 so I'm not sure what the Eclipse way means. I'll repeat again that p2 is not targeting desktops whatever aspects may appear most visible right now. I really don't think there is a system that couldn't be provisioned even with p2 in its current state. I have personally not found one yet. Oleg and I were trying to make something and after looking around at everything -- and we did look at OBR -- we decided that p2 was good enough and we would help improve that. OBR is a repository for components, augmented with metadata that describes dependencies. As such it's not a provisioning system, so in my opinion you should not compare it to p2. There's nothing wrong with competition but I think anyone doing OSGi provisioning is just going to look around in a year and find p2 has 95% of the market. It's a complicated problem and I think p2 is a solid base and be improved and adapted to support things like OBR or anything else including non-OSGi systems. Nobody can look into the future, and since both p2 and Ace are indeed software provisioning solutions, there will definitely be overlap in features. There are also differences though. In the end, the users will decide what they like best. There's no doubt they will. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Ace
I'm suggesting that you two groups figure out how to work together on a very hard problem. I'm also saying that you are unlikely to out do the 5 man years in p2 already. As I said in the previous email if you want to make a competing system that's fine. But don't couch the proposal as something that's new and hasn't been addressed elsewhere because it has. You might want to be more clear in the proposal about p2 being a competitor, also make it clear that OBR has gone back to specification, and what it is you're actually working from. So when a user or potential developer looks at this and says what specification are you working from they can see there isn't one yet, and if they ask what about p2?, then it's clear you decided not to collaborate with them. I think you can even point out that they didn't collaborate with you either. Give people all the information. When I walked into the OSGi BOF at Eclipse I was dumbfounded. The same dose of sniping and grin fucking as other groups I've worked with which was disappointing but I guess I'm not surprised. There were attacks abound at EclipseCon. The way p2 came into existence probably could have been handled better, no doubt. But I don't find guys like Hal very compelling with his melodrama (http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html ). Make it clear to people looking at the proposal that provisioning is a hard problem. These arguments about the Eclipse way of p2 and non- focus on server side or other types of systems is nonsense. If you actually have a pointer to p2 in your proposal -- which is conspicuously absent -- siting them as a direct competitor users will have a clear point of reference. If people had the background story they will probably go WTF just like I did. Both sides of the p2/OBR seem to be equally obstinate and non- collaborative. I used p2 because from a technical level as an end user because it worked. There are nightly builds, lots of documentation and at least 5 people working on it full-time at any given point in time. If you look at the p2 code and the OBR spec they are 90% the same thing and any differences are easily compensated for with a little effort. Competition is fine, I would just be more open about that aspect of it in the proposal. On 5-Apr-09, at 8:47 AM, Karl Pauls wrote: On Sun, Apr 5, 2009 at 5:00 PM, Jason van Zyl jvan...@sonatype.com wrote: On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote: Hello Jason, On Apr 5, 2009, at 1:09 , Jason van Zyl wrote: Equinox p2 was designed to replace the aging Update Manager in Eclipse. It focusses on installing Eclipse-based applications from scratch and updating them and can be extended to manage other types of artifacts. If you look at the agent part, it is geared towards desktop environments Not true. Jeff McAffer's demo at EclipseCon is a case in point. He provisioned an EC2 node using p2. [...] Jeff is very much focused on server side provisioning as am I. Let me rephrase that, it's geared more towards desktop and server environments, as compared to smaller (embedded, mobile) environments. That was the point I was trying to make here. Note though, I'm no Equinox p2 expert. :) Then why are you proposing this when you don't even know what p2 is capable of? We started working on this system when p2 did not even exist. I even remember talking to Jeff in those days about our system, but they decided to make their own, so you could equally well make this argument the other way round. I'll use the same story I used on Richard. I created a DI and runtime system 5 years ago. So what. Guice and Equinox have a massive user community, professional support is available for both and so I will cull the technologies I developed. I don't think it really matters so much who was first but who got to a production system first that is known and support by thousands of users. Are you suggesting that we shouldn't incubate projects that overlap with an existing production system outside the ASF? It's just my opinion but anyone doing provisioning with OSGi has had their asses handed to them on a plate by the p2 guys. In my opinion, p2 is fine if you are already doing everything the Eclipse way and are targetting desktops and servers. There are however other types of systems that need provisioning, and Apache Ace tries to cater for those too. Again you haven't really even looked at p2. What is the Eclipse way ? You're going to make/keep another system entirely because it's the Eclipse way ? I've seen JBoss and Tomcat servers provisioned with p2 so I'm not sure what the Eclipse way means. I'll repeat again that p2 is not targeting desktops whatever aspects may appear most visible right now. I really don't think there is a system that couldn't be provisioned even with p2 in its current state. I have
Re: [PROPOSAL] Apache Ace
I have no problem with it per se. You guys should go for it. It's your effort and I'm not trying stop you but only draw some attention to the surrounding environment. I think the proposal should attempt to be a little more clear about but that's was a request not something I was specifically asking for. You'll do what you do, if you guys figure stuff out with the p2 guys great. If not, that's fine too. +1 On 5-Apr-09, at 12:50 PM, Karl Pauls wrote: I'm not sure I understand what your problem with this proposal is exactly but I sure would like to. Let me try to get some things clear in order to be able to get to the bottom of this. Don't let any previous comments side-track you and lets try to focus on the proposal: I don't see where the proposal is mentioning OBR in the first place. Let alone where it would say anything about it being a standard or anything. Its only listed as an external dependency. There is no pointer to OBR (other then that it is a dependency) nor is there a pointer to p2. That is not suspicious as the project is not about any of the two other then it should be able to use obr and p2 repositories and infrastructure where it makes sense. I completely agree that it would be great if there would be an active and healthy collaboration between the projects but I'm not sure this has to be in the proposal. It certainly doesn't say anything to the opposite (unless I'm missing something?). Finally, the proposal already does say: When assembling software out of reusable components, the task of deploying software onto an ever increasing number of targets is not trivial to solve. This becomes even harder when these targets require different components based on who's using them. What else do you think is necessary to make it clear that provisioning is a hard problem as you say? From this point, would you say that what you like to see is a paragraph that mentions that the current luminis implementation uses OBR and that the project will look into using p2 as well? I'm sure that this can be arranged. regards, Karl I'm suggesting that you two groups figure out how to work together on a very hard problem. I'm also saying that you are unlikely to out do the 5 man years in p2 already. As I said in the previous email if you want to make a competing system that's fine. But don't couch the proposal as something that's new and hasn't been addressed elsewhere because it has. You might want to be more clear in the proposal about p2 being a competitor, also make it clear that OBR has gone back to specification, and what it is you're actually working from. So when a user or potential developer looks at this and says what specification are you working from they can see there isn't one yet, and if they ask what about p2?, then it's clear you decided not to collaborate with them. I think you can even point out that they didn't collaborate with you either. Give people all the information. When I walked into the OSGi BOF at Eclipse I was dumbfounded. The same dose of sniping and grin fucking as other groups I've worked with which was disappointing but I guess I'm not surprised. There were attacks abound at EclipseCon. The way p2 came into existence probably could have been handled better, no doubt. But I don't find guys like Hal very compelling with his melodrama (http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html ). Make it clear to people looking at the proposal that provisioning is a hard problem. These arguments about the Eclipse way of p2 and non- focus on server side or other types of systems is nonsense. If you actually have a pointer to p2 in your proposal -- which is conspicuously absent -- siting them as a direct competitor users will have a clear point of reference. If people had the background story they will probably go WTF just like I did. Both sides of the p2/OBR seem to be equally obstinate and non- collaborative. I used p2 because from a technical level as an end user because it worked. There are nightly builds, lots of documentation and at least 5 people working on it full-time at any given point in time. If you look at the p2 code and the OBR spec they are 90% the same thing and any differences are easily compensated for with a little effort. Competition is fine, I would just be more open about that aspect of it in the proposal. On 5-Apr-09, at 8:47 AM, Karl Pauls wrote: On Sun, Apr 5, 2009 at 5:00 PM, Jason van Zyl jvan...@sonatype.com wrote: On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote: Hello Jason, On Apr 5, 2009, at 1:09 , Jason van Zyl wrote: Equinox p2 was designed to replace the aging Update Manager in Eclipse. It focusses on installing Eclipse-based applications from scratch and updating them and can be extended to manage other types of artifacts. If you look at the agent part, it is geared towards desktop environments Not true. Jeff
Re: [PROPOSAL] Apache Ace
There's nothing for me to be insincere about. Beyond providing some context for most people that don't know I am not going to expend any effort on implementation, but I would be happy to talk about the problem of provisioning which is why I gave a +1. So it's in the hands of those that care. If folks want to do the work then I do feel they should go for it. I saw the proposal, someone mentioned p2, I use p2, I gave my opinion. I would only ask that these proposals have a little more clarity, context, and honesty. Everyone seems to know exactly what I'm talking about with respect to p2 yet none of that is reflected in the proposal. It's a little like dealing with patent lawyers: this system uses 4 bits, not 5 so it's completely different, lightweight and orthogonal. A little background on OBR and p2 could only be helpful for people trying to understand the landscape while reading the proposal. As for my agenda, there's nothing that isn't public. Sonatype has implemented a product that supports p2. We actually haven't done any work on p2 itself yet but we probably will in the next 6 months. We effectively created a product in a very short period of time and it was at the behest of our clients. So I would relay that to people: p2 is a viable platform. That said insofar as Nexus goes it would take a week to implement support for a completely different system so we're not wedded to p2 as a business model. If p2 disappeared tomorrow it's not of any particular consequence to Sonatype so talking about p2 is nothing more then me being a very happy user. p2 just happens to be what our clients are asking for so we created support for it on the server side. I recommend p2 to folks looking at provisioning. All publicly stated. If that's an agenda then I guess I have one. I think p2 is solid and pretty advanced and if I am genuinely in anything it's asking, for your sakes, not to make something that no one is going to use. That's my agenda if I have one. You've got IBM and Redhat and a slew of other companies (lots of small ones too) working on it, it's all there to look at and the code is not terribly hard to work with. You could make any provisioning system with it including anything you're talking about here. If you guys want to work on something else, seriously, go for. I'd be happy to share use cases as we've dealt with 5 all the way up to 3k machines. On 5-Apr-09, at 6:40 PM, Niclas Hedhman wrote: On Mon, Apr 6, 2009 at 2:11 AM, Jason van Zyl jvan...@sonatype.com wrote: As I said in the previous email if you want to make a competing system that's fine. But don't couch the proposal as something that's new and hasn't been addressed elsewhere because it has. Jason, I don't know why you got so worked up over this proposal. You seldom raise your concerns here, and when you do it this loudly, it sounds like you are on an agenda, and with your recent commitment to Eclipse Foundation, such suspicion is yet stronger. I will assume that is not the case. And in the end, you make a turn-around and say You guys should go for it.. I hope that is sincere. It is barely the first time a project is overlapping or competing with a known large project. And whether or not P2 covers the same space or not is also fairly irrelevant. As for the argument; 95% will use Eclipse... Even if that would be true, it is irrelevant and you if anyone should know that. Ant had close to 100% of users in Java-land and won Best Software kind of awards all over the place, by the time you started Maven. Should that argument have stopped you from trying? Do you regret that Maven started? I also find OBR vs P2 argumentation being a non-issue. Ace can in principle work with both, if the community choose to support P2. IMHO, P2 is fairly heavy and not suitable for many people. And I don't like to live in the world with 'single choice', where a faceless mob has made my choice out of numbers alone. I happen to choose the technology that best suits _my_ needs. Some years ago that was Maven over Ant, now it is IDEA over Eclipse, Jetty over Tomcat for tests, and so on... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Re: [PROPOSAL] Apache Ace
because it seems to me like a lot of people talked about OBR but didn't really implement anything. I don't think the p2 folks wanted to get into a 6 month discussion about the XML format of repository metadata and so they might have been a little brisk but what's done is done. If you want to compete just be clear about it because from where I'm sitting you haven't talked about anything I haven't seen done with p2 -- I'm talking about building on p2 here. It's just my opinion but anyone doing provisioning with OSGi has had their asses handed to them on a plate by the p2 guys. Oleg and I were trying to make something and after looking around at everything -- and we did look at OBR -- we decided that p2 was good enough and we would help improve that. p2 is going to have hundreds of millions of users via Eclipse pretty shortly and server side management systems are already cropping up and p2 can be built upon to handle these requirements. People can point at the horrible things that have happened with p2 lately but it's fixed quickly and that's life when serving out that much content to that many people. There's nothing wrong with competition but I think anyone doing OSGi provisioning is just going to look around in a year and find p2 has 95% of the market. It's a complicated problem and I think p2 is a solid base and be improved and adapted to support things like OBR or anything else including non-OSGi systems. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Maven for incubating projects
On 19-Feb-09, at 11:37 AM, Jukka Zitting wrote: Hi, On Thu, Feb 19, 2009 at 5:35 PM, Bob Schellink sab...@gmail.com wrote: Seems there was a recent update in policy that incubator projects can be pushed to the central repository? So we can copy Click maven artifacts to '/www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/ click/'? Use the Ant tasks to deploy them properly, or if you're using Maven do a proper release. Do not just copy files into the repository as we're going to start getting strict. If you have bad poms, invalid checksums, or missing signatures they will not get synced to central. Yes. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com http://twitter.com/jvanzyl -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Cassandra into the Incubator (Summary)
+1 Brian's response clarified the situation for me. On 28-Dec-08, at 7:29 PM, Ian Holsman wrote: After 5 days, the following is the vote summary of the binding votes (apologies if I missed your vote in advance). +1: (5) Brian, Ian, Otis, Dims, Emmanuel +0: (2) Bertrand, Torsten -1: (1) Niclas ?: Jason, Martijn, Matthieu (commented but no vote) The only concern on the voting process was that it was started on the 23rd (GMT) and that people were not given enough time. I extended the vote for 2 more days to help alleviate that. I'll leave it up to the PMC/board if they consider this sufficient, as they can invalidate the vote on those grounds (possibly others that i'm not aware of too). I would like to say In defense of the vote, that of the people who discussed the Cassandra proposal since it was proposed on the 2nd, only two (Paul Roland) have not voted/commented. According to my notes, only Paul has a binding vote and has been active on other apache threads during the period that the vote was being held. Regards Ian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Cassandra into the Incubator
On 26-Dec-08, at 3:31 PM, Torsten Curdt wrote: [ ] +1 Accept Cassandra as a new podling [ ] -1 Do not accept the new podling (provide reason, please) -1 (binding). I will even give reasons because it is Christmas; a. See Martijn's concern. b. Running vote over Christmas when *many* people are busy with other things. c. I would like to see a proposal with more meat in it. Some history, more elaboration on the various topics that the template provides... Just a different perspective: a) I agree with the concern but as Martijn expressed, I'm not sure it should be a real concern for the vote. If the project dies, so be it. But clearly a few individuals seem to care so why not giving them a chance? b) +1 on this one, it could just be balanced by setting a longer than usual voting time frame. c) I agree although some feedback has been provided on the ML, it could be nice to bring back some of that in the proposal. Some thoughts from this end: I also have the feeling that the proposal could benefit from some more meat. The timing around Christmas indeed was not very helpful either. But what really concerns me a bit is the question whether people really want to/can work together. It seems like the fork / The word fork does not appear in the proposal, but at the very top of the proposal it says it started at Facebook. I just read the proposal and a few emails today so I don't know anything about the project but that immediately says to me there is some disparity. If it's a fork that's fine, but that's something pretty important to leave out of the proposal. non-fork debate already left some scars and I am not eager to invest time when people can't get along even to begin with. Maybe my Avalon alarm is set a little too sensitive but for now I only vote +0. Ian, since you are the one driving this... would you mind working with the project team on improving the proposal? ...and then consider a re-submit? cheers ...and Merry Christmas -- Torsten - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Continuous Build environment?
On 17-Dec-08, at 6:26 AM, Niklas Gustavsson wrote: On Wed, Dec 17, 2008 at 9:11 AM, Jason van Zyl jvan...@sonatype.com wrote: I've never tried hooking up agents to more then one master, but if that works sure. Oh, that was not really my question. I was wondering if we could install separate agents that would be controlled by the Apache Hudson? Hudson is pretty light weight so we could try that too. /niklas - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Continuous Build environment?
We're still trying to figure out how the machine is being utilized but we can offer up some space for Apache projects that are interested using the grid Sonatype has setup for Maven: http://grid.sonatype.org/ci/view/Maven%203.0.x/job/maven-3.0.x-bootstrap/123/ We've got Ubuntu, CentOS, Vista, OSX (a mac mini plug into the rack), and Solaris nodes working. I'm sure we can spare some cycles, the machine is a monster. On 12-Oct-08, at 11:29 AM, Niclas Hedhman wrote: Anyone has information about this?? Cheers Niclas -- Forwarded message -- From: James Dixson jadix...@cisco.com Date: Sun, Oct 12, 2008 at 9:48 PM Subject: Continuous Build environment? To: etch-...@incubator.apache.org Does Apache have build-environment resources that we could leverage? Perhaps a shared Atlassian Bamboo or Apache Continuum or similar? We are currently doing Etch builds continuously, but the build server is locked behind our firewall here at Cisco. I would prefer to be able to have the builds manageable by non-Cisco folks. I would like to see us building continuously on Windows and Linux and OSX. -- James - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Incubator Project Dissolution for NMaven
Do we have an official process for dissolving a project in the incubator? We had a vote amongst the IPMC members for NMaven yesterday and 3/4 IPMC members voted to dissolve the NMaven project and take it out of the incubator. Is there any official process or do we just update the documentation? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Project Dissolution for NMaven
On 13-Nov-08, at 2:23 AM, Niclas Hedhman wrote: On Thu, Nov 13, 2008 at 6:50 AM, Jason Van Zyl [EMAIL PROTECTED] wrote: Do we have an official process for dissolving a project in the incubator? We had a vote amongst the IPMC members for NMaven yesterday and 3/4 IPMC members voted to dissolve the NMaven project and take it out of the incubator. Uhhh I have not seen any vote regarding NMaven in the Incubator PMC. I must assume you meant PPMC or perhaps even Maven PMC. Sorry, the NMaven IPMC. Is there any official process or do we just update the documentation? I think that you have Incubator PMC consensus, so unless someone yells, documentation needs to be updated. Off my head; * STATUS page - Add a note that it is retired. * Website (if any), saying that Incubation retired. * site-author/stylesheets/project.xml - Remove NMaven link. * site-author/projects/index.xml - Move it to Retired section. * Reporting Schedule - http://wiki.apache.org/incubator/ReportingSchedule Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Project Dissolution for NMaven
On 13-Nov-08, at 2:16 AM, Martijn Dashorst wrote: Depends on what take it out of the incubator means: - graduation to TLP - graduation to sub project - stop incubation altogether and possibly continue elsewhere Take it out of the incubator and Apache all together. Graduation is covered in the graduation guide [1], stopping (aka failing) is not covered in a guide (yet). I assume a formal vote on general@ might be in order, and when that is completed, all resources should be shelved: svn - attic, status page - set status to stopped/failed, remove project from reporting schedule, remove project from active project list on site, add to stopped/failed project list. Close down wiki, update project site to reflect status. Martijn On Thu, Nov 13, 2008 at 4:27 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Do we have an official process for dissolving a project in the incubator? We had a vote amongst the IPMC members for NMaven yesterday and 3/4 IPMC members voted to dissolve the NMaven project and take it out of the incubator. Is there any official process or do we just update the documentation? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Incubator Project Dissolution for NMaven
Do we have an official process for dissolving a project in the incubator? We had a vote amongst the IPMC members for NMaven yesterday and 3/4 IPMC members voted to dissolve the NMaven project and take it out of the incubator. Is there any official process or do we just update the documentation? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Incubator Project Dissolution for NMaven
Do we have an official process for dissolving a project in the incubator? We had a vote amongst the IPMC members for NMaven yesterday and 3/4 IPMC members voted to dissolve the NMaven project and take it out of the incubator. Is there any official process or do we just update the documentation? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Jukka, Are you intending here to just redirect poddlings distribution management to: http://people.apache.org/repo/m2-ibiblio-rsync-repository/ Do you want me to sync the existing repository here: http://people.apache.org/repo/m2-incubating-repository/ to http://people.apache.org/repo/m2-ibiblio-rsync-repository/ Or are you handling that? On 13-Oct-08, at 4:00 PM, Jukka Zitting wrote: Hi, On Mon, Oct 13, 2008 at 3:30 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Just a final heads up that, based on the majority vote, I will be implementing this policy change tonight unless anyone wants to propose an alternative policy. See revision 704280. It is now OK for podlings to deploy approved releases (that satisfy the labeling and disclaimer requirements) to the central Maven repository through m2-ibiblio-rsync-repository. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
The central repository is not an Apache project's resource. We've always discussed issues of the central repository in private (except for technical details of syncing other project repositories) and as far as policy goes it's the Maven PMC that will sets it. Members can see the list and we're fine with that. We already know what everyone and their uncle wants and it's unlikely a productive discussion will ensue. You just have to look here to see that. We're not wasting our time in endless debate. We'll decide, take feedback, adjust, and move on. We're actually going to setup a group call to discuss the issues on the table. So by next week we'll stuff for people to discuss. As far as Maven development goes, we work like just like every other project, the repository is different and affects every project and organization. What we are deciding is beyond the realm of Apache. On 7-Oct-08, at 11:23 AM, Doug Cutting wrote: Jason van Zyl wrote: The central repository is the Maven PMC's business. What results will be public policy but we'd like to avoid the banter of the misinformed so we can arrive at a decision quickly. I'd love to avoid the banter of the misinformed too, but that's not the way Apache projects are supposed to work, is it? Private lists should only be used for things which cannot be discussed in public, e.g., personnel issues, security breaches, etc. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of PGP support in Maven
On 6-Oct-08, at 10:21 AM, Noel J. Bergman wrote: Niclas Hedhman wrote: Being in the camp I hate Maven too I hate Maven's lack of authentication, the potential for widespread damage, and am immensely frustrated by their *years* of willfully negligent handling thereof. I would like to swap Noel's statement around and ask; Why doesn't security concerned individuals participate in the Maven effort? Lead by example and not by bashing... They have received constructive input for years. They continue to do so. Jason's comments appear to echo the old-school negligence that I'd hoped the Maven PMC was at long last starting to be cured of. Noel, your comments are completely out of whack with reality. You are asking Maven to enforce something that no one does. Pretty much almost no one. Downloads from our own servers: 57.47% archive.apache.org 40.72% www.apache.org ... almost all are zip's and [.tar].gz's (see extensions report) 92.72% .zip [Zip archives] 2.10% .gz [Gzip compressed files] 2.05% .tar.gz [Compressed archives] 0.1% .asc (not even listed) Almost no one is validating PGP signatures. It's not that we couldn't in the past, we just had to choose to implement features that delivered what our users wanted. Checking PGP signatures is obviously not something the vast majority of people do. So pointing your finger at us and calling it negligence is not even remotely correct. The same goes the checksums which people also don't check but Maven does this automatically so we are, in fact, providing a greater degree of security to the average user. By default as a big warning message appears and you can optionally fail builds if the checksum fails. After having a discussion with Henk about the nature of PGP usage and checksums I share his sentiments which he has allowed me to quote: -- In the past I have maintained that the most important reason to sign stuff is to protect the /ASF/ (as opposed to downloaders). People trust the ASF to detect malware (trojans etc) and react upon detection. For downloaders, a simple md5 check should be sufficient. The ASF should be as cautious/suspicious as the most cautious/suspicious downloader imaginable. Are we ? -- Another reason: one day some computer science class is going to compare various open-software centers (like the ASF) on how well such centers protect themselves against malware. The ASF should be examplary. Are we ? When Mercury is integrated into Maven and people can optionally fail builds on failed PGP sig validation Maven will again provide a greater degree of security given that the practice of validating sigs is pretty much non-existent. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
The central repository is the Maven PMC's business. What results will be public policy but we'd like to avoid the banter of the misinformed so we can arrive at a decision quickly. On 6-Oct-08, at 10:22 AM, Noel J. Bergman wrote: Jason van Zyl wrote: The discussions are taking place on the Maven PMC list. If you are a member you can join the list. Why are those discussions taking place on a private, closed, list instead of an open one? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On 7-Oct-08, at 12:02 AM, Niclas Hedhman wrote: On Tue, Oct 7, 2008 at 11:47 AM, Jason van Zyl [EMAIL PROTECTED] wrote: The central repository is the Maven PMC's business. What results will be public policy but we'd like to avoid the banter of the misinformed so we can arrive at a decision quickly. Yes, although the PMC is expected to do all non-sensitive discussion on the public dev@ list. But, so far I think the central repo has served the Java communities (not only Apache) very well. It allows sync'ing from other repository hosts, which has made life a lot easier for smaller projects. That said, I think that Maven should move away from a central repository, and instead go with distributed ones and possibly harness the power of search engines (Yahoo RDF?) to locate stuff everywhere. This is already possible with Nexus (http://nexus.sonatype.org). Nexus, or the Nexus CLI tool, produces a Lucene index which Nexus uses to create a federated searching and retrieval mechanism. One instance of Nexus can proxy any other Maven repository -- a repository manager or normal webserver -- and with the presence of the Nexus index allows federated searching and retrieval of artifacts through that single instance. Some groups are already starting to provide Nexus indices: http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexed+Maven+Repositories This means you as a user can setup Nexus locally, create proxied repositories and get access to the contents of those repositories. So if everyone did this we could federate all the repositories around the world and then central just becomes a switchboard. This would be great as it would distribute the load around, but I think we still might want to collect everything in one place for safety. To be able to do that securely, some clever security mechanisms must first be developed, and since that is in line with security-concerned people, I think it is a good thing to do so. How hard can it be?, considering the expertise around detailing the requirements almost at code level, right ;-) ? Mercury will support PGP validation, and we are building support for PGP into Nexus so the indices could be retrieved and validated, and subsequent retrieval of artifacts could then also be validated. The technology is pretty much there to do what you're asking for but producing the indices in all the repositories will take time. But people are doing because it also provides value in the IDEs. m2eclipse, Netbeans, and IDEA are already integrating Nexus index technology to provide full POM auto-completion support, and we also use the index to find Maven plugins, Maven archetypes, and flag artifacts as having sources, javadocs, and valid checksums and signatures. So people will create indices to get the value in IDEs and as a consequence federating everything is possible. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
The discussions are taking place on the Maven PMC list. If you are a member you can join the list. On 4-Oct-08, at 8:31 AM, Gilles Scokart wrote: 2008/10/3 Jason van Zyl [EMAIL PROTECTED]: On 2-Oct-08, at 9:19 PM, Noel J. Bergman wrote: Emmanuel Lecharny wrote: Better a bad decision than no decision, otherwise, soon, nobody will vote anymore... Not really. Consider that there appears to be a clear consensus that if Maven were to fix the download situation, requiring that users approve the user of Incubator artifacts, rather than transparently use them, many of the -1 would be +1. That's unlikely to happen. We're not going to be implementing policy enforcement for you. Our opinion is forming in the Maven PMC that we will not enforce third party policy but will adhere to the legal distribution rights set forth by the license. All PMC members who have voiced an opinion thus far have this opinion, Where does this dicussion took places? Is there a thread we can read? but we are scheduling a call for next week and we will have a decision and stated policy shortly. We will keep you posted when we reach a decision. It appears that the Maven community is finally getting a clue, and we can hope for a resolution, perhaps 6 months out or less if they don't falter. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On 2-Oct-08, at 9:19 PM, Noel J. Bergman wrote: Emmanuel Lecharny wrote: Better a bad decision than no decision, otherwise, soon, nobody will vote anymore... Not really. Consider that there appears to be a clear consensus that if Maven were to fix the download situation, requiring that users approve the user of Incubator artifacts, rather than transparently use them, many of the -1 would be +1. That's unlikely to happen. We're not going to be implementing policy enforcement for you. Our opinion is forming in the Maven PMC that we will not enforce third party policy but will adhere to the legal distribution rights set forth by the license. All PMC members who have voiced an opinion thus far have this opinion, but we are scheduling a call for next week and we will have a decision and stated policy shortly. We will keep you posted when we reach a decision. It appears that the Maven community is finally getting a clue, and we can hope for a resolution, perhaps 6 months out or less if they don't falter. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of PGP support in Maven
On 3-Oct-08, at 10:50 AM, Noel J. Bergman wrote: Moved to the thread it belongs in ... Jason van Zyl wrote: Noel J. Bergman wrote: Emmanuel Lecharny wrote: Better a bad decision than no decision, otherwise, soon, nobody will vote anymore... Not really. Consider that there appears to be a clear consensus that if Maven were to fix the download situation, requiring that users approve the user of Incubator artifacts, rather than transparently use them, many of the -1 would be +1. That's unlikely to happen. We're not going to be implementing policy enforcement for you. We don't need for you to implement any policy other than the requirement for users to approve authorized signing keys. You simply need to implement artifact signing and mandatory authorization, which is why I've moved this to the thread Brett started for purposes of discussing signing. You are not the Incubator PMC, and what the Incubator says they require is far from clear. Disclaimers, notices, PGP keys. No one knows what anyone wants here. No one can follow these discussions. There will be no mandatory authorization. That will not be turned on by default in the foreseeable future. The tools will exist for people to use as they see fit. It is more likely that people using repository managers will enable this, but it won't be turned on in the Maven client. Oleg, who is responsible for implementing Mercury which has full PGP support, has this functionality working on all branches of Maven but the option to use it will be in the hands of the user. As the quality and tools for supporting PGP get better, and more people use them we will again take a look at the default behavior Did you not see what just happened to Redhat with respect to Fedora? They take artifact security seriously. For a long time, it has appeared that Maven does not, but I am hopeful now that mandatory authorization will appear, so that I and others will not have to increase lobbying efforts to have the Maven repository closed, at least with respect to ASF projects. Lobby away. Close the repository, then what's going to happen? Someone checks out all the sources with a CI system, builds everything and publishes them, then what are you going to do? Shut down anonymous SVN access because people are doing what they can by rights of the license? Track them down and tell them not to do it? Tell the Maven PMC to intervene to stop people from making submissions via JIRA. Stop the repositories that are already syncing Apache artifacts to central or hosting their own repositories? How are you going to stop people from doing this Noel when its their right? You going to lock down everything to the point where no one wants to get involved? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of PGP support in Maven
On 3-Oct-08, at 12:31 PM, Noel J. Bergman wrote: Jason van Zyl wrote: Noel J. Bergman wrote: We don't need for you to implement any policy other than the requirement for users to approve authorized signing keys. You simply need to implement artifact signing and mandatory authorization, which is why I've moved this to the thread Brett started for purposes of discussing signing. You are not the Incubator PMC And where did I imply otherwise?? and what the Incubator says they require is far from clear. Disclaimers, notices, PGP keys. No one knows what anyone wants here. No one can follow these discussions. That's rather over the top. We're talking years here Noel. Point at anything that succinctly states the policy. Doesn't exist. I think if you asked anyone right now they would have no idea what the result is. We had a majority vote, someone on the board said that's the way we should go, some agree, some don't, then you step in and say that's not the way it is because Greg said that's the way it is. It's not meant to be over the top, just a statement of fact. The disclaimer and notice requirements are well documented and have been for a long time. The PGP key situation is under discussion, likely to be resolved by the Infrastructure Team, and will be an ASF-wide issue. The Incubator relationship is that the same mandatory requirement for security that needs to be imposed on Maven can also address the long-standing requirement that users be aware of and accepting that they are using Incubator artifacts. You won't be imposing anything on Maven and what we do with central or what security measures we do, or do not implement. Policy here is, of course, of the IPMC. Turn on/off repositories as you see fit. It's got nothing to do with the way Maven users access the central repository. If you don't want to participate directly making artifacts available then don't. We're not fighting you, and technically we've made it easier for folks to check if there are signatures but lots of projects don't and that's not Maven's problem, it's not Ivy's problem, it's not BuildR's problem. Oleg, who is responsible for implementing Mercury which has full PGP support, has this functionality working on all branches of Maven but the option to use it will be in the hands of the user. As the quality and tools for supporting PGP get better, and more people use them we will again take a look at the default behavior. Did you not see what just happened to Redhat with respect to Fedora? They take artifact security seriously. For a long time, it has appeared that Maven does not, but I am hopeful now that mandatory authorization will appear, so that I and others will not have to increase lobbying efforts to have the Maven repository closed, at least with respect to ASF projects. How are you going to stop people from [creating their own artifacts and repositories] Noel when its their right? We don't have to. We can simply mandate that every ASF project sign their artifacts and charge the Maven PMC with enforcing it. The first part is already mandated, or I certainly thought it was. The second part of that is not going to happen. And perhaps now you start to gain a glimer of the depth of the problem created by Maven's irresponsible, unconscionable, lackadaisical, attitude towards security, despite other repository exemplars (e.g., linux distributions), having had security in place for years. Yes, it may be a bit painful to make the change. On the other hand, imagine the fun when someone puts a nice bit of malware into the security-free zone known as the Maven repository. Not only do I agree with Henning's assessment, I think that network administrators should block the Maven repository at their firewalls. Tell them that. See what they do. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: On incubating releases
On 27-Sep-08, at 9:05 PM, Davanum Srinivas wrote: Unfortunately a typical response from you. Guess there's no point in even trying.. Where the line of reasoning is unsound and shows a cavalier disregard for users there would be no point. I am a practical person above all else, and I listen and do where it makes sense. I didn't make a huge fuss while people were hurling insults at Maven developers and the PMC about the PGP nonsense, I had someone implement a solution and now it's done. There is full support in the new artifact/transport layer called Mercury for on the fly generation and validation of PGP keys. A rework was being done anyway, not hard to add. The argument about redistribution where the license already clearly embodies the policy is what I find inane. The practical solution to that is that I've asked Maven PMC member to read up on this list and hope to have a vote next week about what our stand is on third party policies which contravene distribution rights provided by an artifact's license. Whether that be restricting distribution or the addition of requirements. I really don't want to get into the policy business because if we set the precedent of making an exception for the Apache Incubator it will never end. The best I think we can do is follow the law. If you want a different distribution policy for incubating artifacts or have additional requirements then make an addendum to the license. If the decision is to allow third party policy to alter standard behavior then the onus will be on the Maven developers to implement a extension point by which you can execute your policy. The onus will be on policy creators to implement the policy enforcement. If we allow these changes then the Maven developers cannot be responsible for implementing policy enforcement for everyone that asks. That just doesn't scale and it's not our job. And we will also need help with development resources to ensure that policies can't easily be knocked out and circumvented which will require testing and I assume all those in favor here will be completely willing to help implement and test these policy enforcement mechanisms. If the decisions is not allow policy to alter the rights of the already defined license, then we sync everything. Life goes on. -- dims On Sat, Sep 27, 2008 at 8:25 PM, Jason van Zyl [EMAIL PROTECTED] wrote: On 27-Sep-08, at 7:46 PM, Davanum Srinivas wrote: Jason, Exactly why in previous discussions i already asked...Can the maven folks provide another way to do this? (not showing disclaimers necessarily, something that the user has to do one time works too. Example: apt-get and keys) We could do anything, but I'm not implementing pop ups. But you can. On a download event the build could stop and make people read An ode to the Incubator: How important we are, and how like children you all are. Or we could make them listen to that enduring audio classic: Did someone in the incubator just make something up that no one has ever heard of before? That one always makes me laugh (cry). Maybe we can humor the users in the hopes they don't get pissed off with us because we intentionally made things harder then they have to be. I'll hope that people rely on the same tool that keeps them from sniffing the ends of loaded shotguns, or bathing with toasters. That would be the brain. -- dims On Sat, Sep 27, 2008 at 7:30 PM, Jason van Zyl [EMAIL PROTECTED] wrote: On 27-Sep-08, at 7:03 PM, Davanum Srinivas wrote: Am asking because, the way the situation is being portrayed is that anyone using maven is totally unable to use the incubator artifacts...that's wrong. It's just amazingly inconvenient. Take the 10 minutes (and that's a conservative number) that every user goes through groping around trying to figure out how setup the repositories and multiply that by 5k (which is not unreasonable for something as popular as JSecurity) and now multiply that by the number of projects and we're literally getting into man years of wasted time. To consciously inflict this on people when it's not necessary is exacting a serious amount of damage. Every user who can't build something here as a first time user is going to make their first experience a bad one. For us to pontificate here about how we should be protecting a generally intelligent user base while wasting man years of users' valuable time to me is wrong. thanks, dims On Sat, Sep 27, 2008 at 6:46 PM, Davanum Srinivas [EMAIL PROTECTED] wrote: Jukka, I see where you are going with this. But what i cannot for the life of me understand is why adding a tiny snippet of xml to project B's pom is so objectionable (adding another repo)? No one has yet answered that question for me. thanks, dims On Sat, Sep 27, 2008 at 5:36 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On Sat, Sep 27, 2008 at 11:21 PM, Davanum
Re: On incubating releases
On 28-Sep-08, at 7:33 AM, Davanum Srinivas wrote: You mean the Maven Way or the high way. I think Bill is referring to the ASL Way. We did the VOTE and everyone has stated their opinions. Why bring it up again and again? -- dims On Sat, Sep 27, 2008 at 9:12 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: Fine...Please state your *specific* use case scenario that is problematic right now The problem set is that this thread now exceeds 500 posts in four years, with only one technically appropriate conclusion. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: On incubating releases
On 27-Sep-08, at 4:43 PM, William A. Rowe, Jr. wrote:
Davanum Srinivas wrote:
Because we (Apache) control the distribution channel?
Nope. We control several distribution channels; offhand...
www.apache.org/dist/{tlp}/
- ASF-wide policies (TLP 3x +1, more +1 than -1)
www.apache.org/dist/incubator/podling/
- Incubator policies (+ DISCLAIMER, named -incubator)
maven repository
- Maven TLP (now that ASF has absorbed Maven server)
The ASF has not absorbed the Maven server.
(Not including ASF-wide or per-TLP policies, this is
a common carrier mirror service with minimal necessary
controls.)
There are countless distribution channels that the ASF does not
control, distributing ASF software.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
--
Script timed out
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: On incubating releases
On 27-Sep-08, at 6:13 PM, William A. Rowe, Jr. wrote: Jason van Zyl wrote: maven repository - Maven TLP (now that ASF has absorbed Maven server) The ASF has not absorbed the Maven server. Color me confused for having approved colocation expenses some 2 meetings back. This did not happen or will not happen? This did not happen, and whether it will happen is currently under discussion by the Maven PMC. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: On incubating releases
On 27-Sep-08, at 6:37 PM, Davanum Srinivas wrote: And since we are paying for it...who (maven pmc?) exactly is tasked with taking care of it? I pay for it (which I don't mind, as I consider it part of my obligation to the Maven user base), and Contegix is responsible for taking care of it 24/7. And in recent months with abuse it pretty much takes monitoring all the time, and the general increase in use required us to put in a load balancer, another machine, and a private network for high speed backups. Contegix is an amazing outfit and you'd be hard pressed to find anyone who isn't impressed with them. The central repository is in very good hands. thanks, dims On Sat, Sep 27, 2008 at 6:13 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jason van Zyl wrote: maven repository - Maven TLP (now that ASF has absorbed Maven server) The ASF has not absorbed the Maven server. Color me confused for having approved colocation expenses some 2 meetings back. This did not happen or will not happen? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: On incubating releases
On 27-Sep-08, at 7:46 PM, Davanum Srinivas wrote: Jason, Exactly why in previous discussions i already asked...Can the maven folks provide another way to do this? (not showing disclaimers necessarily, something that the user has to do one time works too. Example: apt-get and keys) We could do anything, but I'm not implementing pop ups. But you can. On a download event the build could stop and make people read An ode to the Incubator: How important we are, and how like children you all are. Or we could make them listen to that enduring audio classic: Did someone in the incubator just make something up that no one has ever heard of before? That one always makes me laugh (cry). Maybe we can humor the users in the hopes they don't get pissed off with us because we intentionally made things harder then they have to be. I'll hope that people rely on the same tool that keeps them from sniffing the ends of loaded shotguns, or bathing with toasters. That would be the brain. -- dims On Sat, Sep 27, 2008 at 7:30 PM, Jason van Zyl [EMAIL PROTECTED] wrote: On 27-Sep-08, at 7:03 PM, Davanum Srinivas wrote: Am asking because, the way the situation is being portrayed is that anyone using maven is totally unable to use the incubator artifacts...that's wrong. It's just amazingly inconvenient. Take the 10 minutes (and that's a conservative number) that every user goes through groping around trying to figure out how setup the repositories and multiply that by 5k (which is not unreasonable for something as popular as JSecurity) and now multiply that by the number of projects and we're literally getting into man years of wasted time. To consciously inflict this on people when it's not necessary is exacting a serious amount of damage. Every user who can't build something here as a first time user is going to make their first experience a bad one. For us to pontificate here about how we should be protecting a generally intelligent user base while wasting man years of users' valuable time to me is wrong. thanks, dims On Sat, Sep 27, 2008 at 6:46 PM, Davanum Srinivas [EMAIL PROTECTED] wrote: Jukka, I see where you are going with this. But what i cannot for the life of me understand is why adding a tiny snippet of xml to project B's pom is so objectionable (adding another repo)? No one has yet answered that question for me. thanks, dims On Sat, Sep 27, 2008 at 5:36 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On Sat, Sep 27, 2008 at 11:21 PM, Davanum Srinivas [EMAIL PROTECTED] wrote: I know...hence my VOTE was what it was. So my questions go out to people who opposed the proposed policy change: 1) Is it OK for project A to bundle the incubating dependency? 2) If yes, why should things be more complex for project B? BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On 10-Sep-08, at 8:34 AM, Jukka Zitting wrote: Hi, We've had a number of long discussions about the incubating projects using the central Maven repository to distribute their releases. The current policy is that incubating releases should not go to there. The related discussion threads have died with no consensus but the issue still exists and affects many podlings. I would like to finally resolve the issue one way or another by calling the Incubator PMC to vote on the matter. In INCUBATOR-82 I have prepared a patch (also attached below) that changes the policy document to explicitly _allow_ extra distribution channels like the central Maven repository for incubating releases. Note that the proposed patch allows any such channels instead of focusing just on the Maven repository. Also, any releases must still be approved, comply with the disclaimer and naming rules, and be primarily distributed through the official http://www.apache.org/dist/incubator/ channel. Please vote on accepting or rejecting this policy change! This majority vote is open for a week and only votes from the Incubator PMC members are binding. [ ] +1 Yes, allow extra release distribution channels like the central Maven repository [ ] -1 No, keep the current policy My vote is +1 BR, Jukka Zitting Patch from https://issues.apache.org/jira/browse/INCUBATOR-82: Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 692094) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -489,6 +489,8 @@ p Releases for empodling/em strongMUST/strong be distributed through codehttp://www.apache.org/dist/incubator/empodling/em/code. +In addition, the Podling MAY choose to distribute approved releases through +other channels like the central Maven repository. /p /section section id=Use+of+Apache+Resources - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
+1 On 10-Sep-08, at 8:34 AM, Jukka Zitting wrote: Hi, We've had a number of long discussions about the incubating projects using the central Maven repository to distribute their releases. The current policy is that incubating releases should not go to there. The related discussion threads have died with no consensus but the issue still exists and affects many podlings. I would like to finally resolve the issue one way or another by calling the Incubator PMC to vote on the matter. In INCUBATOR-82 I have prepared a patch (also attached below) that changes the policy document to explicitly _allow_ extra distribution channels like the central Maven repository for incubating releases. Note that the proposed patch allows any such channels instead of focusing just on the Maven repository. Also, any releases must still be approved, comply with the disclaimer and naming rules, and be primarily distributed through the official http://www.apache.org/dist/incubator/ channel. Please vote on accepting or rejecting this policy change! This majority vote is open for a week and only votes from the Incubator PMC members are binding. [ ] +1 Yes, allow extra release distribution channels like the central Maven repository [ ] -1 No, keep the current policy My vote is +1 BR, Jukka Zitting Patch from https://issues.apache.org/jira/browse/INCUBATOR-82: Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 692094) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -489,6 +489,8 @@ p Releases for empodling/em strongMUST/strong be distributed through codehttp://www.apache.org/dist/incubator/empodling/em/code. +In addition, the Podling MAY choose to distribute approved releases through +other channels like the central Maven repository. /p /section section id=Use+of+Apache+Resources - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Do we really need an incubator?
On 9-Jul-08, at 4:42 PM, William A. Rowe, Jr. wrote: Jochen Wiedmann wrote: On Wed, Jul 9, 2008 at 6:16 PM, Noel J. Bergman [EMAIL PROTECTED] wrote: However, the Maven repository situation has little to do with the need for an Incubator. Obviously you choose to pick out everying Ron's writing about the flaws in Maven / the Maven repository while at the same time carefully ignoring everything he's writing about the necessity of a special incubator repository. I think you need to reread Roy's post, which spelled out exactly why he believes There is no reason for a separate repository. Noel isn't cherry picking, but your comment is flailing about without any contribution to what that necessity actually is. Folks seem to believe maven helps users make decisions about the individual components they want. It does no such thing. It helps users decide to use a particular top level package with all of its warts, wrinkles and obscure dependencies, and *shields* the user from those details. That is not true. We allow the convenience of allowing the specification of compile time dependencies, but the information for the corresponding dependency graph is present and available in tools like m2eclipse: http://docs.codehaus.org/display/MAVEN/Developing+Maven+2.1 That is not obscuring the dependencies in the slightest. The fact is _all_ the dependency information is available. Even on the command line with the -X option you can see what is there. We also have the dependency convergence report which shows everything that's being used. Lots of people are interested in everything they use, and that information is available to users in many convenient ways. The next versions of the visualization will also annotate the origin of a specific artifact. You can take as much or as little. You can override any individual dependency, anywhere in the graph. A lot of people here at Apache are talking a keen interest in Maven. If you don't understand how it works ask because there are lots of people, most likely inadvertently, completely describing Maven's capabilities and behaviors incorrectly. Having a separate repository would actually run against the end user goals for Maven. If they inspect package dependencies, and see foo-incubating rev 0.0.1 or higher in those dependencies, that's all we need to insure. It's no different than encountering thirdparty bar rev 0.0.1 beta or higher. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Again: The Maven Repository
I don't ever recall any discussion that culminated into an official vote. On 3-Jul-08, at 7:46 PM, Noel J. Bergman wrote: Justin Erenkrantz wrote: IIRC, we have voted on precisely this matter in the past. It just seems that the issue will constantly be reopened until folks get their personally desired result. I agree. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] as to Thrift Proposal
+1 On 7-Feb-08, at 4:27 PM, Ted Husted wrote: Here's my binding +1 on the Thrift proposal. On Jan 23, 2008 9:07 PM, Mark Slee [EMAIL PROTECTED] wrote: Hi all, We've just posted the Apache Incubator proposal for Thrift onto the Wiki: http://wiki.apache.org/incubator/ThriftProposal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Jabber Server
On 23 Dec 07, at 10:29 AM 23 Dec 07, Peter Neubauer wrote: Hi there, On Oct 31, 2007, at 4:42 AM, Jason van Zyl wrote: I have the port to Plexus in a tree and I'm sure alag would be fine with it coming along here. Yes, i got that impression too. Guess Alag has no cycles to spare on this and it seems a Apache IM server would be great. Then, does this relate to the Eclipse Communication Framework somehow (which of course uses OSGi as the underlying component model)? Not sure if ECF has a server, but they most certainly can tie into any existing server infrastructure. But this variant of the IM server is set of Plexus components, as they were once a set of Phoenix components. I would be interested in participating in a XMPP project, especially checking out the implications of that for mobile-to-mobile communication and streaming between XMPP peers. /peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Jabber Server
I have the port to Plexus in a tree and I'm sure alag would be fine with it coming along here. On 30 Oct 07, at 8:43 AM 30 Oct 07, J Aaron Farr wrote: Petar Tahchiev [EMAIL PROTECTED] writes: Hi guys, today I was looking for a Jabber server implemented entirely in Java, and the only results that I got was this: ---(free)--- http://www.codecobra.com/chime/ http://www.open-im.net/ OpenIM was originally developed using Apache Avalon containers and now uses Plexus (which is entering incubation). The developer, alag, was a regular on the mailing lists at the time. I'm not sure how active the project is today (looks like it's moved to Codehaus). It's under the MIT license. And while I haven't used this particular feature of ActiveMQ, it does advertise XMPP support: http://activemq.apache.org/xmpp.html -- J Aaron Farr jadetower.com[US] +1 724-964-4515 馮傑仁 cubiclemuses.com [HK] +852 8123-7905 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Composer in the Incubator
On 23 Oct 07, at 5:46 AM 23 Oct 07, Jim Jagielski wrote: On Oct 22, 2007, at 4:55 PM, Jason van Zyl wrote: On 22 Oct 07, at 10:36 AM 22 Oct 07, Jim Jagielski wrote: On Oct 22, 2007, at 12:13 AM, Jason van Zyl wrote: Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. But not all favorably it appears... Was there a particular response you were trying to illicit with that quote? Yes. It's called knowledge and background. What do you want to know? And I can provide any background you feel people should know about. You can't honestly expect to gather a whole lot from a cheeky remark uttered 4 years ago. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Composer dependency on BSH
He meant BSF, though Plexus can optionally use BSH as a component factory. On 23 Oct 07, at 11:48 AM 23 Oct 07, sebb wrote: The Wiki proposal mentions that Composer has an optional dependency on the Apache project BSH. I could not find an Apache project called BSH. Is is then BeanShell (which is not an Apache project) or should it be BSF (which is Apache)? Or perhaps something else entirely? S On 22/10/2007, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, The proposal for Composer has been drafted here: http://wiki.apache.org/incubator/ComposerProposal As mentioned previously, both containers are heavily used, both have always lived as open source projects. Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. [ ] +1 Accept Composer project for incubation [ ] 0 Don't care [ ] -1 Reject for the following reason : Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Accept Composer in the Incubator
Hi, The proposal for Composer has been drafted here: http://wiki.apache.org/incubator/ComposerProposal As mentioned previously, both containers are heavily used, both have always lived as open source projects. Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. [ ] +1 Accept Composer project for incubation [ ] 0 Don't care [ ] -1 Reject for the following reason : Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Composer in the Incubator
On 22 Oct 07, at 10:36 AM 22 Oct 07, Jim Jagielski wrote: On Oct 22, 2007, at 12:13 AM, Jason van Zyl wrote: Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. But not all favorably it appears... I don't think anyone was particularly happy about the outcome of the Avalon project, that quote is probably 4 years old now, and no one is obliged to like everything at Apache. There are lots of things I like, and there are things I don't like. The overriding obligation and responsibility of anyone who has a project here, or wants to put one here, is to make an earnest attempt to improve Apache. There is no one on the list of people in the proposal who thinks otherwise. Was there a particular response you were trying to illicit with that quote? Paul is on vacation, getting drunk, but I'm sure he would respond in the same fashion. I don't think anyone was particularly happy with the outcome of Avalon. Such is life, life goes on, and this is where we are trying to reintegrate this stuff back into Apache. It is also worth noting that Paul got drunk with Aslak to start PicoContainer on the day a world class coder was effectively expelled from Apache. He voted against that action and won't go into details, but believes that it was wrong. [ ] +1 Accept Composer project for incubation [ ] 0 Don't care [ ] -1 Reject for the following reason : 0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Composer in the Incubator
On 22 Oct 07, at 2:14 AM 22 Oct 07, Leo Simons wrote: +1. Really happy to see this happen guys; I wish you all the best and I'm gonna try and track progress even if there's no chance I can find time to actually contribute... I hope the relative lack of controversy around this so far is carried all the way through successful graduation...looking at the list of participants I imagine incubation might go quite quickly :-) Yes, I really see this as IP vetting, and planning on how to migrate users. There's a lot of code, and we have a fair number of users. The complete merger of the code will probably take some time, and it's not necessary to do that in the incubator as it will take quite a while to use a merged container in Maven. I imagine separate releases of the containers will happen for a while as we release merged versions for people to try. I think we'll be out of the incubator very quickly relative to projects coming in with little or no open source experience. On Oct 22, 2007, at 9:13 AM, Jason van Zyl wrote: The proposal for Composer has been drafted here: http://wiki.apache.org/incubator/ComposerProposal As mentioned previously, both containers are heavily used, both have always lived as open source projects. Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. [ ] +1 Accept Composer project for incubation [ ] 0 Don't care [ ] -1 Reject for the following reason : cheers, Leo Simons -- http://www.leosimons.com/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Composer Proposal
There didn't seem to be any curfuffle at all in floating the proposal through the incubator. That's a good thing. Both containers are heavily used, both originate from these parts and so it's somewhat fitting they would like to return. I'll put up vote thread later today. On 8 Oct 07, at 9:54 AM 8 Oct 07, peter royal wrote: On Oct 8, 2007, at 6:54 AM, Noel J. Bergman wrote: I am watching http://wiki.apache.org/incubator/ComposerProposal with some interest. A couple of items: 1) JAMES uses Phoenix, which is the old name for Plexus yes, Loom was unsuccessful Phoenix fork. iirc, Plexus borrowed concepts from Fortress more, but was mostly an independent implementation 2) What about Apache Excalibur, currently home to the various Avalon modules (framework, components, etc.)? Excalibur can continue on as-is.. iirc, Excalibur had made movements to have some of its components be framework agnostic? If so, they'd run in Composer. (the Composer component model is likely going to be very much like pico's, which just runs with pojo's) -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 15 May 07, at 9:57 AM 15 May 07, Shane Isbell wrote: Just to clarify, the implementation is now as follows: NMaven uses the default repo format remotely and then transforms locally; this is the most pragmatic approach, and I don't have any immediate concerns. The problem, however, is that we are exposing the internal schema to the client; this creates a fair amount of confusion as people look for a general schema that satisfies the various languages, as opposed to a general API, say through REST or SOAP. Although HTTP GET with a URL may qualify as an API, I don't think it does. If you're referring to how an actual artifact is retrieve then it should only be via a set of parameters like artifactId, groupId, version, type (optional classifier) and the provider should deal with fetching the said artifact and giving it back to the client. Using an URL as the only way to retrieve an artifact is problematic. So specify the set of parameters you can get an artifact from a Gem repository, CPAN, a Maven repository, or anything else provided you delegated to appropriate provider to deal with repository specifics. The call for a artifact for assemblies or JARs would look the same once you have a reference to the provider. So you would have something like Maven Artifact eventually I would imagine. under its current form its really implementation (file-system) specific. I would be surprised if this issue doesn't keep coming up, as people become interested in using Maven for other languages. Shane On 5/15/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 6 May 07, at 9:13 PM 6 May 07, Carlos Sanchez wrote: I didn't have a chance to talk about this with Shane but the idea in the end is to make the repository agnostic on how things are stored and how the client uses them. Right now is a simple directory, but could be a database with a web front end or anything like that. It shouldn't matter how NMaven artifacts are stored, as long as the client handles them correctly. A solution we talked about time ago was to put them as any other artifacts and either developers could choose what format their local repo is in or the pom could say how they should be stored It all boils down to packaging that's important. It doesn't matter how they are stored. What matters is how they are transformed and I'm sure someone can find a work around for having the name in the assembly manifest being burned in and breaking the linker when the file name and manifest entry doesn't match. The repository can theoretically be stored in anything Wagon supports but it's unlikely we'll stray very far from file-system based mechanisms. But this is a total different discussion On 5/6/07, Daniel Kulp [EMAIL PROTECTED] wrote: Shane, Honestly, it sounds like the NMaven stuff will need a complete new set of repositories for NMaven artifacts. There isn't any way, IMO, that the repo layout can change for the normal maven 1 and maven 2 repositories. Incubator or repo1.maven.org is relatively irrelevant in that regards. The layout is pretty much set in stone. There are too many plugins (deploy, etc...) that rely on it, there are too many other apps (several different proxy applications, etc...) that rely on it, etc... If the current layout is inadequate for NMaven, the NMaven team should figure out an appropriate place for a new repository. My personal suggestion is to work with the Maven team and create a new area at repo1.maven.org/nmaven or similar. But that's me. In either case, I think that discussion is separate from where the m2 artifacts go. It make make sense to put the nmaven stuff in dist/incubator for a while until the layout is finalized, then move to central. However, the layouts for m1/m2 are finalized. Thus, they can/should go to central. (IMO) That said, I don't know the NMaven details. But my #1 concern is your line: I would expect that an incubator release repo would be more amendable to such changes. No chance, IMO. Once an artifact is released, it's SET IN STONE. That includes the layout of the repository it's sitting in. Once theres the possibility that another project is relying on a particular artifact to be living at a particular location, it needs to stay there. The incubator m2 release repository is no different from central in that regard. Dan On Sunday 06 May 2007 14:11, Shane Isbell wrote: [ ] use standard repositories [ x ] relocate repositories under /www.apache.org/dist/incubator My reasons are as follows: First, NMaven does not follow the standard repo layout; second, the repository layout structure is still in a state of flux, meaning that there is a need for potentially changing the layout for .NET artifacts, while still doing releases. Getting more into some more specifics, with NMaven, there is no version information contained
Re: [POLL] Incubator Maven Repository
On 6 May 07, at 11:11 AM 6 May 07, Shane Isbell wrote: [ ] use standard repositories [ x ] relocate repositories under /www.apache.org/dist/incubator My reasons are as follows: First, NMaven does not follow the standard repo layout; second, the repository layout structure is still in a state of flux, meaning that there is a need for potentially changing the layout for .NET artifacts, while still doing releases. Not sure where you're getting the idea the layout may change. We've already had this discussion with .Net folks and the standard directory structure for the remote repositories is not changing. The problem is with the .Net linker and can be worked around with plugins. At least for the Java side of things the version in the JAR is never coming off the file name. If you're referring to something specific proposed for NMaven and a different repository that's one thing, but the structure as it is used currently is not in flux. Not sure where you picked up that notion. At any rate the .Net artifacts can go somewhere else until we figure it out and doesn't affect everyone else trying to deploy. We can make a separate repo until the problems are sorted out with .Net. Getting more into some more specifics, with NMaven, there is no version information contained within the artifact file name and the version must follow a standard 0.0.0.0 format. This precludes the use of incubator within the version itself. As mentioned above, at this early stage, it's also not 100% clear on exactly how NMaven .NET artifacts will reside within the repo. For instance, there is an open question as to where pom files will reside when we add the concept of classifiers to the repo. Also, given the repository layout structure for NET artifacts may change over time, as the incubator project evolves, I have concerns whether any of the standard maven repos would accept - and with good reason - an NMaven incubator release at all. I would expect that an incubator release repo would be more amendable to such changes. Shane On 5/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote: [ x ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 6 May 07, at 8:56 PM 6 May 07, Daniel Kulp wrote: Shane, Honestly, it sounds like the NMaven stuff will need a complete new set of repositories for NMaven artifacts. There isn't any way, IMO, that the repo layout can change for the normal maven 1 and maven 2 repositories. There is already a full proposal by Dan Fabulich of BEA who works extensively with .Net and we've already beaten that horse to death. It's not changing. The assemblies can have their constituents renamed while packaging or they can use a different repository. A system that cannot use version numbers in artifacts is defective IMO, but we'll figure something out. But the chances of changing the existing structure are pretty close to zero. I haven't seen any compelling arguments. Shane, you've looked at Dan Fabulich's document. I assume Brett must have pointed you to it at this point. Incubator or repo1.maven.org is relatively irrelevant in that regards. The layout is pretty much set in stone. There are too many plugins (deploy, etc...) that rely on it, there are too many other apps (several different proxy applications, etc...) that rely on it, etc... If the current layout is inadequate for NMaven, the NMaven team should figure out an appropriate place for a new repository. My personal suggestion is to work with the Maven team and create a new area at repo1.maven.org/nmaven or similar. But that's me. In either case, I think that discussion is separate from where the m2 artifacts go. It make make sense to put the nmaven stuff in dist/incubator for a while until the layout is finalized, then move to central.However, the layouts for m1/m2 are finalized. Thus, they can/should go to central. (IMO) That said, I don't know the NMaven details. But my #1 concern is your line: I would expect that an incubator release repo would be more amendable to such changes. No chance, IMO. Once an artifact is released, it's SET IN STONE. That includes the layout of the repository it's sitting in. Once theres the possibility that another project is relying on a particular artifact to be living at a particular location, it needs to stay there. The incubator m2 release repository is no different from central in that regard. Dan On Sunday 06 May 2007 14:11, Shane Isbell wrote: [ ] use standard repositories [ x ] relocate repositories under /www.apache.org/dist/incubator My reasons are as follows: First, NMaven does not follow the standard repo layout; second, the repository layout structure is still in a state of flux, meaning that there is a need for potentially changing the layout for .NET artifacts, while still doing releases. Getting more into some more specifics, with NMaven, there is no version information contained within the artifact file name and the version must follow a standard 0.0.0.0 format. This precludes the use of incubator within the version itself. As mentioned above, at this early stage, it's also not 100% clear on exactly how NMaven .NET artifacts will reside within the repo. For instance, there is an open question as to where pom files will reside when we add the concept of classifiers to the repo. Also, given the repository layout structure for NET artifacts may change over time, as the incubator project evolves, I have concerns whether any of the standard maven repos would accept - and with good reason - an NMaven incubator release at all. I would expect that an incubator release repo would be more amendable to such changes. Shane On 5/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote: [ x ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 6 May 07, at 4:57 AM 6 May 07, robert burrell donkin wrote: incubator distributions need to be stored under /www/www.apache.org/ dist AFACT there are two reasonable options: either create repositories under /www.apache.org/dist/incubator or use the standard maven ones of course, staging for the purpose of release verification would continue to happen under people.apache.org Wasn't there a vote about this not too long ago? Was that vote not definitive? Jason. - robert [ ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator - 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: [VOTE] Should we treat incubator releases differently to normal releases
On 15 Mar 07, at 9:23 PM 15 Mar 07, Henri Yandell wrote: Two parts to the vote: ONE: Should Incubator tarballs go in the normal place (and thus mirrors). [ ] +1 [ ] -1 +1 TWO: Should there be an Incubator maven repository. [ ] +1 [ ] -1 -1 Vote to last a week. Unless people are bored of replying, or it's a flamefest, or we're too busy pursuing eternal enlightenment and running free in the mountains. Hen - 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: [vote] ActiveMQ Graduation
+1 On 8 Jan 07, at 8:20 PM 8 Jan 07, Brian McCallister wrote: ActiveMQ would like to move to graduate to a top level project, and that the proposal at the end of this email be presented to the board for consideration at the next meeting. Status File: http://incubator.apache.org/projects/activemq.html I will plan on tallying the vote on 1/15/07 (one week from today) in order to allow plenty of time for folks to catch up from the holidays. Thank you, -Brian --- -- Proposal to the Board -- --- Establish the Apache ActiveMQ Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software implementing a distributed messaging system, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache ActiveMQ PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ActiveMQ PMC be and hereby is responsible for the creation and maintenance of open-source software and documentation for a distributed messaging system, based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache ActiveMQ be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache ActiveMQ PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ActiveMQ PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache ActiveMQ PMC: Alan Cabrera [EMAIL PROTECTED] Hiram Chirino [EMAIL PROTECTED] Rob Davies [EMAIL PROTECTED] Matt Hogstrom [EMAIL PROTECTED] David Jencks [EMAIL PROTECTED] Brian McCallister [EMAIL PROTECTED] Aaron Mulder [EMAIL PROTECTED] Guillaume Nodet [EMAIL PROTECTED] John Sisson [EMAIL PROTECTED] Bruce Snyder [EMAIL PROTECTED] James Strachan [EMAIL PROTECTED] Dain Sundstrom [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Brian McCallister be appointed to the office of Vice President, ActiveMQ, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache ActiveMQ PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache ActiveMQ Project; and be it further RESOLVED, that the Apache Incubator PMC shall, upon deciding that the ActiveMQ incubating project has graduated, transfer all oversight and responsibility for the ActiveMQ incubating project and its artifacts to the Apache ActiveMQ PMC. - 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: [VOTE] graduate Solr to Lucene
+1 On 12 Jan 07, at 11:19 AM 12 Jan 07, Yonik Seeley wrote: The Solr community has voted and believes Solr is ready for graduation from the Incubator and has met all incubation requirements, and the Lucene PMC has voted to accept Solr. The Solr podling is therefore requesting to graduate from the Incubator to become an Apache Lucene subproject. Please send in your +1/0/-1 to approve/abstain/disapprove. References: Lucene PMC Vote on it's private list: Message-ID: [EMAIL PROTECTED] Solr community vote: http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/ 200701.mbox/% [EMAIL PROTECTED] The project status for Solr is at: http://incubator.apache.org/projects/solr.html The Solr home page is at: http://incubator.apache.org/solr/ -Yonik - 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: Woden podling artifacts on ibiblio!!
The artifacts have been removed from the central repository. Jason. On 22 Nov 06, at 6:54 AM 22 Nov 06, Jeremy Hughes wrote: Unknown to the woden-dev team (until today) our M6 release artifacts have escaped to ibiblio (see this thread on woden-dev): http://mail-archives.apache.org/mod_mbox/ws-woden-dev/200611.mbox/% [EMAIL PROTECTED] via them being erroneously being put into here: http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/ apache/woden/ Also, the file names lack the mandatory 'incubating' I feel duty bound to inform the IPMC in case there is something that can be done. Thanks, Jeremy - 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] Ivy
+1 On 23 Oct 06, at 2:03 PM 23 Oct 06, Xavier Hanin wrote: Hi All, After several weeks of discussion with our user community [1] and with several Apache members, I am proud to present a proposal [2] for the open source project Ivy to join the Apache Incubator. I and all the Ivy team and user community hope you will consider this proposal carefully, and accept the project to join the foundation. Best regards, - Xavier Hanin [1] http://groups.google.com/group/ivy-future [2] = Ivy Proposal = The following presents the proposal for creating a new Ivy project within the Apache Software Foundation. == Abstract == Ivy (http://www.jayasoft.org/ivy) is a java based tool for tracking, resolving and managing project dependencies. == Proposal == Ivy is a tool for managing (recording, tracking, resolving and reporting) project dependencies. It is characterized by the following: 1) flexibility and configurability - Ivy is essentially process agnostic and is not tied to any methodology or structure. Instead it provides the necessary flexibility and configurability to be adapted to a broad range of dependency management and build processes. 2) tight integration with Apache Ant - while available as a standalone tool, Ivy works particularly well with Apache Ant providing a number of powerful Ant tasks ranging from dependency resolution to dependency reporting and publication. == Rationale == Software development is increasingly characterized by leveraging externally provided components/capabilities and by a rapid release cycle. As a result it is not unusual for a project to depend on numerous third-party components which themselves may be dependent on a multitude of third-party of different or identical third-party components. Managing these dependencies - determining what the dependencies are, how they are used, the impact of a change, conflicts among dependencies, etc. - is extremely difficult and absolutely necessary. Ivy is one of a handful of tools addressing this need. While often compared to Maven - which has similar Ant tasks - Ivy differs from Maven in both its focus and philosophy. Ivy is solely focused on dependency management and is designed from the ground up to adapt to a wide range of requirements and scenarios. Examples include multiple aritfacts per module, plugin resolvers, configurable repository configurations and conflict managers. The maintainers of Ivy are interested in joining the Apache Software Foundation for several reasons: * Ivy has been hosted since its beginning in 2004 by a private company, which make people feel like it's a corporate product, thus slowing the contribution by the community. We strongly believe in the open source movement, and would like to make Ivy independent from Jayasoft. * We'd like to enjoy the benefits of utilizing Apache's infrastructure and legal protection. * It might open the door for cooperation with other projects, such as Ant or Maven. * We strongly believe in Apache philosophy, especially Meritocracy. == Current status == === Meritocracy === Ivy was originally created by Xavier Hanin in September 2004. Since then more than 20 users have contributed patches, and one of them has been promoted to the status of committer based on his merit through patch contribution. === Community === Ivy already has a growing user community, with more than 10,000 downloads since its 1.0 version and more than 500 users registered on the forum. === Core Developers === Ivy has only two core developers for the moment, but we hope joining the ASF will help increase this number. Xavier Hanin is the creator of the project, is an independant consultant and co founder of Jayasoft. He has an experience of 9 years in Java software development, uses open source projects intensively, and started his real participation in open source development with Ivy. Maarten Coene has joined the committer team in may 2006. He has an experience of 9 years in java development, is co-administrator of dom4j, ex-committer for scarab, has contributed patches to several open- source projects and is a user of a lot of open-source projects. === Alignment === Ivy has no mandatory dependencies except java 1.4. However, it is strongly recommended to be used with Ant. Ivy uses also other Apache projects, especially from Jakarta Commons. == Known risks == === Orphaned products === Due to its small number of committers, there is a risk of being orphaned. The main knowledge of the codebase is still mainly owned by Xavier Hanin. Even if Xavier has no plan to leave Ivy development, this is a problem we are aware of and know that need to be worked on so that the project become less dependent on an individual. === Inexperience with Open Source === While distributed under an open source license, access to Ivy was initially limited with no public access to the issue tracking system or svn repository. While
Re: REVISED Policy on Initial Committer and PPMC members
+1 On 12 Oct 06, at 11:42 AM 12 Oct 06, Noel J. Bergman wrote: Based upon all of the discussion, I'll pose the following as what I hope is an agreeable solution: -- The Champion shall work with the incoming community to identify the initial committers. The Champion shall review each with the incoming community to justify each inclusion (active committer, highly desired new committer, etc., but not arbitrary). The proposal does not need to include the justification, although the Champion should share it (and any concerns) with the Incubator PMC. The Champion shall work with the incoming community identify the initial PPMC members*. The Champion shall review each with the incoming community to justify each inclusion.The proposal does not need to include the justification, although the Champion should share it (and any concerns) with the Incubator PMC. [Editiorial: the topic of Emeritus Committers is unaddressed, on the grounds that when an Emeritus Committer asks to become a Committer, there is still a vote, and there is no requirement that the Community apply any specific barrier to (re-)entry.] The Champion shall include the list(s) in the Project Proposal submitted to the Incubator PMC for voting to accept the project. Upon a successful vote to accept, the proposal as accepted shall determine the initial committer and PPMC lists. *Incubator PMC members have oversight on all Incubator projects, and need not be listed, although Mentors need to be identified when the project is accepted. -- Needless to say (as anyone who has observed the discussion around the process proposal should realize), this is offered invite discussion, wordsmithing and consensus. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy on Initial Committership
On 8 Oct 06, at 8:55 AM 8 Oct 06, Justin Erenkrantz wrote: On 10/8/06, Jim Jagielski [EMAIL PROTECTED] wrote: However, in that case I would really like to see it that if committers from other ASF projects read the proposal and have a sincere interest in helping, that they be included in the initial list, since I think it helps bootstrap the community process right off the bat. Noel and I were chatting about this last night, and my position is that I'm okay with 'piling on' by ASF folks *if* the podling community is happy with that. If the podling folks do not want them on the initial list and desire that they earn their commit bits through actual participation, I'm okay with that too. Noel's said that being the arbitrator of who is on the list should be the role of the Champion and I think that's probably as good as we're going to get. But, by the time the Incubator PMC votes on a proposal, that list must be set (i.e. no deletions after the vote concludes). -- justin +1 In addition I would like to add the process used for OpenEJB as the gold standard for creating this initial list: --- As far as how we came up with the commit list, it's actually pretty neat. For the proposal, I added everyone who had commit. For the actual giving commit, I was much more cautious. I created a status file and gave people basically two months to add their name. I did this for two reasons 1. filters the completely inactive and proves at least some level of activity (you have to at least read the list and update svn) 2. a formal acknowledgment that you understand and agree with our moving to apache and want to participate We ended up with a smaller list of committers, but actually got some old committers active again, so that was a big plus. --- Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On 1 Oct 06, at 6:38 PM 1 Oct 06, Roy T. Fielding wrote: On Oct 1, 2006, at 11:26 AM, Noel J. Bergman wrote: Taken from the Problem with commit rights on Celtixfire thread: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers This also implies changing the proposal's initial committers list to something suggestive not binding, allowing the the Mentors review and vote on comitters. -1. Of the people participating in a new project, the Mentors are the least capable of selecting a PPMC. I don't think that's true. At least not in the case of CXF. I know both code bases reasonably well as a casual user and I know for example that Dan and Dan are very active and would have the knowledge to bring other PPMC members aboard. Dan and Dan were the first people I asked to be added to the PPMC so discussions could be started regarding brining in as many other developers who were known to be committed to the project. So your argument here is not accurate in general. They generally know nothing about the code or the community, but rather know how to get things done at Apache. The Incubator PMC is even less able than that when it comes to selecting Mentors in the first place. The people listed in the proposal as committers are the PPMC. If some project allows too many people to jump on the proposal at the beginning in order to make the proposal look better to Apache, then they are stuck with the results. Don't like that answer? Then dissolve the podling and start over. Have committers that haven't bothered to contribute? Then vote them off the island, just like a real PMC. Truth in advertising demands that you follow the process as described in the proposal and use the Apache mailing lists for all project discussions. Roy - 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: Problem with commit rights on Celtixfire
On 1 Oct 06, at 1:05 PM 1 Oct 06, Noel J. Bergman wrote: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers +1 --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with commit rights on Celtixfire
On 30 Sep 06, at 10:09 AM 30 Sep 06, Jim Jagielski wrote: On Sep 30, 2006, at 3:57 AM, robert burrell donkin wrote: On 9/29/06, Dan Diephouse [EMAIL PROTECTED] wrote: Hi Jim, Can you please explain what the criteria was for removing people from the comitter list? Can you also detail who was removed? Can you also explain why this hasn't been communicated to everyone on the dev list so far? And why I have only heard about the final decision third hand from this email and an offhand mention in Bo's email? I am OK with the PMC's authority as thats what I signed up for at Apache, but I feel that if they make such an important decision as this they should at least communicate the above. setting aside the particulars, this worries me from a process perspective. I will again defer to Jason van Zyl who was the prime focus of all this. Unless Jason responds by Monday, I will email a synopsis from my PoV. I will state however that from the get-go, I said: I just got back from being on the road and wanted to be around and prepared for the ensuing discussion. There will certainly be some debate and I didn't want to throw the issue out and then not being around to follow the discussion. I would be somewhat hesitant about doing this via a con-call. Certainly we can request a cxf-private list that contains the mentors and the PPMC members (see #2). The reason is simple: such policy discussions should be archived, since they affect the project and its future. One key question was who is the PPMC. My interpretation is that the initial PPMC consists of the Mentors and the initial group of committers noted and agreed to in the proposal. Some had issues with that and said that the initial list of committers was stacked. Generally, I think there are problems with a number of proposals that have gone in recently in that they deviate heavily from existing notions of meritocracy. What's important is that going forward is that the process is clear as I made assumptions based on how existing, non-incubating, projects work and there seems to be a discrepancy between how I feel projects should be initiated according to Apache history and what some projects are doing or did. At any rate the discussion was between the mentors so effectively the PPMC for CeltiXFire. The thread was initiated off list but everyone agreed to bring it on list and the onus is on me to put the message forward because I think there are problems. I will fully disclose everything and summarize to the list by Monday now that I'm back home. Jason. - 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: PPMCs [was Re: what are required for contributing to release management]
On 28 Sep 06, at 12:59 PM 28 Sep 06, Garrett Rooney wrote: Well, PMCs are formed by the board when a project moves to top level status. PPMCs are formed for an incubating project, and exactly how that works tends to differ a bit between projects. Some mentors start off with just the mentors on the PPMC, and then invite project members as time goes on (or that's the impression I've gotten). Others just start with the whole group of committers plus the mentors on the PPMC (that's what we did with Abdera). I think starting with the mentors is the wisest choice as at that point any committers can be brought aboard if deemed fit. So that can support both models as all committers can be brought aboard if it fits, or over time if more suitable. I was also confused about this as I heard one thing from Noel and one thing from Jim, but the mentors deciding seems sensible as projects can be dealt with on a case by case basis. I don't believe committers should automatically be made (P)PMC members as to me it's a different level of understanding and commitment. -garrett - 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: [VOTE] Approve the 4.1 release of ActiveMQ's maven plugins
+1 On 19 Sep 06, at 1:06 AM 19 Sep 06, Hiram Chirino wrote: Howdy ActiveMQ Mentors... you know who you are :) So far I think we have 2 binding +1's from: +1 Robert Burrell Donkin +1 James Strachan I know you guys are probably busy, but could you please take a moment and review the binaries? We almost got the 3 votes needed to approve the release. Thanks! On 9/14/06, Hiram Chirino [EMAIL PROTECTED] wrote: In accordance with the incubator release procedure (see below) the Apache ActiveMQ community has voted on and approved the 4.1 release of the ActiveMQ maven plugins. These plugins are required for the maven build of the ActiveMQ. These artifacts are only targeted for the ActiveMQ project to consume. We would now like to request the permission of the Incubator PMC to perform the release. Vote thread: http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 200609.mbox/% [EMAIL PROTECTED] Vote result: The VOTE has passed with 5 ppmc +1's and no -1s. +1 Hiram Chirino +1 Guillaume Nodet +1 Rob Davies +1 James Strachan +1 Alan D. Cabrera We also had 1 non ppmc +1: +1 Kevan Miller You can checkout the binary build here: http://people.apache.org/repo/m2-incubating-repository/org/apache/ activemq/ The release was built from the following tag: https://svn.apache.org/repos/asf/incubator/activemq/maven-plugins/ tags/maven-plugins-4.1 The maven web site for those plugins is up here: http://incubator.apache.org/activemq/maven-plugins-maven/ Releases section of the Incubation Policy: http://incubator.apache.org/incubation/ Incubation_Policy.html#Releases Here's my non binding +1 -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any resolution on M2 repo for incubating snapshots?
On 15 Sep 06, at 10:02 PM 15 Sep 06, robert burrell donkin wrote: On 9/14/06, Andrus Adamchik [EMAIL PROTECTED] wrote: There was a long going thread about the M2 repo for the incubating projects snapshots. Was there any conclusion to that? i've re-read the posts and IMHO there seems to be a reasonable consensus. Can we publish them somewhere now? unless someone jumps in sometime soon... I don't think there's any downside to publishing snapshots. Syncing releases to the central repository was the contentious part, but there's no harm in putting snapshots in the incubator snapshot repository. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing to release an incubator POM
On 9 Sep 06, at 5:48 PM 9 Sep 06, Jeremy Boynes wrote: On Sep 9, 2006, at 5:48 AM, Jason van Zyl wrote: On 8 Sep 06, at 10:36 PM 8 Sep 06, Wendy Smoak wrote: On 9/8/06, Jeremy Boynes [EMAIL PROTECTED] wrote: This artifact would need to released by the Incubator PMC so that it can be made freely available via ibiblio. The latest version is in SVN at https://svn.apache.org/repos/asf/incubator/public/trunk/pom/pom.xml and if there are no issues with doing this I would like to formally tag it and request a vote by the IPMC. Any comments before I do so? What about using 'incubator' or 'incubator-parent' for the artifactId (instead of just 'parent')? incubator would probably be the best I have no strong preference, this just seemed tautological as the groupId is already org.apache.incubator My rule of thumb is generally be able to tell exactly what it is by looking at it. I don't want to have to open a text editor to know exactly what it is. Just like I don't want to have to crack open the manifest of a JAR to see exactly what it is. Given that proviso maybe apache-incubator, or apache-incubator-podlings. Though we don't have a guideline for parent POM naming I generally use the project name as all the other artifacts in the project are an extension of that i.e. maven-core, maven-artifact ... Other examples are the top-level 'apache' pom,(which you might want to define as this pom's parent, if only to show the project hierarchy,) I thought it was better not to do this as this pom is intended to be used as a parent by podlings which do not have official Apache project status. Maintaining a distinct hierarchy seemed clearer. With this in mind, how about podling-parent for the artifactId? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preparing to release an incubator POM
On 8 Sep 06, at 10:36 PM 8 Sep 06, Wendy Smoak wrote: On 9/8/06, Jeremy Boynes [EMAIL PROTECTED] wrote: This artifact would need to released by the Incubator PMC so that it can be made freely available via ibiblio. The latest version is in SVN at https://svn.apache.org/repos/asf/incubator/public/trunk/pom/pom.xml and if there are no issues with doing this I would like to formally tag it and request a vote by the IPMC. Any comments before I do so? What about using 'incubator' or 'incubator-parent' for the artifactId (instead of just 'parent')? incubator would probably be the best Other examples are the top-level 'apache' pom,(which you might want to define as this pom's parent, if only to show the project hierarchy,): http://svn.apache.org/repos/asf/maven/pom/trunk/asf/pom.xml and the maven-parent pom: http://svn.apache.org/repos/asf/maven/pom/trunk/maven/pom.xml . -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator POM as parent for podlings
postgeneral@incubator.apache.org/post archivehttp://mail-archives.apache.org/mod_mbox/ incubator-general//archive /mailingList /mailingLists /project - 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] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote: On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. Common decency? If we (as the project owners) ask those artifacts not to be posted, then they shouldn't be posted as a matter of courtesy. It just means that we have to start watching for requests coming from users to put artifacts in the repository. Effectively you are asking us to deny the terms of redistribution stated in our license are you not? We could watch for requests going into Ibiblio, but we can't prevent someone else from putting in a repository that they might use. What is going to happen is that people are going to want to use these artifacts and they will want to rsync Ibiblio, which many people do, and then attempt to rsync the incubator repository. We are just going to try and circumvent a path that we cannot fully block off. I don't see what is not clear with *every* incubator artifact being marked with a version that has incubator in it. Plus the reports that can be generated give a clear view to users what they are consuming. I read this: http://marc.theaimsgroup.com/?l=incubator-generalm=115440663222532w=2 and to be frank (4) is somewhat paradoxical to me. You want an incubator project to thrive, and grow while we are tacitly, yet actively, discouraging their use? I think we should let people use their common sense to protect themselves. What is being envisioned here as the worst case scenario of using an incubator artifact for a failed incubator project? The mail says protect the user, but from what? I'm not going to discourage the use of a project I'm mentoring and fully support. I'm going to get everyone on the planet I can to use it as fast and as widely as possible. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote: Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? As a force of habit most Maven users, particularly those coming from Maven 1.x, assume all open source artifacts are in the central repository. And in most cases for Maven 2.x all artifact required are placed in the central repository. It would be an unnecessary inconvenience. If the goal is to raise awareness that it is from the incubator then it can be done with the version. It could even be 1.0-apache-incubator-foo (1) As I think that would be preferable to users and that is abundantly clear I think. The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? The whole point of Maven is to make this easy for users and not have to look at a project's site. Maven users expect what they need to be in the central repository as shown by the many threads when users go to use Sun JARs and we don't have them in the central repository. If they do indeed look, isn't it trivial to add instructions on adding info on how to add the incubation repo? Where's the problem? A lot of times people actually go to the central repository to find the artifact's groupId and artifactId. They don't go to project websites, they go to the authority which is the central repository. If the goal here is user awareness then I think using an version like (1) supports this end to a great extent while being more convenient for the average Maven user. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote: On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. Common decency? If we (as the project owners) ask those artifacts not to be posted, then they shouldn't be posted as a matter of courtesy. It just means that we have to start watching for requests coming from users to put artifacts in the repository. Effectively you are asking us to deny the terms of redistribution stated in our license are you not? We could watch for requests going into Ibiblio, but we can't prevent someone else from putting in a repository that they might use. What is going to happen is that people are going to want to use these artifacts and they will want to rsync Ibiblio, which many people do, and then attempt to rsync the incubator repository. We are just going to try and circumvent a path that we cannot fully block off. I don't see what is not clear with *every* incubator artifact being marked with a version that has incubator in it. Plus the reports that can be generated give a clear view to users what they are consuming. I read this: http://marc.theaimsgroup.com/?l=incubator- generalm=115440663222532w=2 and to be frank (4) is somewhat paradoxical to me. You want an incubator project to thrive, and grow while we are tacitly, yet actively, discouraging their use? I think we should let people use their common sense to protect themselves. What is being envisioned here as the worst case scenario of using an incubator artifact for a failed incubator project? The mail says protect the user, but from what? I'm not going to discourage the use of a project I'm mentoring and fully support. I'm going to get everyone on the planet I can to use it as fast and as widely as possible. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 30 Aug 06, at 11:18 PM 30 Aug 06, Davanum Srinivas wrote: Hmm, we are not setting any limits on anyone else, just ourselves. We the incubator folks will not automatically sync *our* repo to the central repo *automatically*. Everyone else can do what they want within their rights. That doesn't really jive with what Justin said in an earlier thread. In that we should tell people not to redistribute incubator artifacts and ask they comply out of courtesy. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 10:16 PM 30 Aug 06, Davanum Srinivas wrote: Please see this email from Noel: http://marc.theaimsgroup.com/?l=incubator- generalm=115440482328786w=2 Why can't both aims be met? That of user protection and user convenience? I cannot see the how marking *each* and *every* incubator artifact with a version that clearly says it is from the Apache Incubator gives less clarity then adding a repository element. In a standard dependency report like: http://jackrabbit.apache.org/dependencies.html It would be very clear looking at the version that it came from the incubator. And if people download these artifacts with non-Maven tools like an Ant Task, Ivy or simply check in versions of these artifacts then they will clearly be seen as coming from the incubator. If we are going to make it clear then let's do it in the place where it will be seen by everyone regardless of the tool they use to build. Also the Maven 2.x IDE integration will soon have the ability to pull indices from repositories in order to provide drop down/searchable lists of available artifacts so it will be easy to grab new artifacts to put in your POMs. An IDE could easily provide a set of repositories to pull indices from at which point the user is going to merrily start pulling down dependencies. When you select an artifact you always select the version, like in the Eclipse integration, so people will see apache-incubator over and over. They will see the repository entry once. If I then had to go to the people doing IDE integration and say please don't include the apache incubator repository. So you are going to make us: 1) Deny people the right to distribute software as described in our license 2) Make the Maven developers go search out all third party integration efforts to prevent them from providing convenient access to certain repositories I think this is a little heavy handed, unfair and unnecessary. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote: Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? As a force of habit most Maven users, particularly those coming from Maven 1.x, assume all open source artifacts are in the central repository. And in most cases for Maven 2.x all artifact required are placed in the central repository. It would be an unnecessary inconvenience. If the goal is to raise awareness that it is from the incubator then it can be done with the version. It could even be 1.0-apache-incubator-foo (1) As I think that would be preferable to users and that is abundantly clear I think. The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? The whole point of Maven is to make this easy for users and not have to look at a project's site. Maven users expect what they need to be in the central repository as shown by the many threads when users go to use Sun JARs and we don't have them in the central repository. If they do indeed look, isn't it trivial to add instructions on adding info on how to add the incubation repo? Where's the problem? A lot of times people actually go to the central repository to find the artifact's groupId and artifactId. They don't go to project websites, they go to the authority which is the central repository. If the goal here is user awareness then I think using an version like (1) supports this end to a great extent while being more convenient for the average Maven user. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote: On 8/30/06, Dan Diephouse [EMAIL PROTECTED] wrote: policy, so I see those as in conflict right now. So I want to know on what grounds the incubator can prevent me from requesting that some incubating jars from being uploaded to ibiblio. Common decency? If we (as the project owners) ask those artifacts not to be posted
Re: [policy] incubating projects and maven repositories v1.0
On 31 Aug 06, at 12:18 AM 31 Aug 06, Davanum Srinivas wrote: Jason, Justin used the word common decency. No one can twist anyone's arm. If either the ibiblio folks or Maven PMC folks don't honor the request, well, it's upto them...Here we are setting policy for us the incubator participants, incubator mentors and incubator pmc folks. If people working on the incubation project break the policy, then that's an issue for us. It's not policy until we vote on it. So I guess it's time to vote. How is this done, no the general list? For 72 hours? A majority wins? -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 11:18 PM 30 Aug 06, Davanum Srinivas wrote: Hmm, we are not setting any limits on anyone else, just ourselves. We the incubator folks will not automatically sync *our* repo to the central repo *automatically*. Everyone else can do what they want within their rights. That doesn't really jive with what Justin said in an earlier thread. In that we should tell people not to redistribute incubator artifacts and ask they comply out of courtesy. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 10:16 PM 30 Aug 06, Davanum Srinivas wrote: Please see this email from Noel: http://marc.theaimsgroup.com/?l=incubator- generalm=115440482328786w=2 Why can't both aims be met? That of user protection and user convenience? I cannot see the how marking *each* and *every* incubator artifact with a version that clearly says it is from the Apache Incubator gives less clarity then adding a repository element. In a standard dependency report like: http://jackrabbit.apache.org/dependencies.html It would be very clear looking at the version that it came from the incubator. And if people download these artifacts with non-Maven tools like an Ant Task, Ivy or simply check in versions of these artifacts then they will clearly be seen as coming from the incubator. If we are going to make it clear then let's do it in the place where it will be seen by everyone regardless of the tool they use to build. Also the Maven 2.x IDE integration will soon have the ability to pull indices from repositories in order to provide drop down/searchable lists of available artifacts so it will be easy to grab new artifacts to put in your POMs. An IDE could easily provide a set of repositories to pull indices from at which point the user is going to merrily start pulling down dependencies. When you select an artifact you always select the version, like in the Eclipse integration, so people will see apache-incubator over and over. They will see the repository entry once. If I then had to go to the people doing IDE integration and say please don't include the apache incubator repository. So you are going to make us: 1) Deny people the right to distribute software as described in our license 2) Make the Maven developers go search out all third party integration efforts to prevent them from providing convenient access to certain repositories I think this is a little heavy handed, unfair and unnecessary. -- dims On 8/30/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote: Jason, Is it rocket science to add a new repo location in pom.xml? *Any* maven newbie learns *very* quickly how to add a new repo. Are you stating that *IF* the artifacts are not in the central repo they won't find it and won't know how to use it? As a force of habit most Maven users, particularly those coming from Maven 1.x, assume all open source artifacts are in the central repository. And in most cases for Maven 2.x all artifact required are placed in the central repository. It would be an unnecessary inconvenience. If the goal is to raise awareness that it is from the incubator then it can be done with the version. It could even be 1.0-apache-incubator-foo (1) As I think that would be preferable to users and that is abundantly clear I think. The least anyone will need to know is the artifact id and version id and they find this when they browse a project's pages, are you stating that a user will never look at anyone's web site or download area and will *ONLY* look at ibiblio repo and decide to use a project? The whole point of Maven is to make this easy for users and not have to look at a project's site. Maven users expect what they need to be in the central repository as shown by the many threads when users go to use Sun JARs and we don't have them in the central repository. If they do indeed look, isn't it trivial to add instructions on adding info on how to add the incubation repo? Where's the problem? A lot of times people actually go to the central repository to find the artifact's groupId and artifactId. They don't go to project websites
Re: [policy] incubating projects and maven repositories v1.0
On 28 Aug 06, at 11:44 AM 28 Aug 06, Leo Simons wrote: On Sun, Aug 27, 2006 at 12:44:58PM -0400, Jason van Zyl wrote: snip/ There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. A few folks with incubating projects have voiced concerns that they don't want to see their projects be taken out of circulation in the central repository because they are incubating. If each and every incubating project has a version for each artifact like that above then it will be fairly clear that it's from the incubator. Moreso then if you just had a repository definition pointing at the incubator repository. Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Thoughts? central repository is ibiblio.org right? Correct. Eg not an ASF machine? Correct. I think its not up to the incubator to dictate policies on what external parties should and should not do with our software. It all comes back to being clear to users and providing a consistent message, and I think the steps we agreed on here (seperate repo, clear versioning, incubation notices on website and in readme) are sufficient, and I doubt we should go any further than that. If other ASF projects depend on projects that depend on projects that depend on incubating projects that are published on the ibiblio site and that is not sufficiently clear for users of that project, then that's not the responsibility of the incubator pmc to fix. IOW, I don't really want to to get into the business of policing anything but the bits we're actually responsible for policing :) So I'll withold actual thoughts (which would've been along the lines of centralized storage is so 1990s) ;) LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[policy] incubating projects and maven repositories v1.0
Hi, It looks like people objected to creating another mailing list for policy so I just used [policy] as Robert did in a previous message. Henri has setup Maven repositories for the incubator and there is a document which is an attempt to describe the current setup here: http://www.apache.org/dev/repository-faq.html I think that everyone agrees that a separate repository for incubating projects is a good idea as 1) you can clearly see what incubator artifacts have been created 2) we can perform analysis and create reports for incubator artifacts easily (using Archiva, the maven repository manager) 3) separating the administration duties of the incubator repository is a good idea I think. This might involve a different instance of Archiva and/or different people looking after the respective repositories I haven't looked at all the projects using Maven in the incubator but cxf, the one I'm most involved with, looks like its settling on versions like: 2.0-incubator-SNAPSHOT So the repository is clearly separated, and from a dependency element in a Maven POM you can clearly see it's an incubator version. There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. A few folks with incubating projects have voiced concerns that they don't want to see their projects be taken out of circulation in the central repository because they are incubating. If each and every incubating project has a version for each artifact like that above then it will be fairly clear that it's from the incubator. Moreso then if you just had a repository definition pointing at the incubator repository. Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Thoughts? Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 27 Aug 06, at 6:28 PM 27 Aug 06, Craig L Russell wrote: On Aug 27, 2006, at 2:22 PM, Jukka Zitting wrote: Hi, On 8/27/06, Jason van Zyl [EMAIL PROTECTED] wrote: There was discussion that incubator repository would not be sync'd to the central repository but I don't really see much point in this. [...] Also someone may make an repository request to place an incubator artifact in the central repository and at this point a policy mandated here would conflict with someone's right to redistribute artifacts created in the incubator. I don't really want to get into the business of policing repository requests. I think it is in the best interests of the incubating projects to have the incubator repository sync'd to Maven's central repository. The source of artifacts for incubating projects is clear from the version so I don't think there will be any confusion by consumers of these artifacts and as such I don't really see any downside to allowing the sync to Maven's central repository. Me neither. But why do we then need the separate incubator repository if the artifacts get synchronized with the central repository? As I mentioned in the thread before the Incubator Maven repository was created, it makes more sense to enforce an incubator label on the artifact versions than enforcing a specific incubator repository. Especially since there is no way for us to really enforce that repository policy. I agree. I understand that we want users who choose to use an incubating project's artifacts to declaratively state that. If the artifact's name contains incubating then it's pretty clear. The only thing that muddles things for me is when using an m2 repository that contains a non-incubating project with a dependency on an incubating project. Then, a project that depends on the project that is itself not in the incubator might not even know that it's using an incubating project. The standard dependency report shows all transitive dependencies so you can definitely see what you're using: http://maven.apache.org/continuum/dependencies.html Could be a little better in display but you can see what's in your dependency set. There are also things like the netbeans m2 integration which draws nice graphs of the dependencies. Can this happen? Is it likely? If you don't look at the dependency report or a graph then I suppose it could. Is there any policy that we can put into place to avoid that projects with dependencies on projects with incubating projects accidentally have this dependency? Perhaps Maven can help by not allowing the transitive dependency on incubating projects? Just thinking out loud... If you can clearly see what you have in a report so I'm not sure we would want to put any special rules in place to deal with artifacts from incubator. Craig BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] incubating projects and maven repositories v1.0
On 27 Aug 06, at 10:26 PM 27 Aug 06, Niclas Hedhman wrote: On Monday 28 August 2006 08:58, Jason van Zyl wrote: Perhaps Maven can help by not allowing the transitive dependency on incubating projects? Just thinking out loud... If you can clearly see what you have in a report so I'm not sure we would want to put any special rules in place to deal with artifacts from incubator. Could that report be made part of the release:prepare and the release manager had to explicitly approve it?? How are we supposed to enforce that? And what if they are not using Maven? Say using either the Maven Ant Tasks, or Ivy, or just an http get to get artifacts from a repository. If so, then I'm totally cool with no other Maven adjustments to deal with incubating projects. Generating the site is not part of a standard release, though it's usually done as part of a release, and I'm not sure how you're going to enforce that for every possible project that might use something from the incubator. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Wicket into the Incubator
Republic, is a CS student and works for EEA as a software engineer * Frank Bille Jensen is from Denmark and works for Avaleo as a software engineer * Ate Douma is from The Netherlands as a software engineer * Jan Blok is from The Netherlands and works for Servoy as a software engineer * Chris Turner is from the UK and works as an independent consultant. He does not intend to move with us to Apache. In addition, there are other contributors from France, Germany, Spain, the UK, US, Canada, Brazil, India, Japan, China, Iran, and various other countries. All contributors come from a software background, but we - informally - have some different tasks. For instance, Martijn is in charge of the releases, Gwyn of maintaining the WIKI and possibly more site related things and Jonathan provides regular code reviews. But any one of the team has committed code, and may do so. === Reliance on Salaried Developers === None of the developers rely on Wicket for consulting work, though two - Martijn and Eelco - are writing Wicket In Action (publisher Manning) in their spare time. Most of the developers use Wicket for their day jobs, some for multiple projects, and will do so for a considerable while as their companies (specifically Topicus, Cemron, Avaleo and Teachscape) choose Wicket as their development framework of choice. === Ties to other Apache Products === Wicket uses Jakarta Commons Logging and Log4j and adopted some code from Jakarta Commons Upload. It uses Maven for it's build process. Wicket tries to stay as lean as possible though. === An Excessive Fascination with the Apache Brand === The ASF has a strong brand, and that brand is in itself attractive. However, the developers of Wicket have been quite successful on their own and could continue on that path with no problems at all. We are interested in joining the ASF in order to increase our contacts and visibility in the open source world. Furthermore, we have been enthusiastic users of Apache from the earliest hour (remember JServ anyone?), and feel honored at getting the opportunity to join the club. == Committers == * Jonathan Locke * Eelco Hillenius * Johan Compagner * Martijn Dashorst * Juergen Donnerstag * Igor Vaynberg * Gwyn Evans * Matej Knopp * Janne Hietamäki * Frank Bille Jensen * Ate Douma * Jan Blok == Proposed Apache Sponsor == Incubator PMC == Champions == * Upayavira * Alex Karasulu * Sylvain Wallez == Mentors == * Upayavira * Alex Karasulu * Sylvain Wallez * Bertrand Delacretaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for FtpServer JIRA karma
On 22 Aug 06, at 7:29 AM 22 Aug 06, Niklas Gustavsson wrote: Hi I'm a commiter on the incubating FtpServer project. As there is currently only one active commiter with admin (edit, close and assign issues, manager versions and components) rights I would like to apply for this level of access to help share the load. Done. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting up a Maven 2 repo Was: Maven 2 repo for incubating project releases?
On 18 Aug 06, at 11:30 AM 18 Aug 06, Dan Diephouse wrote: Yeah, I find this a bit confusing too. The ibiblio repository distribution policy is unrelated to Apache's. No one is making any claims on ibiblio about the licensing (other than its freely distributable)/community/etc - I mean, come on, there are sourceforge binaries on there! :-) Also, Guillaume makes a good point, anybody create upload requests for ibiblio. Why couldn't I go make an upload request for any of the incubating projects? You don't have to be a project coordinator to get jars uploaded. It only needs to be a freely distributable binary. I'm +1 to creating the repositories and its a very necessary first step, but I think things should go further. I think in terms of physical separation on Apache infrastructure this is a good thing so that we could run the repository manager on that separate repository to get stats on incubator artifact activity. Project using Maven in the incubator can specify a set of repositories to use so it wouldn't be onerous to have artifacts be pulled from the incubator repository. But I honestly don't think there is much downside in syncing to Ibiblio but I suppose that is a decision for the Incubator PMC to decide. That is probably the thing to clear up. - Dan Guillaume Nodet wrote: What is the real purpose of such a repository if it is not synced to ibiblio ? What if a user of an incubating project create an upload request ? There's no reason why Apache internal policies would affect such a request. AFAIK, Ibiblio repository is not owned by the ASF ... Jason van Zyl wrote: +1 On 14 Aug 06, at 5:03 PM 14 Aug 06, Henri Yandell wrote: On 8/7/06, Henri Yandell [EMAIL PROTECTED] wrote: people.apache.org/repo/m1-incubating-repository people.apache.org/repo/m2-incubating-repository Noel, shall I go ahead and create the above? They get my +1 from a repository@ point of view. Pinging on this to make sure the Incubator is happy with the idea before I set it up. Hen --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - 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] -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting up a Maven 2 repo Was: Maven 2 repo for incubating project releases?
On 18 Aug 06, at 5:02 PM 18 Aug 06, Davanum Srinivas wrote: Jason, why don't you start a vote with a detailed note? Let's make a policy decision :) Will do, but shall we do this on a separate list as people indicated they would like to do? To keep the policy making/deciding off this list? thanks, dims On 8/18/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 18 Aug 06, at 11:30 AM 18 Aug 06, Dan Diephouse wrote: Yeah, I find this a bit confusing too. The ibiblio repository distribution policy is unrelated to Apache's. No one is making any claims on ibiblio about the licensing (other than its freely distributable)/community/etc - I mean, come on, there are sourceforge binaries on there! :-) Also, Guillaume makes a good point, anybody create upload requests for ibiblio. Why couldn't I go make an upload request for any of the incubating projects? You don't have to be a project coordinator to get jars uploaded. It only needs to be a freely distributable binary. I'm +1 to creating the repositories and its a very necessary first step, but I think things should go further. I think in terms of physical separation on Apache infrastructure this is a good thing so that we could run the repository manager on that separate repository to get stats on incubator artifact activity. Project using Maven in the incubator can specify a set of repositories to use so it wouldn't be onerous to have artifacts be pulled from the incubator repository. But I honestly don't think there is much downside in syncing to Ibiblio but I suppose that is a decision for the Incubator PMC to decide. That is probably the thing to clear up. - Dan Guillaume Nodet wrote: What is the real purpose of such a repository if it is not synced to ibiblio ? What if a user of an incubating project create an upload request ? There's no reason why Apache internal policies would affect such a request. AFAIK, Ibiblio repository is not owned by the ASF ... Jason van Zyl wrote: +1 On 14 Aug 06, at 5:03 PM 14 Aug 06, Henri Yandell wrote: On 8/7/06, Henri Yandell [EMAIL PROTECTED] wrote: people.apache.org/repo/m1-incubating-repository people.apache.org/repo/m2-incubating-repository Noel, shall I go ahead and create the above? They get my +1 from a repository@ point of view. Pinging on this to make sure the Incubator is happy with the idea before I set it up. Hen --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: general- [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: general- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] approve the 4.0.2 release of ActiveMQ
On 18 Aug 06, at 6:17 PM 18 Aug 06, robert burrell donkin wrote: (we need a script or something to check for license headers) Checkstyle works well at doing this for the java sources, at least. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting up a Maven 2 repo Was: Maven 2 repo for incubating project releases?
+1 On 14 Aug 06, at 5:03 PM 14 Aug 06, Henri Yandell wrote: On 8/7/06, Henri Yandell [EMAIL PROTECTED] wrote: people.apache.org/repo/m1-incubating-repository people.apache.org/repo/m2-incubating-repository Noel, shall I go ahead and create the above? They get my +1 from a repository@ point of view. Pinging on this to make sure the Incubator is happy with the idea before I set it up. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 16 Aug 06, at 2:24 AM 16 Aug 06, Roy T. Fielding wrote: agreed... without experimentation we won't know if IRC or VOIP is better, and produces a better quality/amount. Hmm, IIRC, we already experimented on that issue and discovered the result. I think it was before your time, but APR was mostly designed on IRC and various in-person meetings. I only have one thing to say about that: http://www.utahphillips.org/stuff/mooseturdpie.mp3 What were the problems you encountered? Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
Ali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 15 Aug 06, at 12:27 PM 15 Aug 06, Geir Magnusson Jr wrote: Jan Blok wrote: Hi, What could be the problem of any real-time communication medium usage between some community members as long as every one agrees code and design decisions are made on the mailing list? Because the reality is that decisions are made on IRC, implicitly. It's hard to engage in an argument that already happened, especially when the discussion was very conversational rather than formal : A: what do you think? B: Well, like you said before... A : about the contstructor B : no, the other thing A : related to using =? B : right that it.. it would be better if that was done as Jim suggested versus the more formal statements people make in email I'm beginning to agree that ensuring that re-serializing the Properties preserves the original delimiter (= in Jim's example) that was used in the original file. That's a sweeping generalization which in many cases is not true. Email can be just as unclear and people going Sorry, I don't understand what you just said happens often. In IRC where you can iterate to the point of understanding and pastebin examples to get your point across works very well. I don't think the argument can be made that one form of communication has a better rate of conveyance. I would say IRC does, you would say email does. I think the argument here is one of persons/groups being excluded or not which is matter of project members' attitudes about inclusion. Jason. geir Regards Jan Blok Jim Jagielski wrote: I think one way of looking at this is simply remembering that the ASF values community over code. Yes, IRC and other real-time communication methods means quicker code development, etc, but it places, IMO, an undue barrier to the development of the community. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REMINDER: AUGUST REPORTS ARE ***DUE***
On 11 Aug 06, at 2:07 PM 11 Aug 06, Noel J. Bergman wrote: The page has been sitting waiting for content: http://wiki.apache.org/incubator/August2006 Reports are due every month folks. I should not have to constantly nag you to get them in. How about we hook up to the little notification system used for reminding people to send in board reports? Jason. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 9 Aug 06, at 9:06 PM 9 Aug 06, William A. Rowe, Jr. wrote: Craig L Russell wrote: Has anyone ever considered making IRC chats available (on some basis) as an Apache archive? Seems that Apache (myself included) doesn't like IRC so much because it is not available to those of us who because of time zone or other reasons can't attend. No - mostly because IRC CANNOT BE USED to make project decisions. It's lovely for beating down a problem, kicking around ideas, but those ideas MUST COME BACK TO [EMAIL PROTECTED] Decisions themselves must be made on [EMAIL PROTECTED] It's the responsibility of the project participants to grab any useful log thread, forward it on to the dev@ list to get people thinking and voting. Automatically capturing IRC logs undermines this responsibility and harms the project (for exactly the reasons you point out above). How does automatically capturing the logs undermine anything. It is convenient to point at threads of discussion in IRC and even though summaries can be provided there's nothing like reading the source material. Just as we often summarize threads on [EMAIL PROTECTED], it's still nice to go back to the archives and read over the messages. We keep our messages here: http://dev.rectang.com/logs/codehaus/ And I think they are pretty handy and provide the source material for any summaries. Good evidence of how this works in practice is #cxf where the XFire and Celtix folks have been chatting about ideas and then you see the summary on the mailing list. If you want to go see the IRC log in question you can: http://dev.rectang.com/logs/codehaus/%23cxf/20060809.html I think accountability is actually promoted by logging the channel because if people notice the logs continually growing with no corresponding chatter on the mailing lists then you can identify a problem. If you the channels aren't logged you're never going to know and it probably wouldn't be because a group intentionally trying to undermine the standard channels of communication, it would probably just be habit. You could point at the log and give a gentle nudge to push the discussion to the mailing list. I personally don't see any downside to logging the channels. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CeliXfire Mailing lists
Hi, Just to let folks know that the CeliXfire mailing lists have been set up for those who wish to subscribe: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Thanks, Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consistent naming helps (was: Re: CeliXfire Mailing lists)
On 4 Aug 06, at 11:28 AM 4 Aug 06, Leo Simons wrote: May I suggest making sure that all other resources are also named cxf then? Eg incubator.apache.org/projects/cfx.html svn.apa.../cxf unix group: cxf ... etc. The reason being that it is easier on automated tools and also on admins who may not know about the project. We had some similar difficulties with ws.a.o / webservices.a.o. Makes sense, will do. Jason. cheers! LSD On Fri, Aug 04, 2006 at 11:18:04AM -0400, Jason van Zyl wrote: Hi, Just to let folks know that the CeliXfire mailing lists have been set up for those who wish to subscribe: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Thanks, Jason van Zyl [EMAIL PROTECTED] - 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] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
and integration of Security. * Management tools. * Support for additional class frames such as tunneling == INITIAL SOURCE == A group of companies are developing a set of specifications relating to the creation of commodity enterprise class messaging, collectively called Advanced Message Queuing Protocol (AMQP). In progress versions are available at: * http://www.envoytech.org/spec/amqp/ * http://www.iona.com/opensource/amqp/ * http://www.redhat.com/solutions/specifications/amqp/ * http://www.twiststandards.org/tiki-index.php?page=AMQ * http://www.faqs.org/rfcs/rfc3208.html The initial contributors have been developing Java and C++ code bases (licensed under the Apache License 2.0) which implement aspects of these specifications, and intend to donate it to Apache. The current working svn is available at: https://etp.108.redhat.com/source/browse/etp/trunk/blaze Although the Glasgow project expects to bootstrap using these materials and in the case of specifications, to provide feedback that will be incorporated into their ongoing development, we expect and encourage the open source community to take the project in new directions not envisioned by them to create a world class implementation of the AMQP specification and related technologies. == Interactions with the specifications == The specification is being developed by group of companies, under a contract that requires the resulting work to be published to a standards body. This model has been chosen to assure that anyone that contributes to the specification grants a copyright and patient license to all contributions made to the specification on every publication (draft or final). This ensures that the specification will always be open and implementable by anyone without royalties or commercial limitations. We feel that this is a very strong model for keeping this work entirely open and will fit well with the Apache project enabling innovations to pass in both directions across the extended community. Dealing with feedback from the Glasgow project to specifications It is key that the best implementation and specifications be created based on technical merit and practicalities for adoption by both the parties developing the specification and the committers within the Apache community. Given this, one of the important aspects is how issues discovered during the development of this implementation are incorporated back into the specifications. The following feedback loop exists to ensure that any specification input incuding the Glasgow community can have their feedback incorporated into the specifications. === MECHANISMS FOR FEEDBACK === a.) In the same way anyone can issue a JIRA on any Apache project having signed the Apache CLA, anyone can issue a JIRA to the specification working group through the RLA (Reviewer License Agreement). This agreement provides a license to that IP so that the specification team can incorporate it and the specifaction as they like and the specifications can remain entirely open and royalty free. b.) In the same spirit of Apache, if an individual has shown understanding of the project and substantive contribution to the specification, a vote based on technical merit and understanding of the goals of the work can be initiated to have that parties Employer join the specification working group. On such acceptance the employer is required to sign an agreement to make sure that employer also grants the ongoing and consistent licenses to the work as posted in specifications. The Reviewer License Agreement (RLA) can be viewed from the AMQP specification page of any of the members as listed above. == ASF resources to be created == mailing list(s) * glasgow-dev * glasgow-commits Subversion repository * https://svn.apache.org/repos/asf/incubator/glasgow Jira * Glasgow (GLASGOW) === INITIAL COMMITTERS === * Rajith Attapattu (Red Hat) * Mark Atwell (JPMC) * Bela Ban (Red Hat) * Bhupendra Bardwaj (JPMC) * Alan Conway (Red Hat) * Tejeswar Das (IONA) * Ovidiu Feodorov (Red Hat) * Tim Fox (Red Hat) * Paul Fremantle (WSO2) * Eoghan Glynn (IONA) * Robert Greig (JPMC) * Chamikara Jayalath (WSO2) * Sam Joyce (IONA) * John O'Hara (JPMC) * Frank Lynch (IONA) * Marnie McCormack (JPMC) * Martin Ritchie (JPMC) * Rafael Schloming (Red Hat) * Archit Shah (Red Hat) * Stephen Shaw (JPMC) * Gordon Sim (Red Hat) * James Strachan (LogicBlaze) * Manik Surtani (Red Hat) * Paul Taylor (IONA) * Carl Trieloff (Red Hat) * Kim van der Riet (Red Hat) * Steve Vinoski (IONA) * Sergey Yedrikov (IONA) === APACHE SPONSOR === The Glasgow team will make the submission to the incubator as the sponsor for incubation. Champion * Cliff Schmidt (consultant to Red Hat) Mentors: * James Strachan * Cliff Schmidt (consultant to Red Hat) * Paul Fremantle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL
Re: Maven 2 repo for incubating project releases?
On 1 Aug 06, at 3:16 PM 1 Aug 06, Henri Yandell wrote: On 8/1/06, James Strachan [EMAIL PROTECTED] wrote: I understand the concerns of keeping incubating code separate from the rest of Apache and away from the mirrors - I just don't yet see the issue with having somewhere on incubator.apache.org where we put a folder containing releases of incubating projects?(i.e. a maven 2 repo). +1 to having another repository if that's what's needed. Can we keep them in the same place as the others though and not inside the incubator.apache.org website? I suggest: people.apache.org/repo/m1-incubating-repository people.apache.org/repo/m2-incubating-repository It fits the scheme of the others and makes it easier for repository@ to have a clue what is going on. +1 Sounds like a sane and reasonable plan. If we need snapshot or plugin repositories later on we can add them. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [RESULTS] CeltiXfire Project Proposal
On 24 Jul 06, at 1:06 PM 24 Jul 06, Adinarayana Sakala wrote: Great. In the interim i will go over the committer list and get the paper work thing sorted out. Once the mailing list is setup we can probably start having these type of discussions over there. For the website, you mean Incubator project status website? http://incubator.apache.org/projects/tuscany.html That page and the generate site like http://incubator.apache.org/ tuscany/ Jason. Thanks, Adi On 7/24/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 24 Jul 06, at 11:51 AM 24 Jul 06, Adinarayana Sakala wrote: This is great news. Thanks everybody. What is the next administrative step in the process? I'm getting the mailing lists setup and I will get a first version of the site going. Once the lists are up we can discuss bring the code into Apache. Jason. - Adi On 7/22/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, About 10 days has elapsed so I'm going to close the vote on CeltixFire and say it's been accepted by the PMC Incubator, the binding votes are below and I've included the voting thread for reference. Jason van Zyl James Strachan Peter Royal Alex Karasulu Brett Porter Martin van den Bemt Robert Burrell Donkin Sanjiva Weerawarana Henri Yandell Cliff Schmidt Noel Bergman http://mail-archives.apache.org/mod_mbox/incubator-general/ 200607.mbox/[EMAIL PROTECTED] (that's the initial messsage, can't figure out how to get a link for a thread) Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Adi Sakala http://celtix.objectweb.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Adi Sakala http://celtix.objectweb.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [RESULTS] CeltiXfire Project Proposal
On 24 Jul 06, at 11:51 AM 24 Jul 06, Adinarayana Sakala wrote: This is great news. Thanks everybody. What is the next administrative step in the process? I'm getting the mailing lists setup and I will get a first version of the site going. Once the lists are up we can discuss bring the code into Apache. Jason. - Adi On 7/22/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, About 10 days has elapsed so I'm going to close the vote on CeltixFire and say it's been accepted by the PMC Incubator, the binding votes are below and I've included the voting thread for reference. Jason van Zyl James Strachan Peter Royal Alex Karasulu Brett Porter Martin van den Bemt Robert Burrell Donkin Sanjiva Weerawarana Henri Yandell Cliff Schmidt Noel Bergman http://mail-archives.apache.org/mod_mbox/incubator-general/ 200607.mbox/[EMAIL PROTECTED] (that's the initial messsage, can't figure out how to get a link for a thread) Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Adi Sakala http://celtix.objectweb.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] [RESULTS] CeltiXfire Project Proposal
Hi, About 10 days has elapsed so I'm going to close the vote on CeltixFire and say it's been accepted by the PMC Incubator, the binding votes are below and I've included the voting thread for reference. Jason van Zyl James Strachan Peter Royal Alex Karasulu Brett Porter Martin van den Bemt Robert Burrell Donkin Sanjiva Weerawarana Henri Yandell Cliff Schmidt Noel Bergman http://mail-archives.apache.org/mod_mbox/incubator-general/ 200607.mbox/[EMAIL PROTECTED] (that's the initial messsage, can't figure out how to get a link for a thread) Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DOAP files for Podling
On 18 Jul 06, at 12:04 PM 18 Jul 06, Jason van Zyl wrote: Hi, I setup a JIRA project if anyone finds any glitches in the output: http://jira.codehaus.org/browse/MDOAP I've created an official release of the plugin and there is some documentation now: http://maven.apache.org/plugins/maven-doap-plugin/ Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [RESULTS] CeltiXfire Project Proposal
Hi, Dim's pointed me at the thread in theaimsgroup archive: http://marc.theaimsgroup.com/?t=11527733822r=1w=2 That might be easier to follow. Thanks, On 22 Jul 06, at 8:41 AM 22 Jul 06, Jason van Zyl wrote: Hi, About 10 days has elapsed so I'm going to close the vote on CeltixFire and say it's been accepted by the PMC Incubator, the binding votes are below and I've included the voting thread for reference. Jason van Zyl James Strachan Peter Royal Alex Karasulu Brett Porter Martin van den Bemt Robert Burrell Donkin Sanjiva Weerawarana Henri Yandell Cliff Schmidt Noel Bergman http://mail-archives.apache.org/mod_mbox/incubator-general/ 200607.mbox/[EMAIL PROTECTED] (that's the initial messsage, can't figure out how to get a link for a thread) Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [RESULTS] CeltiXfire Project Proposal
On 22 Jul 06, at 4:21 PM 22 Jul 06, Justin Erenkrantz wrote: On 7/22/06, Jason van Zyl [EMAIL PROTECTED] wrote: http://mail-archives.apache.org/mod_mbox/incubator-general/ 200607.mbox/[EMAIL PROTECTED] (that's the initial messsage, can't figure out how to get a link for a thread) Um, click on the right-arrow/chevron next to the word Thread? -- justin Sorry, don't see it. What's the URL I can click on to show the thread? Using the link I think I can use always take me to all the threads which is this: http://mail-archives.apache.org/mod_mbox/incubator-general/ 200607.mbox/browser - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [UPDATE] CeltiXfire Project Proposal
On 18 Jul 06, at 9:38 PM 18 Jul 06, Noel J. Bergman wrote: Jason, I am +1 for the project, overall. I do suggest that we start out with the PPMC of you and the other Mentors, have you bring Dan and other appropriate people onto the PMC as your first order of business, and them go about selecting Committers. From what I recall at ApacheCon, there was some uncertaintly about the current roster, so let's allow the PPMC to review and address as appropriate. Sure, once the vote is formally complete and we move on the next phase I'll get that rolling. As was discussed at ApacheCon EU, I hope that the project will continue efforts to collaborate with the rest of the Web Services community at the ASF, because I hate to see wasted, redundant, effort when collaboration is possible. And it certainly appears from discussion that they are willing to explore any number of options. I think Dan has shown from past efforts that he's always worked well with the WS efforts and has a good relationship with them and will continue that trend. The rest of us will follow Dan's example there so I think we'll be fine. So give it your best effort, and good luck. :-) Thanks, much appreciated. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
