db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Recording published Maven 2 artifacts
Date Tue, 19 Oct 2010 15:41:38 GMT
Kristian Waagan wrote:
>  On 19.10.10 14:52, Rick Hillegas wrote:
>> Kristian Waagan wrote:
>>>  On 12.10.10 16:05, Knut Anders Hatlen wrote:
>>>> Rick Hillegas<rick.hillegas@oracle.com>  writes:
>>>>
>>>>> Knut Anders Hatlen wrote:
>>>>>> Rick Hillegas<rick.hillegas@oracle.com>  writes:
>>>>>>
>>>>>>
>>>>>>> I agree that most developers won't care about this file. It is
>>>>>>> interesting archeology for release managers, though.
>>>>>>>
>>>>>> The most interesting thing in the list is that the 10.5.3.0 
>>>>>> artifacts
>>>>>> are broken, and that 10.5.3.0_1 should be used instead. I think 
>>>>>> this is
>>>>>> something that would interest our users too, which may suggest 
>>>>>> that we
>>>>>> shouldn't hide this information in the source repository?
>>>>>>
>>>>>>
>>>>> I agree that users would be interested in knowing that 10.5.3.0_1 is
>>>>> the good distribution and 10.5.3.0 has been deprecated. Where would a
>>>>> typical maven user expect to find that information? I don't use maven
>>>>> much, so I don't think I could answer that question.
>>>> I have no idea about the Maven users, but I suppose a typical Derby 
>>>> user
>>>> would scan the Derby website and the wiki. That said, I haven't been
>>>> able to find any information on our website/wiki on how to add 
>>>> Derby to
>>>> your Maven project, or any mentioning that we have Maven artifacts for
>>>> that matter, so I don't think we have any natural place to add this
>>>> information right now.
>>>>
>>>
>>> Thanks for the feedback, guys.
>>>
>>> For now I have updated maven2/README.txt on trunk (r1024149), after 
>>> having confirmed that the artifacts have been copied from the Apache 
>>> staging repository to the central Maven repository. It has also 
>>> showed up in various other repositories/aggregator sites.
>>>
>>> Given that we produce Maven artifacts as part of our release 
>>> process, maybe it would be enough to state that fact somewhere? We 
>>> should also mention that the artifacts usually arrive a little later 
>>> than the release itself due to the staging process.
>>> In addition, we should have a way to tell users about 
>>> deprecated/invalid artifacts. I think the website is a better guess 
>>> than the wiki for where [Maven] users go to find this type of 
>>> information, but I don't have any proof to back that up.
>>>
>>> The advantage of the described approach is that, except for the 
>>> one-time initial effort, the release manager doesn't have to do 
>>> anything in the normal case. Only when the community deploys broken 
>>> artifacts, action is required.
>>>
>>> I'm thinking http://db.apache.org/derby/derby_downloads.html
>> Thanks for that analysis, Kristian.
>>
>> Isn't the Maven repository just another distribution channel for our 
>> release artifacts? It's a channel which works with Maven's dependency 
>> system. Don't know if it's mirrored. I think that a better place for 
>> this information would be on the download page for the release 
>> itself, in the Distributions section. E.g.: 
>> http://db.apache.org/derby/releases/release-10.6.2.1.cgi#Distributions
>
> Hi Rick,
>
> I agree Maven can be seen as just another distribution channel.
> If anyone has a suggestion for some text for the release distributions 
> page, that would be great!
Hi Kristian,

I would keep this simple. At the end of the Distributions section of the 
release download page, we can just have a one line reference:

"Maven repository for 10.6.2.1: https://blah/blah/blah"
>
>>
>>> Can we simply add a header "Deprecated Maven Artifacts"?
>> Don't see much reason to advertise the deprecated artifacts. I can't 
>> think of any reason that a user would need to know about any 
>> distribution channels other than the ones which we approve.
>
> We want to "advertise" the deprecated artifacts for the same reason as 
> we are advertising the deprecated Derby versions: we don't want users 
> to use them - either because they simply don't work or because they 
> contain severe bugs. The other reason is that we cannot remove the 
> artifacts once they have been published (do we need better testing 
> before deployment?).
> There are two different scenarios:
>  a) Derby version deprecated implies that the corresponding Maven 
> artifacts are deprecated as well.
>  b) Broken Maven artifacts doesn't imply that the Derby version is 
> deprecated.
>
> I think we already cover (a) implicitly under "Deprecated Releases". 
> We are discussing a home for (b).
> On the other side, now that the Maven scripts we use seem to have 
> stabilized, maybe we can just kill off this discussion right away, in 
> the hope that we won't produce any more broken artifacts?
+1 to killing off this discussion. I'm not planning to make this mistake 
again.
>
> As for your other point - are you saying we don't approve the Maven 
> artifacts? (we are the ones producing and deploying them)
> In that case, do we have to change our release process?
Nothing fancy meant here, either. By "approved" I just mean the channels 
we bother to advertise. Derby release artifacts can turn up anywhere: 
our users can independently re-publish our artifacts and the Maven team 
can move stuff around. But we don't advertise those other locations. The 
deprecated Maven junk is just another location we don't bother to advertise.
>
> In my world (if I got into trouble in the first place), I would type 
> "maven derby 10.5.3.0 error" into a search engine and the first hit 
> would tell me that the problem I'm experiencing lies with the 
> artifacts themselves and not my own POM :) The other important piece 
> of information is that I can replace "10.5.3.0" with "10.5.3.0_1" and 
> off I go.
> Now, doing just that, this is the first hit on the list: 
> https://issues.apache.org/jira/browse/DERBY-4390
If the Maven team wants people to use their distribution channel, then 
they should fix the policies which prevented them from putting our good 
artifacts in a directory with the correct name.

I would feel differently if our users were complaining to us about 
deprecated Maven artifacts. As far as I can see, once we corrected our 
artifacts, the complaints died down.

Thanks,
-Rick
>
>
> Regards,


Mime
View raw message