Re: making project decisions with a small number of PMC members
On May 15, 2007, at 12:26 AM, Brett Porter wrote: Quick question (I hope). I was thinking about what will happen if the NMaven podling would like to add a committer, make a release, etc. Would votes by Maven PMC members (As the sponsoring project) be considered binding in this case, or should we have IPMC members? No the sponsoring PMC votes are not binding. It should be the IPMC. We currently only have 2 IPMC members on the project, so I was going to ask for an additional mentor anyway, but I feel like the appropriate people to be casting votes should be Maven PMC folk. Thoughts? I share your feeling. I'm afraid it is not so easy to change. * ASF is structured to have a PMC (or Officer) responsible and accontable for most things * ASF is not structured for multiple PMCs or Officers to share responsibility Changing this is a lot of work (for example it screws up the workflow for infrastructure since it becomes much harder to know if a request came with the right authority), so I've always shunned away from it. As to which PMC *should* be responsible for *what*, it depends. We've seen projects were it was really needed for the Incubator PMC to take the responsibility for a TLP-sponsored podling, and then some projects where the IPMC was hardly ever needed at all. (aside: some of the original designs for the incubator introduced the PPMC that would consist of * incubator PMC * sponsoring PMC * all committers on the new project * all mentors of the project where the goal would sort-of be to have the committers make the actual decisions and then the IPMC and sponsoring PMC would reluctantly fill in the gaps. We had to move away from that because it broke the clear accountability chain; Secondly, a lot of sponsoring PMC members and IPMC members didn't want to be on that many mailing lists. So now we have a PPMC which is really just the committers on the project with their mentors, and it's supposedly no longer allowed to make any real decisions. Not so great a situation either.) /LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Ratify the release of Apache Tuscany SDO 1.0-incubating-beta1
Niall, many thanks for the fix. That's really helpful. With regards to the license issue, in the future I believe OSOA will publish the SDO APIs, in a maven repository, but that's not the case yet, and we need these artifacts to publish an SDO release. I believe that we are compliant with the Apache Treatment of 3rd Party Works policy in [1] as discussed in [2]. The discussions we have had in the Tuscany community [3][4] all suggest the course of action of releasing as we are at the moment, with a view to shifting the dependency onto OSOA provided artifacts when they are available. Many thanks, Kelvin. [1] http://www.apache.org/legal/src-headers.html [2] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200607.mbox/[EMAIL PROTECTED] [3] http://www.mail-archive.com/[EMAIL PROTECTED]/msg17270.html [4] http://www.mail-archive.com/[EMAIL PROTECTED]/msg17442.html On 14/05/07, Niall Pemberton [EMAIL PROTECTED] wrote: Ant refers to the need to clarify the use of the OSOA licensed code in the following message: http://www.mail-archive.com/[EMAIL PROTECTED]/msg17270.html: Not sure whats meant exactly by clarify - but sounds to me like something that should be done before a release? One minor nitpick with the release is that the MANIFEST files in the impl and tools jars have an Implementation-Version of incubating-M3 rather than 1.0-incubating-beta1 - would be better to have the version no. automatically generated, otherwise its a potential error for every release. I've created a possible patch for this: https://issues.apache.org/jira/browse/TUSCANY-1284 Otherwise looks good to me. Niall On 5/2/07, kelvin goodson [EMAIL PROTECTED] wrote: The Tuscany community held a vote to release Apache Tuscany SDO version 1.0-incubating-beta; see ref [0] below. Please vote to ratify this release. The release candidate RC1 for Tuscany Java SDO beta1 archive distribution files are posted at [1] The maven repository artifacts are posted in a staging repository [2] The release audit tool (rat) files and associated exceptions are attached to the jira under which the release work was done [3]. The tag for the source code is at [4] Changes in this release are shown in [5] [0] http://www.mail-archive.com/[EMAIL PROTECTED]/msg17099.html [1] http://people.apache.org/~kelvingoodson/sdo_java/beta1/RC1/ [2] http://people.apache.org/~kelvingoodson/repo/org/apache/tuscany/sdo/ [3] http://issues.apache.org/jira/browse/TUSCANY-1171 [4] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubating-beta1/ [5] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubating-beta1/sdo/distribution/RELEASE_NOTES.txt --- Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: guides/graduation
Craig, [EMAIL PROTECTED] and [EMAIL PROTECTED] I think On 5/14/07, Craig L Russell [EMAIL PROTECTED] wrote: Now I'm confused. Could someone put some alias names to these concepts? I thought we were talking about project-dev and project- user. What aliases are others referring to? Thanks, Craig On May 14, 2007, at 1:19 PM, robert burrell donkin wrote: On 5/14/07, Martin Sebor [EMAIL PROTECTED] wrote: Yoav Shapira wrote: Hi, On 5/14/07, Craig L Russell [EMAIL PROTECTED] wrote: The community mailing list is open to all Apache committers. This is the right list for questions about community and on community building. Subscriptions should be from an Apache email address. In my experience, the community mailing lists are open to everyone and it's not particularly useful to request that subscriptions be from an Apache email address. I like the last sentence. As a moderator for many ASF mailing lists, having subscription requests from apache.org addresses make like a lot easier. Please don't remove that last sentence ;) Since that particular list is indeed open to the world, maybe a slight rephrasing along the lines of if you've got an Apache address, please use it to subscribe would be better. I can see how posts from apache.org might make the job of moderator of heavy list easier but shouldn't it be left up to each individual project to decide if they want to tighten the subscription policy? AIUI we're talking about the community mailing list which is an apache wide list with no project affiliations - robert - 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! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANTED: Another Mentor for QPid
On 5/14/07, Martin Ritchie [EMAIL PROTECTED] wrote: Hi, just wanted to keep this thread alive as it has been almost a month and we are still a mentor short. I just saw this, I'd be happy to serve if needed, FWIW I work in Glasgow so I have some degree of geographical proximity with the QPid guys. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Ratify the release of Apache Tuscany SDO 1.0-incubating-beta1
On 5/15/07, kelvin goodson [EMAIL PROTECTED] wrote: Niall, many thanks for the fix. That's really helpful. With regards to the license issue, in the future I believe OSOA will publish the SDO APIs, in a maven repository, but that's not the case yet, and we need these artifacts to publish an SDO release. I believe that we are compliant with the Apache Treatment of 3rd Party Works policy in [1] as discussed in [2]. The discussions we have had in the Tuscany community [3][4] all suggest the course of action of releasing as we are at the moment, with a view to shifting the dependency onto OSOA provided artifacts when they are available. OK thanks for the explanation. A (non-binding) +1 from me. Many thanks, Kelvin. np Niall [1] http://www.apache.org/legal/src-headers.html [2] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200607.mbox/[EMAIL PROTECTED] [3] http://www.mail-archive.com/[EMAIL PROTECTED]/msg17270.html [4] http://www.mail-archive.com/[EMAIL PROTECTED]/msg17442.html On 14/05/07, Niall Pemberton [EMAIL PROTECTED] wrote: Ant refers to the need to clarify the use of the OSOA licensed code in the following message: http://www.mail-archive.com/[EMAIL PROTECTED]/msg17270.html: Not sure whats meant exactly by clarify - but sounds to me like something that should be done before a release? One minor nitpick with the release is that the MANIFEST files in the impl and tools jars have an Implementation-Version of incubating-M3 rather than 1.0-incubating-beta1 - would be better to have the version no. automatically generated, otherwise its a potential error for every release. I've created a possible patch for this: https://issues.apache.org/jira/browse/TUSCANY-1284 Otherwise looks good to me. Niall On 5/2/07, kelvin goodson [EMAIL PROTECTED] wrote: The Tuscany community held a vote to release Apache Tuscany SDO version 1.0-incubating-beta; see ref [0] below. Please vote to ratify this release. The release candidate RC1 for Tuscany Java SDO beta1 archive distribution files are posted at [1] The maven repository artifacts are posted in a staging repository [2] The release audit tool (rat) files and associated exceptions are attached to the jira under which the release work was done [3]. The tag for the source code is at [4] Changes in this release are shown in [5] [0] http://www.mail-archive.com/[EMAIL PROTECTED]/msg17099.html [1] http://people.apache.org/~kelvingoodson/sdo_java/beta1/RC1/ [2] http://people.apache.org/~kelvingoodson/repo/org/apache/tuscany/sdo/ [3] http://issues.apache.org/jira/browse/TUSCANY-1171 [4] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubating-beta1/ [5] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubating-beta1/sdo/distribution/RELEASE_NOTES.txt --- Kelvin. - 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: making project decisions with a small number of PMC members
Hi Brett, +1 to most of what Leo says. I'd point out that the main purpose of the PPMC is to get the podling to the point of making decisions the Apache Way and the IPMC then ratifies the decisions. This model should allow the decisions to be made by the people who know and care the most, while preserving the accountability that's legally required. So if you properly vote in the PPMC to accept a new committer, or vote on a new release, following the process in the incubator policy and guides, the IPMC will likely approve pretty quickly any decisions that are made. If you're having difficulty getting the binding IPMC votes after the PPMC votes, then this is an issue that needs to be addressed. Good luck, Craig On May 15, 2007, at 1:16 AM, Leo Simons wrote: On May 15, 2007, at 12:26 AM, Brett Porter wrote: Quick question (I hope). I was thinking about what will happen if the NMaven podling would like to add a committer, make a release, etc. Would votes by Maven PMC members (As the sponsoring project) be considered binding in this case, or should we have IPMC members? No the sponsoring PMC votes are not binding. It should be the IPMC. We currently only have 2 IPMC members on the project, so I was going to ask for an additional mentor anyway, but I feel like the appropriate people to be casting votes should be Maven PMC folk. Thoughts? I share your feeling. I'm afraid it is not so easy to change. * ASF is structured to have a PMC (or Officer) responsible and accontable for most things * ASF is not structured for multiple PMCs or Officers to share responsibility Changing this is a lot of work (for example it screws up the workflow for infrastructure since it becomes much harder to know if a request came with the right authority), so I've always shunned away from it. As to which PMC *should* be responsible for *what*, it depends. We've seen projects were it was really needed for the Incubator PMC to take the responsibility for a TLP-sponsored podling, and then some projects where the IPMC was hardly ever needed at all. (aside: some of the original designs for the incubator introduced the PPMC that would consist of * incubator PMC * sponsoring PMC * all committers on the new project * all mentors of the project where the goal would sort-of be to have the committers make the actual decisions and then the IPMC and sponsoring PMC would reluctantly fill in the gaps. We had to move away from that because it broke the clear accountability chain; Secondly, a lot of sponsoring PMC members and IPMC members didn't want to be on that many mailing lists. So now we have a PPMC which is really just the committers on the project with their mentors, and it's supposedly no longer allowed to make any real decisions. Not so great a situation either.) /LSD - 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! smime.p7s Description: S/MIME cryptographic signature
Re: guides/graduation
Hi Danny, Thanks for that. This does put a different slant on things. I intend to discuss all of these mailing lists along with the email alias file, posting to the lists, and subscribing to the lists, in the update. Craig On May 15, 2007, at 5:33 AM, Danny Angus wrote: Craig, [EMAIL PROTECTED] and [EMAIL PROTECTED] I think On 5/14/07, Craig L Russell [EMAIL PROTECTED] wrote: Now I'm confused. Could someone put some alias names to these concepts? I thought we were talking about project-dev and project- user. What aliases are others referring to? Thanks, Craig On May 14, 2007, at 1:19 PM, robert burrell donkin wrote: On 5/14/07, Martin Sebor [EMAIL PROTECTED] wrote: Yoav Shapira wrote: Hi, On 5/14/07, Craig L Russell [EMAIL PROTECTED] wrote: The community mailing list is open to all Apache committers. This is the right list for questions about community and on community building. Subscriptions should be from an Apache email address. In my experience, the community mailing lists are open to everyone and it's not particularly useful to request that subscriptions be from an Apache email address. I like the last sentence. As a moderator for many ASF mailing lists, having subscription requests from apache.org addresses make like a lot easier. Please don't remove that last sentence ;) Since that particular list is indeed open to the world, maybe a slight rephrasing along the lines of if you've got an Apache address, please use it to subscribe would be better. I can see how posts from apache.org might make the job of moderator of heavy list easier but shouldn't it be left up to each individual project to decide if they want to tighten the subscription policy? AIUI we're talking about the community mailing list which is an apache wide list with no project affiliations - robert - 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! - 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! smime.p7s Description: S/MIME cryptographic signature
RE: Demote TSIK to dormant
I already did this a while back... http://incubator.apache.org/projects/index.html where else do i have to do it? Remove it from incubator-info.txt (and from the Wiki reporting pages). Again, the redundant data problem raises its ugly head. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Demote TSIK to dormant
It's not on the wiki pages either...i'll look into the incubator-info.txt (svn?) thanks, dims On 5/15/07, Noel J. Bergman [EMAIL PROTECTED] wrote: I already did this a while back... http://incubator.apache.org/projects/index.html where else do i have to do it? Remove it from incubator-info.txt (and from the Wiki reporting pages). Again, the redundant data problem raises its ugly head. --- Noel - 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]
Re: making project decisions with a small number of PMC members
Thanks folks. What Leo and Craig said is what I expected, though I was a bit concerned about finding the IPMC people to ratify such decisions. I'll still look for more mentors. - Brett On 15/05/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Brett, +1 to most of what Leo says. I'd point out that the main purpose of the PPMC is to get the podling to the point of making decisions the Apache Way and the IPMC then ratifies the decisions. This model should allow the decisions to be made by the people who know and care the most, while preserving the accountability that's legally required. So if you properly vote in the PPMC to accept a new committer, or vote on a new release, following the process in the incubator policy and guides, the IPMC will likely approve pretty quickly any decisions that are made. If you're having difficulty getting the binding IPMC votes after the PPMC votes, then this is an issue that needs to be addressed. Good luck, Craig On May 15, 2007, at 1:16 AM, Leo Simons wrote: On May 15, 2007, at 12:26 AM, Brett Porter wrote: Quick question (I hope). I was thinking about what will happen if the NMaven podling would like to add a committer, make a release, etc. Would votes by Maven PMC members (As the sponsoring project) be considered binding in this case, or should we have IPMC members? No the sponsoring PMC votes are not binding. It should be the IPMC. We currently only have 2 IPMC members on the project, so I was going to ask for an additional mentor anyway, but I feel like the appropriate people to be casting votes should be Maven PMC folk. Thoughts? I share your feeling. I'm afraid it is not so easy to change. * ASF is structured to have a PMC (or Officer) responsible and accontable for most things * ASF is not structured for multiple PMCs or Officers to share responsibility Changing this is a lot of work (for example it screws up the workflow for infrastructure since it becomes much harder to know if a request came with the right authority), so I've always shunned away from it. As to which PMC *should* be responsible for *what*, it depends. We've seen projects were it was really needed for the Incubator PMC to take the responsibility for a TLP-sponsored podling, and then some projects where the IPMC was hardly ever needed at all. (aside: some of the original designs for the incubator introduced the PPMC that would consist of * incubator PMC * sponsoring PMC * all committers on the new project * all mentors of the project where the goal would sort-of be to have the committers make the actual decisions and then the IPMC and sponsoring PMC would reluctantly fill in the gaps. We had to move away from that because it broke the clear accountability chain; Secondly, a lot of sponsoring PMC members and IPMC members didn't want to be on that many mailing lists. So now we have a PPMC which is really just the committers on the project with their mentors, and it's supposedly no longer allowed to make any real decisions. Not so great a situation either.) /LSD - 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! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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 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: general- [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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail:
Re: [POLL] Incubator Maven Repository
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, 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 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 [
[VOTE] Release Apache ODE 1.0
The ODE community held a vote for its first incubator release. See [1] for the tally of 6 +1s (including one mentor vote) and no 0 or -1s. We're now asking for a vote by the incubator PMC to authorize the publication of our 1.0 release. The release consists of 3 different artifacts: - A WAR-based distribution [2] - A JBI-based distribution [3] - A source distribution [4] Please cast your votes: [ ] +1 release is approved [ ] -1 veto the release (provide specific comments) Thanks! Matthieu [1] http://mail-archives.apache.org/mod_mbox/incubator-ode-dev/200705.mbox/[EMAIL PROTECTED] [2] http://people.apache.org/~mriou/ode-1.0-RC3/org/apache/ode/apache-ode-war/1.0-RC3-incubating/ http://people.apache.org/%7Emriou/ode-1.0-RC3/org/apache/ode/apache-ode-war/1.0-RC3-incubating/ [3] http://people.apache.org/~mriou/ode-1.0-RC3/org/apache/ode/apache-ode-jbi/1.0-RC3-incubating/http://people.apache.org/%7Emriou/ode-1.0-RC3/org/apache/ode/apache-ode-jbi/1.0-RC3-incubating/ [4] http://people.apache.org/~mriou/ode-1.0-RC3/org/apache/ode/apache-ode-sources/1.0-RC3-incubating/http://people.apache.org/%7Emriou/ode-1.0-RC3/org/apache/ode/apache-ode-sources/1.0-RC3-incubating/
RE: [POLL] Incubator Maven Repository
Although HTTP GET with a URL may qualify as an API, under its current form its really implementation (file-system) specific. What makes it implementation specific? You can't store the files in a DB, and map the URI to the resource? Isn't it really a URI, specifying the package name and version? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 5/15/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Although HTTP GET with a URL may qualify as an API, under its current form its really implementation (file-system) specific. What makes it implementation specific? You can't store the files in a DB, and map the URI to the resource? Isn't it really a URI, specifying the package name and version? well, a bit more than that but it is definitely an URI resolving URI-URL allows the artifact to be retrieved - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
Hi Noel, Correct, using a URI does not require a specific implementation; but in today's environment, if someone needs a different repo format, they get one of two responses: 1) create your own repo that uses a different repo format; or 2) use the same repo format but transform the artifact names. Thus, the repos - as they exists within the community - are, for all effective purposes, implementation specific: none of them can be used for custom formats. Thus the API is adequate, but the implementation may prove problematic in the long run. I decided to go with option 2; but the point is that this issue will keep coming up as developers add new languages and require new formats. Regards, Shane On 5/15/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Although HTTP GET with a URL may qualify as an API, under its current form its really implementation (file-system) specific. What makes it implementation specific? You can't store the files in a DB, and map the URI to the resource? Isn't it really a URI, specifying the package name and version? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yoko Incubator Report?
OK...I'll get it done for next month. Darren On 5/14/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Darren Middleman wrote: Sorry about the incubator report, I didn't realize it was that time already. I'll get this together and post it to the Wiki tomorrow (Tuesday). That will be too late. Please submit it for next month. Don't plan on any releases until after the report has been filed. --- Noel
