Re: [higgins-dev] How To Create Automated Build Scripts: Questions

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

Hi Tom,

When we decided that we need automated builds on eclipse server we had
no idea how do that and one of the biggest problem was: how to produce
eclipse plugins from command line. Searching documentation on eclipse
community we found this:
http://www.eclipse.org/articles/Article-PDE-Automation/automation.html
It turned out that there is no other way to produce eclipse plugins
from command line then to use org.eclipse.releng.basebuilder project.
Next our step was to look out how to other eclipse projects doing
their builds and take that as an example. As a result we got what we
have now in org.eclipse.higgins.releng.auto.

If you read the article above this may help to understand what #4, #5
and #6 are all about.

On #2, we were planning to provide information on
available downloads in real time. I meant not to use direct links to
available components and builds on the downloads page. desc.xml was
designed to use by
http://www.eclipse.org/higgins/ver2/downloadsnew.php script to parse
folder content and get an information how to display each folder in
the higgins downloads area
(/home/data/httpd/download.eclipse.org/technology/higgins folder on
build.eclipse.org). Below are three rules used for desc.xml:
  a) If some folder does not contain desc.xml then its content doesn't
  displayed.
  b) If some folder is a root folder for some component it contains
  generic information about component and so, there is no sense to
  generate it.
  c) For folders with build results desc.xml contains information about
  this build and so, it is generated at build time using template from
  "runtime".

On #3, right now index.php is neither required buy build
process nor buy downloads and actually, is a rudiment from a projects
used as an example.

On #8, I can't say that I'm happy with current state either but we
have what we have. Some time ago we're trying to move away from using
basebuilder in our build scripts to make them more clear but we lost a
person who worked on this stuff and right now we have no resources to
continue.

-- 
Thanks,

Valery

Tuesday, April 24, 2007, 8:47:18 PM, you wrote:

> Actually, I guess these are questions and requests for more detail.
> I'm looking at the files in the org.eclipse.higgins.releng.auto
> project to try to decipher what I'd need to do to add a new
> component.  So far, my gut feel is that there is a lot of copying,
> cutting and pasting going on that will make even a small change very
> difficult to propagate.  Here are my questions so far:

> 1. What does the "dropSite" referenced in the
> org.eclipse.higgins.releng.auto correspond to in the "How To" instructions?

> I'm looking at some of the Context Provider directories ...

> In "DropSiteRootFiles":
> 2. What is the desc.xml file and why is it not generated at build
> time?  The <buildTime> element has a date from 2006.
> 3. Could index.php be shared among all automated builds?  I don't
> see anything specific to any CP in there.

> 4. What are maps and what belongs there for any given component?
> 5. What is runtime?  It looks like some of these files could be
> generated from a template with the project name, package name, or
> etc.  At any rate, I can't tell what they're used for or needed for.
> I see Eclipse runtime referenced once in the instructions, is that
> what this is for?  Regardless, I still don't know what that means either.
> 6. Same of #5 for "tests" w/ respect to a template.
> 7. Same as #6 for root context provider scripts.  Only
> descriptions, project names, packages, and build directories differ.
> I'd hate to think every component owner has to do a copy, cut and
> paste dance to start and then manually respond to build system changes separately.
> 8. As far as build automation, why are context providers, hbx,
> idas, and sts separated out?  If they all have basically the same
> structure, dropSiteRootFiles, maps, runtime, and base scripts it
> makes sense that they would just be components in the automated build.

> I think a lot more commonization and standardization should be done
> with the build system.  It should be relatively easy for a component
> owner to add a new component.  I'd think by editing a single file
> with project, package, description and build directories (though
> that could be derived from the other info).  Changes to the build
> system would then flow to the components by simply regenerating the scripts.

> Tom


> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev