Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 345748 - Graphiti's nightly build overrides itself at the same url
Summary: Graphiti's nightly build overrides itself at the same url
Status: CLOSED FIXED
Alias: None
Product: Graphiti
Classification: Modeling
Component: Core (show other bugs)
Version: 0.8.0   Edit
Hardware: All All
: P4 normal (vote)
Target Milestone: 0.9.0   Edit
Assignee: Michael Wenz CLA
QA Contact:
URL:
Whiteboard: Juno M1 theme_release_train
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-13 11:37 EDT by Shenxue Zhou CLA
Modified: 2012-06-28 10:38 EDT (History)
2 users (show)

See Also:
michael.wenz: juno+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shenxue Zhou CLA 2011-05-13 11:37:11 EDT
It looks like Graphiti's build system overwrites the build at the same download URL nightly. This causes trouble when they are consumed by other projects. The webmaster’s position is that previously-published downloads should not be overwritten (messes with download server’s checksums).

More details can be found at http://www.eclipse.org/forums/index.php/t/209214/
Comment 1 Konstantin Komissarchik CLA 2011-05-13 13:15:59 EDT
There are two problems with the current approach to publishing nightly builds:

1. Adopters don't have a fixed URL to refer to a specific build.

2. The checksums reported for the downloads do not match the downloaded artifact. This is due to the fact that the download server caches checksums and does not expect published files to change after being published. The checksum mismatch can be a big problem for adopters as it gets in a way of proper operation of automatic download processes in build systems, etc.
Comment 2 Michael Wenz CLA 2011-05-16 04:31:08 EDT
I haven't seen such a webmaster's statement yet. Can you point me to that?

What I've seen so far is the position of other projects towards their nightly build. They state that there is no guarantee  on the timeline a nigthly build is available (can be overriden any time). That is also stated this way in the retention policy of Graphiti in the project portal metadata.

In general I think it is a bad idea to make one's build dependent on the nightly build of another project. Instead I would always try to point to some kind of published build.

We already offer a RC1 build in our milestones update site (http://download.eclipse.org/graphiti/updates/milestones) which you could use to solve the current issue. In future, I would like you to simply ask us (forum, bugzilla, mail) to make a milestone build you could consume beforehand.

Michael
Comment 3 Konstantin Komissarchik CLA 2011-05-16 13:08:09 EDT
> I haven't seen such a webmaster's statement yet. Can you point me to that?

Don't know if there is a better writeup (and webmaster is copied, so he can chime in), but this should give you some background:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=334323#c2

> What I've seen so far is the position of other projects towards their nightly
> build. They state that there is no guarantee  on the timeline a nigthly build
> is available (can be overriden any time). That is also stated this way in the
> retention policy of Graphiti in the project portal metadata.

Note that the issue is not how long nightly builds are available for (that's a separate discussion), but rather that the same download file name is overwritten nightly. This strategy clashes with download server's checksums service design.

> In general I think it is a bad idea to make one's build dependent on the
> nightly build of another project. Instead I would always try to point to 
> some kind of published build.

Right. Relying on nightly builds is not ideal. The problem if what to do when the last milestone build doesn't have a major bug fix that you need. Other projects address this by publishing weekly declared builds. 

> We already offer a RC1 build in our milestones update site

Update sites are great, but they aren't viable in all situations. We need an archived repo. The download page does not list RC1:

http://www.eclipse.org/graphiti/download.php
Comment 4 Michael Wenz CLA 2011-05-17 04:47:37 EDT
Ok, I understand that issue and will have a look into that nightly build ZIP download after Indigo is out.

To solve your issue for now you can use our ZIP download of RC1 (it's been made available together with the update site, but not yet linked on our downloads page since it's not yet public). Here's the link:
http://www.eclipse.org/downloads/download.php?file=/graphiti/archives/milestones/org.eclipse.graphiti.site_0.8.0RC1.201105161053.zip

Sorry, I forgot that you use the zipper download. As I said: just drop us a note in case you'll need a newer milestone version and we can create one for you.

Michael
Comment 5 Konstantin Komissarchik CLA 2011-05-17 13:07:23 EDT
Thanks for the RC1 zip URL. We were able to use it.
Comment 6 Michael Wenz CLA 2011-07-08 06:31:26 EDT
I changed the Graphiti nightly build so that it renames the created ZIP file to contain the current build-id and updated the download link in a way that it always uses the current version (done via PHP sript).

That should solve the issue regarding identical download locations for the ZIP file. Please let me know in case it doesn't solve your issue.

Michael
Comment 7 Michael Wenz CLA 2011-07-14 08:20:02 EDT
Marked as part of Juno
Comment 8 Michael Wenz CLA 2012-04-11 10:29:12 EDT
Bookkeeping: Set target release
Comment 9 Michael Wenz CLA 2012-06-28 10:38:35 EDT
Part of Graphiti 0.9.0 (Eclipse Juno)