Quick summary of puzzle pieces:
http://wiki.eclipse.org/IT_Infrastructure_Doc
- Basic info on working with the download server.
http://wiki.eclipse.org/Common_Build_Infrastructure/Publishing
- Some overlap with above with discussion of using an ant-based promote.xml
script that projects have to write and maintain.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=306854
- Request to create a push-button solution for getting builds from Hudson to the
download server and cleaning up old builds. Good to see this discussed, but so
far no visible progress and the bug is marked “helpwanted”. This seems
to me a fundamental infrastructure piece and something that should be owned by
the Foundation rather than left for the community.
So
far, we are still missing the piece of creating the download page for the build
and wiring that into the list of pages on the website. It looks like there are
a 101 ways that projects have found to do this. Is there anything resembling
best-practice? The approach used by the Modeling projects is the slickest that
I’ve seen. Is that re-usable by others? Needless to say, this is
something else that should be handled at the infrastructure level. Projects
could publish a metadata file describing their artifacts and the pages could be
synthesized by common infrastructure.
-
Konstantin
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin
Komissarchik
Sent: Tuesday, August 10, 2010 12:50 PM
To: 'Cross project issues'
Subject: RE: [cross-project-issues-dev] Need help publishing builds
Note that I am not looking for a
build system. There are many choices in this field and I already have a working
build, including a Hudson job. Now I need the part that will publish the build
once it is completed on Hudson. The next steps should not be dependent on the
build system that was used to produce the zips.
I need to go from this:
https://build.eclipse.org/hudson/job/fproj-2.0/64/
To something like this:
http://www.eclipse.org/gef/downloads/
- Konstantin
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Denis
Roy
Sent: Tuesday, August 10, 2010 12:36 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Need help publishing builds
On 08/10/2010 03:12 PM, Konstantin Komissarchik wrote:
Is there a document, wiki or anything similar that describes
what must be done for a project to publish builds? Let’s assume that the
project already has a build system and a Hudson job.
There is no need to re-invent the wheel. The Athena Common Build project
is here to help, as it is the build solution we recommend to our new
projects. You can start here:
http://wiki.eclipse.org/Athena_Common_Build
There's also an IT Infra doc which may be helpful. Of course, since there
are many moving parts to Eclipse.org, it makes for a long doc.
http://wiki.eclipse.org/IT_Infrastructure_Doc
Has there been anything written that explains this stuff in
detail? Let’s assume that the audience is Java developers with Ant or
Maven experience, but not necessarily skilled in *nix systems or php.
I’ve seen some references to “login to server x and setup a cron
job”, which is frankly not very helpful for project teams without a
dedicated releng person with admin background. Exact steps would be needed for
everyone else.
This is a barrier that Eclipse Foundation should work on
eliminating. There is no reason for every project to be doing this themselves
and partially re-inventing the wheel in the process.
Strangely, as someone who is skilled in *nix systems and php, but not in Ant or
Maven, my casual observation is that project teams tend to reinvent the wheel
when it comes to build. Some folks use Athena, others, Ant, Maven, Tycho,
Buckminster, PDE Build, b3, or countless combinations of those technologies.
Personally I find it difficult to author a document when I don't know the
starting point.
If I can help here in any way, please let me know. Investing this time
into improving Athena Common Build would be my preference.
Denis