Re: [wtp-incubator-dev] How to make an XSL incubator build

[David M Williams <david_williams@xxxxxxxxxx>]

Here's some extra info on our builds ... I may need
to update some of our "how to" documents so some of this 
is easier to find. Here's some references you might
want to book mark and browse. 


http://wiki.eclipse.org/Category:Eclipse_Web_Tools_Platform_Project

http://wiki.eclipse.org/WTP_Build_Process_and_Procedures

http://wiki.eclipse.org/WTP_Batch_Build

http://build.eclipse.org:7777/dashboard/tab/builds


Some other tips are "inline" below. 



> The project you need to check out for XSL builds is:
> 
> releng.incubator
> 
> This contains the xsl.map file that is used by the build system to
> generate the builds.
> 
> When you want to tag files for an I-Build, I do the following:
> 
> 1.  Make sure all of the xsl plugin source files are checked
out into 
> the workspace.
> 2.  Right click on the releng.incubator project.
> 3.  Select Team->Release
> 4.  Select the xsl.map file from the releng.incubator project.
> 5.  Select all entries in the xsl.map file.
> 6.  Next-> then Select the Tag drop down box and select the
first entry 
> which should be the current date.


One thing to note, you do also need the Eclipse Platform's
releng plugin installed in your dev. env. 
It needs to "match" what ever version of
Eclipse your using as your dev. env. and is available 
on the Eclipse download pages, and we include a link
to it in our download page's pre-reqs for committers list. 

I usually select the project(s) I want to release,
then right click and to the Team->Release. 
Then, just those projects will be selected in the
wizard then, assuming you've released once before. 

If you do select 'all' the entries in the map file,
be sure the check box is set so 
that only changed projects are tagged. "Releasing"
effects the version number (qualifier) which shouldn't 
change if the code hasn't changed. 

In addition to the "current date" default,
we in WTP always use, by convention, tags of the form
vYYYYMMDDHHMM 
in other words, adding the hour and minutes, AND,
by convention, we always use UTC time, since we are a 
pretty global group. 


> Next just follow the rest of the prompts.  I
typically enter a message 
> saying this is an integration build.

Our WTP convention is, when possible, to use a comment
that contains 
[bugnumber] bug abstract/summary
You can use more than one, or "the main"
one if the release fixes several bugs, 
Or ... as Dave implies, provide a summary of why you
are doing the release. 
If you use this convention, then in the CruiseControl
dashboard, you can easily see 
"modifications" and (for most projects)
just click on the bug number to go to the bug. 


> I haven't tried to run a full build locally, but would be interested
in 
> knowing as well, where those ant scripts are located, as I may need
to 
> setup some local builds for some testing purposes on eclipse builds
I'm 
> working on.

Start with 
http://wiki.eclipse.org/WTP_Batch_Build

Not sure if those instruction mention it, but the
"project" you'd use is "incubator-R0.5-I". 

> > Finally, what is the process for an I-build to become and S-build?

> David Williams typically makes this happen when
we are ready for a 
> milestone to go to the public.   He can describe this better
than I though.
> 

We can leave it up to me for now, to switch. There's really no difference
between the two, 
except the labels used. Is that satisfactory for now?
Or did you need something specific? 
Or ... are you asking something deeper about the difference
of "Integration (I) builds" and 
"Milestone (S) builds"? 
I'd be glad to have more releng help, if you want
to take over more responsibility for that, 
but will take some amount of "training"
so want to be sure I know what the plan is before 
jumping in to anything.