You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2015/11/27 11:26:42 UTC
[ALL] Move DOAP files to unchanging URL?
Compress recently moved to Git, so the URL for its DOAP changed.
I originally suggested that all the Commons DOAPs could be stored in a
common SVN location, but that idea met with resistance as several
people felt it was better kept with the source code.
Since then, the release summary file [1] has been introduced.
It might be sensible to move the DOAPs there too?
That would allow the script to automatically extract the latest releases.
At present it assumes all the DOAPs are in SVN, which is no longer the case.
==
The disadvantage of storing DOAPs in the source tree is that the DOAP
is not intended for release, and so is not included in the archives.
However it is included in tags and branches by default. This causes a
discrepancy when comparing the tag with the source archive. Also if
there are branches, care must be taken to ensure that the correct DOAP
is maintained (it's not unknown for a branch to take over from trunk -
or indeed for both to be used for releases).
[1] http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Move DOAP files to unchanging URL?
Posted by Gary Gregory <ga...@gmail.com>.
Sounds reasonable to me.
Gary
On Nov 27, 2015 2:26 AM, "sebb" <se...@gmail.com> wrote:
> Compress recently moved to Git, so the URL for its DOAP changed.
>
> I originally suggested that all the Commons DOAPs could be stored in a
> common SVN location, but that idea met with resistance as several
> people felt it was better kept with the source code.
>
> Since then, the release summary file [1] has been introduced.
>
> It might be sensible to move the DOAPs there too?
> That would allow the script to automatically extract the latest releases.
> At present it assumes all the DOAPs are in SVN, which is no longer the
> case.
>
> ==
>
> The disadvantage of storing DOAPs in the source tree is that the DOAP
> is not intended for release, and so is not included in the archives.
> However it is included in tags and branches by default. This causes a
> discrepancy when comparing the tag with the source archive. Also if
> there are branches, care must be taken to ensure that the correct DOAP
> is maintained (it's not unknown for a branch to take over from trunk -
> or indeed for both to be used for releases).
>
> [1]
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [ALL] Move DOAP files to unchanging URL?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 11/12/2015 09:05, Gary Gregory a écrit :
> Thanks Sebb!
+1
Now if the DOAP files could be updated automatically based on the
release tags or the Maven Central artifacts that would be one less thing
to do when publishing a release.
Emmanuel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Move DOAP files to unchanging URL?
Posted by Gary Gregory <ga...@gmail.com>.
Thanks Sebb!
Gary
On Thu, Dec 10, 2015 at 3:24 AM, sebb <se...@gmail.com> wrote:
> I have now moved the files to
>
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/doap/
>
> and updated the script that processes them [1] accordingly and
> recreated the properties [2] file.
>
> There may still be some DOAP files lying around in branches; I will
> try to remove these gradually, merging any relevant content.
> Obviously any DOAP files in tags will have to remain.
>
> [1]
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/parse-latest-release.py
> [2]
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
>
>
> On 27 November 2015 at 20:12, Phil Steitz <ph...@gmail.com> wrote:
> > On 11/27/15 3:26 AM, sebb wrote:
> >> Compress recently moved to Git, so the URL for its DOAP changed.
> >>
> >> I originally suggested that all the Commons DOAPs could be stored in a
> >> common SVN location, but that idea met with resistance as several
> >> people felt it was better kept with the source code.
> >>
> >> Since then, the release summary file [1] has been introduced.
> >
> > That file is just used to generate the data in the latest version /
> > release date columns on the main commons page, right? I would be +1
> > for dropping that file and those columns. The components are all
> > linked and you can get release info from the component pages. Just
> > one less thing to worry about when cutting releases. IIUC what you
> > say below, this may be moot though.
> >>
> >> It might be sensible to move the DOAPs there too?
> >> That would allow the script to automatically extract the latest
> releases.
> >> At present it assumes all the DOAPs are in SVN, which is no longer the
> case.
> >>
> >> ==
> >>
> >> The disadvantage of storing DOAPs in the source tree is that the DOAP
> >> is not intended for release, and so is not included in the archives.
> >> However it is included in tags and branches by default. This causes a
> >> discrepancy when comparing the tag with the source archive. Also if
> >> there are branches, care must be taken to ensure that the correct DOAP
> >> is maintained (it's not unknown for a branch to take over from trunk -
> >> or indeed for both to be used for releases).
> >
> > Makes sense to me. So +1 to "rope-the-doaps" somewhere :) Would be
> > great if the reporter thingy or something else could be used to
> > auto-update them on release. That would make *2* less things to do
> > for RMs. Yay!
> >
> > Phil
> >>
> >> [1]
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Move DOAP files to unchanging URL?
Posted by sebb <se...@gmail.com>.
I have now moved the files to
http://svn.apache.org/repos/asf/commons/cms-site/trunk/doap/
and updated the script that processes them [1] accordingly and
recreated the properties [2] file.
There may still be some DOAP files lying around in branches; I will
try to remove these gradually, merging any relevant content.
Obviously any DOAP files in tags will have to remain.
[1] http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/parse-latest-release.py
[2] http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
On 27 November 2015 at 20:12, Phil Steitz <ph...@gmail.com> wrote:
> On 11/27/15 3:26 AM, sebb wrote:
>> Compress recently moved to Git, so the URL for its DOAP changed.
>>
>> I originally suggested that all the Commons DOAPs could be stored in a
>> common SVN location, but that idea met with resistance as several
>> people felt it was better kept with the source code.
>>
>> Since then, the release summary file [1] has been introduced.
>
> That file is just used to generate the data in the latest version /
> release date columns on the main commons page, right? I would be +1
> for dropping that file and those columns. The components are all
> linked and you can get release info from the component pages. Just
> one less thing to worry about when cutting releases. IIUC what you
> say below, this may be moot though.
>>
>> It might be sensible to move the DOAPs there too?
>> That would allow the script to automatically extract the latest releases.
>> At present it assumes all the DOAPs are in SVN, which is no longer the case.
>>
>> ==
>>
>> The disadvantage of storing DOAPs in the source tree is that the DOAP
>> is not intended for release, and so is not included in the archives.
>> However it is included in tags and branches by default. This causes a
>> discrepancy when comparing the tag with the source archive. Also if
>> there are branches, care must be taken to ensure that the correct DOAP
>> is maintained (it's not unknown for a branch to take over from trunk -
>> or indeed for both to be used for releases).
>
> Makes sense to me. So +1 to "rope-the-doaps" somewhere :) Would be
> great if the reporter thingy or something else could be used to
> auto-update them on release. That would make *2* less things to do
> for RMs. Yay!
>
> Phil
>>
>> [1] http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Move DOAP files to unchanging URL?
Posted by Phil Steitz <ph...@gmail.com>.
On 11/27/15 3:26 AM, sebb wrote:
> Compress recently moved to Git, so the URL for its DOAP changed.
>
> I originally suggested that all the Commons DOAPs could be stored in a
> common SVN location, but that idea met with resistance as several
> people felt it was better kept with the source code.
>
> Since then, the release summary file [1] has been introduced.
That file is just used to generate the data in the latest version /
release date columns on the main commons page, right? I would be +1
for dropping that file and those columns. The components are all
linked and you can get release info from the component pages. Just
one less thing to worry about when cutting releases. IIUC what you
say below, this may be moot though.
>
> It might be sensible to move the DOAPs there too?
> That would allow the script to automatically extract the latest releases.
> At present it assumes all the DOAPs are in SVN, which is no longer the case.
>
> ==
>
> The disadvantage of storing DOAPs in the source tree is that the DOAP
> is not intended for release, and so is not included in the archives.
> However it is included in tags and branches by default. This causes a
> discrepancy when comparing the tag with the source archive. Also if
> there are branches, care must be taken to ensure that the correct DOAP
> is maintained (it's not unknown for a branch to take over from trunk -
> or indeed for both to be used for releases).
Makes sense to me. So +1 to "rope-the-doaps" somewhere :) Would be
great if the reporter thingy or something else could be used to
auto-update them on release. That would make *2* less things to do
for RMs. Yay!
Phil
>
> [1] http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Move DOAP files to unchanging URL?
Posted by Benedikt Ritter <br...@apache.org>.
Hello Sebb,
2015-11-27 11:26 GMT+01:00 sebb <se...@gmail.com>:
> Compress recently moved to Git, so the URL for its DOAP changed.
>
> I originally suggested that all the Commons DOAPs could be stored in a
> common SVN location, but that idea met with resistance as several
> people felt it was better kept with the source code.
>
> Since then, the release summary file [1] has been introduced.
>
> It might be sensible to move the DOAPs there too?
> That would allow the script to automatically extract the latest releases.
> At present it assumes all the DOAPs are in SVN, which is no longer the
> case.
>
> ==
>
> The disadvantage of storing DOAPs in the source tree is that the DOAP
> is not intended for release, and so is not included in the archives.
> However it is included in tags and branches by default. This causes a
> discrepancy when comparing the tag with the source archive. Also if
> there are branches, care must be taken to ensure that the correct DOAP
> is maintained (it's not unknown for a branch to take over from trunk -
> or indeed for both to be used for releases).
>
I'm okay with either way. But it should be the same for all components. I
don't expect the URL to the DOAP to chance frequently so I don't see that
much of a problem when keeping it together with the code.
>
> [1]
> http://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter