[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[dtp-pmc] RE: DTP::Builds [Was: ODA plugin]
|
I think that Der Ping's comment in a parallel email to this thread about
showing progress with exemplary code answers the concerns that I had. Just
to clarify, I was not talking about the API but rather the overall
architecture of DTP in my comments. Also, Larry observed that a link to
road map and other documents would help in clarifying the current status. I
agree, and think that we should continue with the build as suggested by Der
Ping and Larry.
Moving the discussion to a higher level than just this build, I'd like to
point out a topic that's I feel I'll be coming back to from time to time.
Sure, there are lots of things we _can_ do, so my questions are to what
helps an open source project be a successful open source project at
eclipse.org. Leveraging the experience of others, in this case WTP and
BIRT, I submit is an important part of meeting that aim. So, I'd like to
thank everyone who has contributed to this thread, and I hope that we can
continue to share ideas like this going forward.
Regards,
John Graham
"Linda Chan"
<LChan@xxxxxxxxxx
m> To
"Der Ping Chou"
08/26/2005 03:05 <dpchou@xxxxxxxxxx>, "Lawrence E
PM Dunnell" <ledunnel@xxxxxxxxxx>
cc
<dtp-pmc@xxxxxxxxxxx>,
<jograham@xxxxxxxxxx>
Subject
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
-----Original Message-----
From: Der Ping Chou [mailto:dpchou@xxxxxxxxxx]
Sent: Friday, August 26, 2005 11:41 AM
To: Lawrence E Dunnell
Cc: dtp-pmc@xxxxxxxxxxx; jograham@xxxxxxxxxx; Linda Chan
Subject: Re: DTP::Builds [Was: ODA plugin]
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:
(Embedded image moved to file: pic09758.gif)
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
To
08/26/2005 11:01 AM 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@syb
ase.com
To
08/26/2005 "Linda Chan" <LChan@xxxxxxxxxxx>, Der
07:57 AM 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)
Attachment:
pic09758.gif
Description: GIF image