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
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 [
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: [POLL] Incubator Maven Repository
William A. Rowe, Jr. wrote: I agree there is no reason to force org.apache.incubating.wicket. to be renamed after graduation to org.apache.wicket. Agreed, but why is anyone even raising the issue? We don't require incubator to be part of the Java package name, just in distribution file system artifacts. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
+1 Noel. Synapse used to have org.apache.synapse.* as the package, but synapse-incubating-core-0.xx.jar as the JAR file. I'm +1 for using the ordinary repository. Paul On 5/8/07, Noel J. Bergman [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: I agree there is no reason to force org.apache.incubating.wicket. to be renamed after graduation to org.apache.wicket. Agreed, but why is anyone even raising the issue? We don't require incubator to be part of the Java package name, just in distribution file system artifacts. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 5/7/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Xavier Hanin wrote: On 5/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: This is already a concern for existing projects coming from outside Apache. It is completely and easily possible to become dependent on both org.apache.wicket/wicket-1.3.0-incubating-beta1.jar and wicket/wicket-1.2.6.jar I agree, but why add one more possible confusion for your users, and one more possible case for this kind of conflict? I think using only a tag in the version (as you have done for your 1.3 beta 1 version) is enough and less confusing. I disagree in part, incubating needs to preceed a version number because it's in descending significance (subversion .0 is less significant that version-major 1). So either incubating-wicket-1.3.0-beta1 or else use wicket-incubating-1.3.0-beta - the later is more readable to me. I agree with your logic, but putting the 'incubating' as a version suffix makes the use easier from a dependency management tool: you can depend on version 1.3+ for instance, and get an automatic transition at graduation (if we assume the project graduates before the final 1.3 release, which is what I hope for wicket :-)). Xavier I agree there is no reason to force org.apache.incubating.wicket. to be renamed after graduation to org.apache.wicket. I can't envision where another project will 'adopt' the o.a.wicket. space if it failed to graduate, and that they wouldn't be watching the providence of o.a.wicket if they choose to. I think it's a disservice to our podling's community of early adopters/testers/documentors/coders. Bill . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On May 6, 2007, at 1:57 PM, 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 I don't understand the question, but I think the answer can be deduced from this: Any [1] artifact that is released by The Apache Software Foundation MUST have http://www.apache.org/dist/ as its primary download location and it MUST follow all the central infrastructure guidelines (eg, mirroring, signing) that exist for that location. Similarly Any artifact that does NOT come from http://www.apache.org/dist/ is NOT an official release by The Apache Software Foundation, though it may be a redistribution of such a release, which users are encouraged to verify using PGP signature files and/or SHA1 digest files retrieved from http://www.apache.org/dist/. The ASF welcomes and appreciates redistribution of its existing artifacts. I think the above essentially captures what came out of the 500-mail- or-so discussion and vote that we had recently. IOW it is all fine and dandy if files go all across the globe (or apache servers) as long as they're redistributed from /dist/ somehow. My favorite change was when the ibiblio maven repo was set up to auto-sync from / dist/ (no idea if it still works that way). That loads of users find it quite alright to ignore checksums and signature sanity and just get things out of badly policied repositories (note: I'm not saying the maven repos are badly policied, I think there's a lot of due dilligence going on there, but that wasn't always the case), is well, not part of our own policies. cheers, - Leo [1] this is a recent change from how incubator has done this for a few years, where we made an exception to this rule for artifacts from the incubator. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
Xavier Hanin wrote: On 5/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: This is already a concern for existing projects coming from outside Apache. It is completely and easily possible to become dependent on both org.apache.wicket/wicket-1.3.0-incubating-beta1.jar and wicket/wicket-1.2.6.jar I agree, but why add one more possible confusion for your users, and one more possible case for this kind of conflict? I think using only a tag in the version (as you have done for your 1.3 beta 1 version) is enough and less confusing. I disagree in part, incubating needs to preceed a version number because it's in descending significance (subversion .0 is less significant that version-major 1). So either incubating-wicket-1.3.0-beta1 or else use wicket-incubating-1.3.0-beta - the later is more readable to me. I agree there is no reason to force org.apache.incubating.wicket. to be renamed after graduation to org.apache.wicket. I can't envision where another project will 'adopt' the o.a.wicket. space if it failed to graduate, and that they wouldn't be watching the providence of o.a.wicket if they choose to. I think it's a disservice to our podling's community of early adopters/testers/documentors/coders. Bill . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[POLL] Incubator Maven Repository
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 - 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]
Re: [POLL] Incubator Maven Repository
On 5/6/07, robert burrell donkin [EMAIL PROTECTED] wrote: [X] use standard repositories I would say that podlings using maven would be required to set their project's group id to org.apache.incubator.podling, and possibly even extend an incubator parent pom. This way the podling distributables are nicely contained inside the incubator space inside the maven repository. There would not be a requirement to name the java packages to org.apache.incubator.podling (as that would require renaming of all projects that are using the code, which is unnecessary IMO). Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 5/6/07, Daniel Kulp [EMAIL PROTECTED] wrote: I disagree with setting the groupId to org.apache.incubator.podling. I greatly prefer requiring a version string that includes either incubator or incubating.(ex: 2.0-incubator, 1.3-incubating, etc..) Putting it in the group ID causes a MUCH larger set of headaches for both the project itself as well as all dependent projects upon graduation. You can also end up with two jars on the classpath with the same code in it, just different versions. This is already a concern for existing projects coming from outside Apache. It is completely and easily possible to become dependent on both org.apache.wicket/wicket-1.3.0-incubating-beta1.jar and wicket/wicket-1.2.6.jar Only _not_ depending on podling releases will prevent this for depending projects. Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
On 5/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: On 5/6/07, Daniel Kulp [EMAIL PROTECTED] wrote: I disagree with setting the groupId to org.apache.incubator.podling. I greatly prefer requiring a version string that includes either incubator or incubating.(ex: 2.0-incubator, 1.3-incubating, etc..) Putting it in the group ID causes a MUCH larger set of headaches for both the project itself as well as all dependent projects upon graduation. You can also end up with two jars on the classpath with the same code in it, just different versions. This is already a concern for existing projects coming from outside Apache. It is completely and easily possible to become dependent on both org.apache.wicket/wicket-1.3.0-incubating-beta1.jar and wicket/wicket-1.2.6.jar I agree, but why add one more possible confusion for your users, and one more possible case for this kind of conflict? I think using only a tag in the version (as you have done for your 1.3 beta 1 version) is enough and less confusing. Xavier Only _not_ depending on podling releases will prevent this for depending projects. Martijn -- Learn Wicket at ApacheCon Europe: http://apachecon.com Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
[ 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]
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: [POLL] Incubator Maven Repository
[ ] 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]
Re: [POLL] Incubator Maven Repository
On 5/6/07, Jason van Zyl [EMAIL PROTECTED] wrote: 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? dunno - anyone have an url? Was that vote not definitive? in the incubator, if the vote doesn't include a patch for policy then it tends to get forgotten - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [POLL] Incubator Maven Repository
Jason, Would you please address Shane's issues? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
[X ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator On May 6, 2007, at 4:57 AM, 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 When you talk about repositories it makes me very nervous. Maven does not do a good job with multiple repositories. [If you have a single SNAPSHOT dependency, maven searches through every repository looking for each SNAPSHOT at least once per day and if the repository is not extremely responsive, you end up wasting a lot of time.] So if we choose for special incubator repositories, I'd have to vote in favor of a single incubator repository not multiple repositories. But having read all of the other responses as of right now, I don't see any issues with using the standard maven repository for publishing incubating project release artifacts. The releases are official incubating artifacts that have been through release clearance and as long as they are correctly identified with - incubating in their [version id, artifact id, or group id], IMHO no one will be confused about the status of the artifact. And whether to put -incubating into the group id, artifact id, or version id, I'd leave that decision up to the project. My own preference is in the version id, but I can see reasons for projects preferring the -incubating flag in any of the maven name locations. Craig of course, staging for the purpose of release verification would continue to happen under people.apache.org - 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] Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: [POLL] Incubator Maven Repository
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: [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]
Re: [POLL] Incubator Maven Repository
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 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: [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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]