db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: Recording published Maven 2 artifacts
Date Tue, 19 Oct 2010 14:14:46 GMT
  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 artifacts
>>>>> are broken, and that 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 is
>>>> the good distribution and 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-

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!

>> 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 
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 

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?

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?

In my world (if I got into trouble in the first place), I would type 
"maven derby 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 "" with "" and off I go.
Now, doing just that, this is the first hit on the list: 


> Thanks,
> -Rick
>> ---
>> [Deprecated Maven Artifacts]
>> Maven artifacts are produced for each release. It usually takes some 
>> days before they are generally available, as they must be deployed by 
>> the release manager and pass through a staging process.
>> The group id for the Derby artifacts is org.apache.derby. If you 
>> experience problems with the Apache Derby artifacts, please let us 
>> know at derby-user AT db DOT apache DOT org.
>> The following artifacts are invalid, and have been deprecated:
>>  o, all artifacts: Invalid POMs, use version 
>> instead.
>> ---

View raw message