[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dtp-pmc] RE: DTP::Builds [Was: ODA plugin]
|
Der Ping, Thanks for verifying that the Ant build script,
provided in the ODA source tree, does indeed build fine as is; and that
adjusting your workspace settings work as
well.
Re: an
"unified build system" for DTP, I agree with Larry and Der Ping that we should
move towards that.
Re: the separate concern for
"accusations that we "keep changing things.""... it should not be an issue. It is quite common and well understood
that until an open source project has declared a final build, any interim source or download builds are subject to
change.
Furthermore, speaking for the ODA public interfaces, the package
description clearly states that the API is "provisional". I believe this is a recommended practice to indicate that the public
APIs could still change without backward compatibility support. BTW, we do plan to provide backward
compatibility to the ODA public API defined in BIRT 1.0.
Linda
John and
Larry,
First of all Linda helped
me last night to make sure ODA build with script, I also adjusted my IDE to
ensure they agree, we are OK in that regard. (Linda user from EclipseWorld
will not see the build error now)
I agree with you and Larry's proposal. Further more, since we have
everything built (modelbase, connectivity subproject), we probably
should go directly toward the 'unified build system' using what Larry
published and we could consider building more than modelbase subproject
in the build. We are not trading off stability of the build, but exposing a
lots of exemplary code to demonstrate our progress.
Larry was suggesting that we can have a staging build
area/system to help team transition into 'unified build system'.
We should be able to establish the
'unified build system' with following two subproject (modelbase and
connectivity) and plugins:
Der-Ping Chou
Information Management Tooling
Development Manager
- Data Tools
Seattle IBM Office
tel : 1-206-587-5946 (T/L:
277-5946)
| Lawrence E
Dunnell/Redmond/IBM
08/26/2005 11:01 AM
|
|
To
| jograham@xxxxxxxxxx
|
|
cc
| Der Ping
Chou/Redmond/IBM@IBMUS, dtp-pmc@xxxxxxxxxxx, "Linda Chan"
<LChan@xxxxxxxxxxx>
|
|
Subject
| Re: DTP::Builds [Was:
ODA plugin]Link |
|
John,
Are
you suggesting that each project provide build scripts as an interim solution
or a long term solution? In the long term I think we will need a unified
build system.
As far as build
systems I would suggest using the Eclipse build system which is hosted in the
releng.builder plug-in. The build person will be able to get a lot of
support from the Eclipse community if we use it. This system allows each
subproject to be responsible for its build artifacts (mostly a collection of
xml files) while still providing a "master" build script. It also
supports junit tests and existing tools for displaying the results in web
pages. If you look around the WTP project downloads website you can see
various build logs and other artifacts generated by the build system.
There is some information about it here:
http://www.eclipse.org/articles/Article-PDE-Automation/automation.html
Larry Dunnell
RAD Data Tools and DB2
Tooling
IBM DB2 Information Management Software
Notes address:
Lawrence E Dunnell/Redmond/IBM@IBMUS
Internet address:
ledunnel@xxxxxxxxxx
tel: 206 587 5957
tie line: 277
5957
| jograham@xxxxxxxxxx
08/26/2005 07:57 AM
|
|
To
| "Linda Chan"
<LChan@xxxxxxxxxxx>, Der Ping Chou/Redmond/IBM@IBMUS,
Lawrence E Dunnell/Redmond/IBM@IBMUS
|
|
cc
| dtp-pmc@xxxxxxxxxxx
|
|
Subject
| DTP::Builds [Was: ODA
plugin] |
|
All,
Sorry to be late getting back into this thread. I'd
like to make a couple
of observations here and ask for feedback from the
group and the PMC:
1. I have concerns about creating a simple DTP build
at this point.
Currently we have a number of (essentially) final models in
CVS, a bunch of
"sample" code, and some that is in transition. By "sample
code" I mean the
non-model ports from WTP/rdb. By "in transition" I mean
ODA at this point
and (some time really soon), the initial connectivity
components from Rob.
These "in transition" components will need to be
integrated with the other
DTP components and the samples will be
replaced/augmented by DTP components
later. Based on our previous
discussions, my belief is that everyone here
(and in DTP) understands and
agrees to this (if not, then this would be a
really good time to speak up.
:-) ). My concern is that people picking up
the build will not
understand these distinctions, even if we go to pains to
document them in
the downloads/build pages. I think it would be a
substantial disaster to
introduce such confusion into the community, and
that we'd spend a lot of
time going forward sorting this out and responding
to accusations that we
"keep changing things." Given these considerations,
I'd like to suggest
three possibilities:
a. We do a build of Model Base
only
b. We do separate builds: Model Base and the rest. The
download for
"the rest" is clearly explained to be samples/in
transition.
c. We build Model Base only and provide
instructions on how to build
the rest. The instructions make clear the
sample/transitional nature of the
components
I would prefer (a) as
my first choice, then (c) and finally (b). Of course,
this does not
preclude others (e.g. BIRT) from building directly from
DTP:CVS for their
own purposes. Once we get the code in a more unified
state, then we can add
more to the "DTP build." What this "more unified
state" is would be
determined by the PMC in conjunction with the DTP
committers.
2.
Actually doing the builds: For the time being, I think we should put
builds
up manually as needs arise. For example, Der Ping and I have a talk
next
week about DTP, and it would be nice to have a Model Base build
available.
WTP wants to look at the connectivity frameworks, so I'd like to
have a
"build" (maybe not fully functional) of that as soon as Rob gets
the
initial code checked in. These builds could be done against a known
base
set ("driver", such as Eclipse version, etc.) by individuals and
then
posted on the site by me. Next, we'll move to automated builds/posting
as
we get more components together. Ultimately, we'd have unit tests run,
and
nice pictures (like the platform does) to show build status. Sybase
has
agreed to host the build machine itself. I'd like to suggest that
each
project be responsible for creating a build script that works
within
certain parameters (not yet determined), and then I'll make sure
that the
build machine automates running of those scripts. BTW, BIRT -- is
there
some way we can generate interesting build reports for positing on
the
site?
Thoughts?
Regards,
John Graham
Staff Software
Engineer
Sybase, Inc.
telephone: (978) 287-1634 (GMT -
5)
e-mail: john.graham@xxxxxxxxxx
"Linda Chan"
<LChan@xxxxxxxxxx
m>
To
"Der Ping Chou" <dpchou@xxxxxxxxxx>
08/25/2005 08:47
cc
PM
<jograham@xxxxxxxxxx>,
"Lawrence E
Dunnell" <ledunnel@xxxxxxxxxx>
Subject
RE: ODA plugin
Hi Der Ping,
The compiler warning on assert seems
to be related to the javac option
using a version older than 1.4 .
Did
you use the Ant build script that comes with the ODA plugin source
tree?
It's called "build.xml" which references the "build.properties"
file.
It explicitly specifies version 1.4 for javac.
If so, perhaps there
are other build environment options that should be set
as well.
Please feel free to give me a call, so we can walk thru them.
And yes,
I fully agree that we need a build system in place for all the
DTP
components. In fact, John and I have discussed that briefly...
we need
volunteers to take this on
;-)
Linda
office: 1-650-837-2217
-----Original Message-----
From: Der Ping Chou
[mailto:dpchou@xxxxxxxxxx]
Sent: Thursday, August 25,
2005 5:33 PM
To: Linda Chan
Cc:
jograham@xxxxxxxxxx; Lawrence E Dunnell
Subject: ODA
plugin
Linda,
Since
we don't have a build system in place for DTP yet. (I think it
is something that we need to include in our milestone 1)
While
preparing course material for DTP in
EclipseWorld, I was not able to
build some helper
classes (for example, odaDriver.java file - assert
method is not defined) in
org.eclipse.datatools.connectivity.oda
plugin. Could
you let me know what is the required build environment
for oda?
Thanks,
Der-Ping Chou
Information Management
Tooling
Development Manager - Data Tools
Seattle IBM Office
tel : 1-206-587-5946
(T/L: 277-5946)
