You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2013/08/28 22:23:18 UTC
improving eclipse update (sub) site builds
The current design checks out the current sub-site into a subdir of "target",
runs the build using that data (which represents the existing features and
plugins, including any previous "versions"), and then allows committing (just)
the changes back to the current sub-site.
A modification (for safety) has been to use the dist.apache.org's "dev" tree,
rather than the "release" tree, and require some kind of intentional "manual"
operation to release the update site.
This is currently done as follows (under the -Papache-release profile):
1) svn delete the update subsite on the dist.apache.org ... dev.
2) svn copy the update subsite from the ...release... to the ...dev...
(this is because svn copy won't copy over existing dirs).
I think the following would work better:
1) check out the subsite from the ...dev... side.
2) svn merge the subsite from the ...release... side. This makes it up-to-date
with the release side. At this point the working copy is equivalent to the
release side.
With this approach, there's no need to do 2 svn change operations on
dist.apache.org repository (the delete, and the copy).
Any objections to changing the parent pom to work this way, or better suggestions?
-Marshall
Re: improving eclipse update (sub) site builds
Posted by Marshall Schor <ms...@schor.com>.
At the risk of being annoying by stating what you probably know, we're not
hosting these things in SVN --
We're posting (not hosting - sorry, couldn't resist) to the Apache main website
distribution point, and to the array of 3rd party "mirrors" of the this.
It just turns out that Apache infra, for reasons that I'm not really aware,
decided this was a good, controlled way to do this kind of posting.
Not only the Eclipse update site goes there, but anything that wants to make use
of the Apache Mirror system. The big artifacts that get posted there are the
binary "convenience builds" zip's and tar.gz's.
I, too, get a bad feeling about (mis) using SVN in this way. I would welcome
more clarity on the tradeoffs infra weighed in picking this method of posting,
-Marshall
On 8/28/2013 5:30 PM, Richard Eckart de Castilho wrote:
> Hosting update sites or Maven repositories in SVN gives me shivers. Isn't there some decent repository solution for Eclipse update site, like there is Nexus, Archiva, or whatnot for Maven? At some point there had been plans to add P2 support to Nexus - no idea if that happened and if it really works. Unfortunately, there comments here [1] are not very promising :(
>
> Otherwise, please ignore my comment. It's not helping the discussion, just expressing amazement and frustration.
>
> -- Richard
>
> [1] https://docs.sonatype.org/display/Nexus/Nexus+OSGi+Experimental+Features+-+P2+Repository+Plugin
>
> Am 28.08.2013 um 23:16 schrieb Marshall Schor <ms...@schor.com>:
>
>> A problem with the "merge" method:
>>
>> Consider:
>>
>> you check out the ...dev...
>>
>> suppose that dev has changesets with more recent revisions than release.
>>
>> Then, merging in the release won't update those.
>>
>> So, if anyone committed some change to the dev list, that would remain, even
>> after the merge.
>>
>> -----------
>> The following seems to me to work:
>>
>> 1) svn checkout the subsite from release
>> 2) svn switch to the dev.
>>
>> This is just a safety measure - to prevent accidental commits to release.
>> At this point files might appear as new additions, or as having incoming updates
>> (if the above scenario held), etc.). But we won't intentially be doing anything
>> with this branch (no commits...)
>> ....
>> run builds, etc. (this adds / modifies the subsite in the local working copy)
>> do any release voting, and after approval,
>>
>> 4) svn switch back to the release branch, and commit any changes.
>>
>> WDYT? -Marshall
>>
>> On 8/28/2013 4:23 PM, Marshall Schor wrote:
>>> The current design checks out the current sub-site into a subdir of "target",
>>> runs the build using that data (which represents the existing features and
>>> plugins, including any previous "versions"), and then allows committing (just)
>>> the changes back to the current sub-site.
>>>
>>> A modification (for safety) has been to use the dist.apache.org's "dev" tree,
>>> rather than the "release" tree, and require some kind of intentional "manual"
>>> operation to release the update site.
>>>
>>> This is currently done as follows (under the -Papache-release profile):
>>>
>>> 1) svn delete the update subsite on the dist.apache.org ... dev.
>>> 2) svn copy the update subsite from the ...release... to the ...dev...
>>>
>>> (this is because svn copy won't copy over existing dirs).
>>>
>>> I think the following would work better:
>>>
>>> 1) check out the subsite from the ...dev... side.
>>> 2) svn merge the subsite from the ...release... side. This makes it up-to-date
>>> with the release side. At this point the working copy is equivalent to the
>>> release side.
>>>
>>> With this approach, there's no need to do 2 svn change operations on
>>> dist.apache.org repository (the delete, and the copy).
>>>
>>> Any objections to changing the parent pom to work this way, or better suggestions?
>>>
>>> -Marshall
Re: improving eclipse update (sub) site builds
Posted by Richard Eckart de Castilho <ri...@gmail.com>.
Hosting update sites or Maven repositories in SVN gives me shivers. Isn't there some decent repository solution for Eclipse update site, like there is Nexus, Archiva, or whatnot for Maven? At some point there had been plans to add P2 support to Nexus - no idea if that happened and if it really works. Unfortunately, there comments here [1] are not very promising :(
Otherwise, please ignore my comment. It's not helping the discussion, just expressing amazement and frustration.
-- Richard
[1] https://docs.sonatype.org/display/Nexus/Nexus+OSGi+Experimental+Features+-+P2+Repository+Plugin
Am 28.08.2013 um 23:16 schrieb Marshall Schor <ms...@schor.com>:
> A problem with the "merge" method:
>
> Consider:
>
> you check out the ...dev...
>
> suppose that dev has changesets with more recent revisions than release.
>
> Then, merging in the release won't update those.
>
> So, if anyone committed some change to the dev list, that would remain, even
> after the merge.
>
> -----------
> The following seems to me to work:
>
> 1) svn checkout the subsite from release
> 2) svn switch to the dev.
>
> This is just a safety measure - to prevent accidental commits to release.
> At this point files might appear as new additions, or as having incoming updates
> (if the above scenario held), etc.). But we won't intentially be doing anything
> with this branch (no commits...)
> ....
> run builds, etc. (this adds / modifies the subsite in the local working copy)
> do any release voting, and after approval,
>
> 4) svn switch back to the release branch, and commit any changes.
>
> WDYT? -Marshall
>
> On 8/28/2013 4:23 PM, Marshall Schor wrote:
>> The current design checks out the current sub-site into a subdir of "target",
>> runs the build using that data (which represents the existing features and
>> plugins, including any previous "versions"), and then allows committing (just)
>> the changes back to the current sub-site.
>>
>> A modification (for safety) has been to use the dist.apache.org's "dev" tree,
>> rather than the "release" tree, and require some kind of intentional "manual"
>> operation to release the update site.
>>
>> This is currently done as follows (under the -Papache-release profile):
>>
>> 1) svn delete the update subsite on the dist.apache.org ... dev.
>> 2) svn copy the update subsite from the ...release... to the ...dev...
>>
>> (this is because svn copy won't copy over existing dirs).
>>
>> I think the following would work better:
>>
>> 1) check out the subsite from the ...dev... side.
>> 2) svn merge the subsite from the ...release... side. This makes it up-to-date
>> with the release side. At this point the working copy is equivalent to the
>> release side.
>>
>> With this approach, there's no need to do 2 svn change operations on
>> dist.apache.org repository (the delete, and the copy).
>>
>> Any objections to changing the parent pom to work this way, or better suggestions?
>>
>> -Marshall
Re: improving eclipse update (sub) site builds
Posted by Marshall Schor <ms...@schor.com>.
A problem with the "merge" method:
Consider:
you check out the ...dev...
suppose that dev has changesets with more recent revisions than release.
Then, merging in the release won't update those.
So, if anyone committed some change to the dev list, that would remain, even
after the merge.
-----------
The following seems to me to work:
1) svn checkout the subsite from release
2) svn switch to the dev.
This is just a safety measure - to prevent accidental commits to release.
At this point files might appear as new additions, or as having incoming updates
(if the above scenario held), etc.). But we won't intentially be doing anything
with this branch (no commits...)
....
run builds, etc. (this adds / modifies the subsite in the local working copy)
do any release voting, and after approval,
4) svn switch back to the release branch, and commit any changes.
WDYT? -Marshall
On 8/28/2013 4:23 PM, Marshall Schor wrote:
> The current design checks out the current sub-site into a subdir of "target",
> runs the build using that data (which represents the existing features and
> plugins, including any previous "versions"), and then allows committing (just)
> the changes back to the current sub-site.
>
> A modification (for safety) has been to use the dist.apache.org's "dev" tree,
> rather than the "release" tree, and require some kind of intentional "manual"
> operation to release the update site.
>
> This is currently done as follows (under the -Papache-release profile):
>
> 1) svn delete the update subsite on the dist.apache.org ... dev.
> 2) svn copy the update subsite from the ...release... to the ...dev...
>
> (this is because svn copy won't copy over existing dirs).
>
> I think the following would work better:
>
> 1) check out the subsite from the ...dev... side.
> 2) svn merge the subsite from the ...release... side. This makes it up-to-date
> with the release side. At this point the working copy is equivalent to the
> release side.
>
> With this approach, there's no need to do 2 svn change operations on
> dist.apache.org repository (the delete, and the copy).
>
> Any objections to changing the parent pom to work this way, or better suggestions?
>
> -Marshall
>
Re: improving eclipse update (sub) site builds
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Am 28.08.2013 22:23, schrieb Marshall Schor:
> The current design checks out the current sub-site into a subdir of "target",
> runs the build using that data (which represents the existing features and
> plugins, including any previous "versions"), and then allows committing (just)
> the changes back to the current sub-site.
>
> A modification (for safety) has been to use the dist.apache.org's "dev" tree,
> rather than the "release" tree, and require some kind of intentional "manual"
> operation to release the update site.
>
> This is currently done as follows (under the -Papache-release profile):
>
> 1) svn delete the update subsite on the dist.apache.org ... dev.
> 2) svn copy the update subsite from the ...release... to the ...dev...
>
> (this is because svn copy won't copy over existing dirs).
>
> I think the following would work better:
>
> 1) check out the subsite from the ...dev... side.
> 2) svn merge the subsite from the ...release... side. This makes it up-to-date
> with the release side. At this point the working copy is equivalent to the
> release side.
>
> With this approach, there's no need to do 2 svn change operations on
> dist.apache.org repository (the delete, and the copy).
>
> Any objections to changing the parent pom to work this way, or better suggestions?
+1 sounds good
Peter
> -Marshall
>