That's the way I feel as well. The maven repo exists to make lives easier for people - its an easy way to pick up dependencies if you need them - nothing more. It is primarily organized by domain names, so, if you have an org.apache.incubator.podlingname group id, you're just following convention expected by pretty much everyone.
This is a _good thing_ - it is expected behavior, makes things easy for people, and is extremely clear that its not an ASF top level project. IMO, that is all that end-users really care about. Isn't that good enough? I feel with comfortable certainty that the large majority of people will be perfectly fine with that, and because it does not require manual intervention, would probably prefer it. On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <[EMAIL PROTECTED]> wrote: > So it seems that a valid question is whether or not publishing to one > repository or another indicates an endorsement. I don't personally see it > that way. Just because ASF makes a release available via a maven repository > isn't the same thing as endorsement to me, just as the fact that the Apache > (Incubator) name may be used in reference to a project or that Apache is > hosting the project doesn't mean it's necessarily endorsing it. > > I think that if a developer doesn't understand his project's dependencies, > that's certainly a problem. But I worry that forcing them to go through > extra steps of adding a special repository, approving a special key, etc. > makes it seem like the software isn't trustworthy and could hinder adoption. > > To my mind, "incubator project" does not necessarily imply instability. > Where it's hosted in maven doesn't necessarily imply endorsement. The fact > that the project is in the incubator and the names include incubating is > what indicates that it isn't an ASF endorsed project yet. > > Jeremy > > On May 30, 2008, at 11:14 AM, James Carman wrote: > >> The bottom line is that incubator projects haven't (yet) gone through >> all the hoops necessary to become official ASF projects. So, if they >> are published to the main repository, that is in a way saying that the >> ASF endorses the software. Since it has not graduated from the >> incubator, the ASF doesn't yet endorse it. This is the way I see it >> at least. >> >> On Fri, May 30, 2008 at 11:06 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >>> >>> Noel, >>> >>> Could you please help me understand the fundamental reasons why this >>> is important to the IPMC? >>> >>> I mean, I as an end-user could care less about if the dependency >>> artifact is in incubation or not - as long as it solves the problems >>> in the way the development team deems necessary, all I want to do is >>> just have be accessible to me immediately. I don't care where it >>> comes from. If it requires intervention on my part, I view that as a >>> major pain, especially if it can knowingly be avoided. I would want >>> things to be as automatic and hands-off as possible. >>> >>> I'm just genuinely trying to understand why the distinction is necessary. >>> >>> Thanks for clarifying my naivety, >>> >>> Les >>> >>> On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman <[EMAIL PROTECTED]> >>> wrote: >>>> >>>> Robert Burrell Donkin wrote: >>>> >>>>> it has now been clearly established that we need to move the >>>>> repository. we're now just asking: where? >>>> >>>> As I said, Brett Porter's proposal, made early on in the thread, seemed >>>> satisfactory. >>>> >>>>> asking podlings to publish through a secondary repository is both >>>>> annoying and ineffective at making it explicit to people that >>>>> they are using artifacts under incubation. this measure cuts >>>>> against the grain of maven. >>>> >>>> I really don't care what cuts across the grain of Maven. I do care >>>> about >>>> the established principle that people must make a deliberate decision to >>>> use >>>> Incubator artifacts. If Maven would finally support enforcing signing >>>> of >>>> artifacts, as they have been asked to do for years, we could use an >>>> Incubator-specific signing key, forcing people to approve the use of >>>> Incubator artifacts, regardless of download location. >>>> >>>> Rather than relax the principle to accomodate a defective tool, if Maven >>>> cannot solve this problem, I'd be more inclined to ban the use of maven >>>> repositories for Incubator artifacts. That is how strongly I feel about >>>> the >>>> principle. >>>> >>>> By the way, there has been some talk in Infrastructure about shutting >>>> down >>>> the ASF's repository entirely if Maven does not provide enforcement of >>>> signed artifacts, due to security concerns. >>>> >>>> Look back over the years of debate on this issue, and I believe that you >>>> will find I've been very consistent. I want Incubator projects to be >>>> able >>>> to perform releases in order to grow their (developer) community, but we >>>> also require that people be aware of the fact that they are not using >>>> official ASF code, as noted by the disclaimer. >>>> >>>>> an easy and effective way to ensure that users know that they are using >>>>> an artifact from the incubator would be to ensure that the group or >>>>> artifact ID includes this information. >>>> >>>> End users don't read the POM. They just use it. So that is no solution >>>> at >>>> all. The signing approach would be, IMO, a reasonable solution. It >>>> would >>>> solve Les' issue -- users would simply have to agree to install the >>>> Incubator-signed artifact(s), and thereafter they'd be fine. >>>> >>>> --- 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] >>> >>> >> >> --------------------------------------------------------------------- >> 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]
