Daniel,
This is an important topic, and we can
spend some time on it on Thursday. We should discuss item 1. Items
2 and 3 are in process (there are bugzilla items for them.) For 4, in theory, we are tracking 3rd
party dependencies in the components wiki, we should discuss further to make
sure everyone understands the granularity required. All Eclipse projects are required to do
this.
Mike,
From your perspective, is there anything
preventing us from doing standard STS builds like we currently do IdAS builds
(other than entering a Bugzilla item to create the build scripts and screens)?
We are waiting on the IPzilla process
before we can proceed with putting LDAP into CVS and having standard builds.
Mary
-----Original Message-----
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Sanders
Sent: Tuesday, January 02, 2007
7:04 PM
To: higgins-dev@xxxxxxxxxxx
Subject: [higgins-dev] Agenda Item
for Thursday Call
I would like to propose an agenda
item for Thursday's call, if there is time.
The issue is builds for the various
Higgins components. I am concerned because I currently have no way to
reproduce what was done for the IIW demo. The jar files that were
deployed on our demo servers came from builds that were done on various
people's personal computers - using code that had not been checked in and for
which there was (and still is not) an "official" build.
I understand that when we are under
pressure and are putting together demos, this is often a necessary mode of
operation, but once everyone is satisfied that the demo is ready, I would like
to be able to get back to the source and all dependencies that were used for
the demo so that I can reproduce it and tweek it as needed. This is often
very difficult to do if the developers have moved on and checked in hundreds of
new fixes, features, etc. - or are busy refactoring everything. This has
not been a high priority item, but I think it should be. I would really,
really like to see this take on a higher priority and urgency.
Specifically, we need official builds (including source) for the following
components:
idas, ldap context provider, sts,
and the card generator (currently part of the sts).
In addition, we need to know how we
are going to handle this going forward. I would like to see us discuss
the following sub-issues with respect to builds:
1) Packaging of source along with
jar files - so the jar files can always easily be associated with the source
that was used to generate it. I would also like to recommend that we
create tags in the CVS repository for specific milestones and/or other
important events that we might want to preserve and get back to (such as demos).
BTW: If our repository were Subversion, this would be much easier, because we
could simply use a SVN version number.
2) A way to trigger a build at any
time. This is important when putting together a demo, because what I
really want to do is to ask a developer to check in their "fixes" and
then manually do an "official" build that we incorporate immediately
into the demo. That way we aren't as prone to forget to check stuff in
and save off an official build that corresponds to our demo before we move on
and start doing other features. -- We simply discipline ourselves to only use
official builds when putting together demos - but that is only possible if
it is easy to generate official builds multiple times a day on demand.
3) #2 implies that the builds need
a more granular naming scheme than date - it needs to include hour,
minute, and second as well - because we may do multiple builds in one day,
not just a single nightly build.
4) List of dependencies that were
used to do the build. I know we cannot redistribute these things
ourselves, but we ought to at least keep a list that is current - so we can
know exactly what versions of things were used to do the build.
In my mind, it is critical that we
get a robust "build management" system in place now - including
whatever standards we think people ought to follow. People are starting
to do things (demos, etc.) where reproducibility is going to be very
important. We want to do this before we lots going on and are attempting
to support it with a build system that grew up in a haphazard way without
careful thought and planning.