You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kristian Waagan <kr...@oracle.com> on 2010/10/12 10:42:43 UTC
Recording published Maven 2 artifacts
Hi,
When I worked on the scripts generating and publishing the Maven 2
artifacts, I added a release history to the maven2/README.txt file. This
file exists on every branch.
I did not think a lot about how this would work out as we publish new
releases. Its only purpose is to serve as a record for artifacts
released by the Derby community. I don't think Derby users will read it.
Keeping it up to date on all branches seems like a drag. Here are some
options, including the tedious one:
a) Update trunk, merge to all branches.
b) Update trunk, merge to release branch.
Merging may not work here, so we may have to simply update the
file directly on both trunk and the release branch.
c) Update trunk only.
I have chosen to always update trunk so that we have a place where we
keep the full history.
Any opinions on this?
I'm leaning towards (c) for simplicity. I prefer to avoid (a).
Regards,
--
Kristian
Re: Recording published Maven 2 artifacts
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Kristian Waagan <kr...@oracle.com> writes:
> Hi,
>
> When I worked on the scripts generating and publishing the Maven 2
> artifacts, I added a release history to the maven2/README.txt
> file. This file exists on every branch.
> I did not think a lot about how this would work out as we publish new
> releases. Its only purpose is to serve as a record for artifacts
> released by the Derby community. I don't think Derby users will read
> it. Keeping it up to date on all branches seems like a drag. Here are
> some options, including the tedious one:
>
> a) Update trunk, merge to all branches.
> b) Update trunk, merge to release branch.
> Merging may not work here, so we may have to simply update the
> file directly on both trunk and the release branch.
> c) Update trunk only.
>
> I have chosen to always update trunk so that we have a place where we
> keep the full history.
>
> Any opinions on this?
> I'm leaning towards (c) for simplicity. I prefer to avoid (a).
Hi Kristian,
Of those three options, I agree that (b) and (c) sound like less work
than (a). But do we need to keep this in the repository? Perhaps a wiki
page would do? Then we'd only need to update the list a single place per
release.
You mentioned that users will probably not read the list. Is there any
reason why developers would read it? If not, we might just as well
remove it, since the release manager probably has enough tasks to
remember already.
--
Knut Anders
Re: Recording published Maven 2 artifacts
Posted by Kristian Waagan <kr...@oracle.com>.
On 20.10.10 18:41, Lily Wei wrote:
> Kristian Waagan wrote:
> > On 19.10.10 17:41, Rick Hillegas wrote:
[ snip ]
> > There is one thing I'd like to nail down though, and that is what
> the development community wants regarding the history section in
> maven2/README.txt. My motivation for this is that the current
> instructions are inaccurate and may cause a little extra hassle for
> the release manager.
> >
> > Based on the discussion we have had in this thread, I propose two
> options:
> > a) update the version living on trunk, regardless of release branch
> > b) remove it - leave no traces in the code repository of Maven
> artifact deployment, we will have to consult the Apache staging
> repository or the central Maven repository [1] to figure out what has
> been published
> >>
> >> Since I have been working a little with the Maven stuff, I'm
> comfortable with option (b). This will remove one small task for the
> release manager, so I'm giving it my +1.
> >+1 to reducing the complexity of our release process.
> +1. It is so nice that you are working with the Maven stuff. :-)
Hi all,
I removed the history section from the readme-file (tracked the work
under DERBY-4865), and I also removed the item instructing the release
manager to update the file in
http://wiki.apache.org/db-derby/ReleasePublication .
--
Kristian
>
> Thanks,
> Lily
>
Re: Recording published Maven 2 artifacts
Posted by Lily Wei <li...@yahoo.com>.
Kristian Waagan wrote:
> On 19.10.10 17:41, Rick Hillegas wrote:
>> Kristian Waagan wrote:
>>> On 19.10.10 14:52, Rick Hillegas wrote:
> [ snip ]
>>> 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.
>
> Since there doesn't seem to be a consensus on whether there is a need to
>improve the documentation of our Maven artifacts or not, I will put this on hold
>for now.
> We can continue the discussion if we get more complaints from users at some
>point.
>
> There is one thing I'd like to nail down though, and that is what the
>development community wants regarding the history section in maven2/README.txt.
>My motivation for this is that the current instructions are inaccurate and may
>cause a little extra hassle for the release manager.
>
> Based on the discussion we have had in this thread, I propose two options:
> a) update the version living on trunk, regardless of release branch
> b) remove it - leave no traces in the code repository of Maven artifact
>deployment, we will have to consult the Apache staging repository or the central
>Maven repository [1] to figure out what has been published
>>
>> Since I have been working a little with the Maven stuff, I'm comfortable with
>>option (b). This will remove one small task for the release manager, so I'm
>>giving it my +1.
>+1 to reducing the complexity of our release process.
+1. It is so nice that you are working with the Maven stuff. :-)
Thanks,
Lily
Re: Recording published Maven 2 artifacts
Posted by Rick Hillegas <ri...@oracle.com>.
Kristian Waagan wrote:
> On 19.10.10 17:41, Rick Hillegas wrote:
>> Kristian Waagan wrote:
>>> On 19.10.10 14:52, Rick Hillegas wrote:
> [ snip ]
>>> 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.
>
> Since there doesn't seem to be a consensus on whether there is a need
> to improve the documentation of our Maven artifacts or not, I will put
> this on hold for now.
> We can continue the discussion if we get more complaints from users at
> some point.
>
> There is one thing I'd like to nail down though, and that is what the
> development community wants regarding the history section in
> maven2/README.txt. My motivation for this is that the current
> instructions are inaccurate and may cause a little extra hassle for
> the release manager.
>
> Based on the discussion we have had in this thread, I propose two
> options:
> a) update the version living on trunk, regardless of release branch
> b) remove it - leave no traces in the code repository of Maven
> artifact deployment, we will have to consult the Apache staging
> repository or the central Maven repository [1] to figure out what has
> been published
>
> Since I have been working a little with the Maven stuff, I'm
> comfortable with option (b). This will remove one small task for the
> release manager, so I'm giving it my +1.
+1 to reducing the complexity of our release process.
Thanks,
-Rick
>
>
> Regards,
Re: Recording published Maven 2 artifacts
Posted by Kristian Waagan <kr...@oracle.com>.
On 19.10.10 17:41, Rick Hillegas wrote:
> Kristian Waagan wrote:
>> On 19.10.10 14:52, Rick Hillegas wrote:
[ snip ]
>> 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.
Since there doesn't seem to be a consensus on whether there is a need to
improve the documentation of our Maven artifacts or not, I will put this
on hold for now.
We can continue the discussion if we get more complaints from users at
some point.
There is one thing I'd like to nail down though, and that is what the
development community wants regarding the history section in
maven2/README.txt. My motivation for this is that the current
instructions are inaccurate and may cause a little extra hassle for the
release manager.
Based on the discussion we have had in this thread, I propose two options:
a) update the version living on trunk, regardless of release branch
b) remove it - leave no traces in the code repository of Maven
artifact deployment, we will have to consult the Apache staging
repository or the central Maven repository [1] to figure out what has
been published
Since I have been working a little with the Maven stuff, I'm comfortable
with option (b). This will remove one small task for the release
manager, so I'm giving it my +1.
Regards,
--
Kristian
[1] For instance http://repo1.maven.org/maven2/org/apache/derby/derby/
[ snip ]
Re: Recording published Maven 2 artifacts
Posted by Rick Hillegas <ri...@oracle.com>.
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<ri...@oracle.com> writes:
>>>>
>>>>> Knut Anders Hatlen wrote:
>>>>>> Rick Hillegas<ri...@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,
Re: Recording published Maven 2 artifacts
Posted by Kristian Waagan <kr...@oracle.com>.
On 19.10.10 14:52, Rick Hillegas wrote:
> Kristian Waagan wrote:
>> On 12.10.10 16:05, Knut Anders Hatlen wrote:
>>> Rick Hillegas<ri...@oracle.com> writes:
>>>
>>>> Knut Anders Hatlen wrote:
>>>>> Rick Hillegas<ri...@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!
>
>> 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?
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 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
Regards,
--
Kristian
>
> 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 10.5.3.0, all artifacts: Invalid POMs, use version 10.5.3.0_1
>> instead.
>>
>> ---
>>
>>
>
Re: Recording published Maven 2 artifacts
Posted by Rick Hillegas <ri...@oracle.com>.
Kristian Waagan wrote:
> On 12.10.10 16:05, Knut Anders Hatlen wrote:
>> Rick Hillegas<ri...@oracle.com> writes:
>>
>>> Knut Anders Hatlen wrote:
>>>> Rick Hillegas<ri...@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
> 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.
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 10.5.3.0, all artifacts: Invalid POMs, use version 10.5.3.0_1 instead.
>
> ---
>
>
Re: Recording published Maven 2 artifacts
Posted by Kristian Waagan <kr...@oracle.com>.
On 12.10.10 16:05, Knut Anders Hatlen wrote:
> Rick Hillegas<ri...@oracle.com> writes:
>
>> Knut Anders Hatlen wrote:
>>> Rick Hillegas<ri...@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
Can we simply add a header "Deprecated Maven Artifacts"?
---
[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 10.5.3.0, all artifacts: Invalid POMs, use version 10.5.3.0_1 instead.
---
--
Kristian
Re: Recording published Maven 2 artifacts
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@oracle.com> writes:
> Knut Anders Hatlen wrote:
>> Rick Hillegas <ri...@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.
--
Knut Anders
Re: Recording published Maven 2 artifacts
Posted by Rick Hillegas <ri...@oracle.com>.
Knut Anders Hatlen wrote:
> Rick Hillegas <ri...@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.
Thanks,
-Rick
Re: Recording published Maven 2 artifacts
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@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?
--
Knut Anders
Re: Recording published Maven 2 artifacts
Posted by Rick Hillegas <ri...@oracle.com>.
Hi Kristian,
I cast my vote for lightweight processes. Of these choices, option (c)
sounds best to me.
Even better and lighterweight would be to separate this log into its own
file. The maven script could automatically add an entry to the end of
this log every time a release is published. The release manager could go
back and edit the log in case something went wrong. But normally the
maintenance of this log would be handled by the script and the release
manager would have one less step to worry about, addressing Knut's
issue. I have started putting logic into the the ant build scripts to
automate some of these tasks which involve updating files in the repository.
I agree that most developers won't care about this file. It is
interesting archeology for release managers, though.
My $0.02,
-Rick
Kristian Waagan wrote:
> Hi,
>
> When I worked on the scripts generating and publishing the Maven 2
> artifacts, I added a release history to the maven2/README.txt file.
> This file exists on every branch.
> I did not think a lot about how this would work out as we publish new
> releases. Its only purpose is to serve as a record for artifacts
> released by the Derby community. I don't think Derby users will read
> it. Keeping it up to date on all branches seems like a drag. Here are
> some options, including the tedious one:
>
> a) Update trunk, merge to all branches.
> b) Update trunk, merge to release branch.
> Merging may not work here, so we may have to simply update the
> file directly on both trunk and the release branch.
> c) Update trunk only.
>
> I have chosen to always update trunk so that we have a place where we
> keep the full history.
>
> Any opinions on this?
> I'm leaning towards (c) for simplicity. I prefer to avoid (a).
>
>
> Regards,