| [higgins-dev] Notes from July 12 Higgins developers call |
|
Notes from the July 12th
Higgins developers call. These note are a
little rougher than usual. I if didn’t get your name or something else
right, please let me know. Attendees ========= Alex Amies - IBM *Paula Austel - IBM *Jeff Broberg CA *Andy Hodgkinson - Novell *Duane Buss - Novell *Greg Byrd - NCSU/IBM *Brian Carrol - Serena *Tom Doman - Novell *Valery Kokhan - Parity *David Kuehr-Mclaren - IBM *Mike McIntosh - IBM Nataraj Nagaratnam - IBM Dale Olds - Novell Uppili Srinivasan - Oracle *Drummond Reed - Cordance *Mary Ruddy - Parity/SocialPhysics *Markus Sabedello *Jim Sermersheim - Novell *George Stanchev - Serena *Daniel Sanders Abhi Schelat - IBM Paul Trevithick - Parity/SocialPhysics -- * Present Regrets ======= Paul Trevithick - Parity/SocialPhysics Tony Nadalin - IBM Agenda ------ Starter Agenda • Enabling other developers to use Higgins ** Our builds ** Making it easy for other developers to build • IdAS Registry (if Jim is on the call) • Post Catalyst Interop: refactoring H1, H2 and H3 for more
consistency, next steps for interop • Other? Milestone 0.9 0) MikeM is going on vacation for the next two weeks, starting after
this meeting. 1) Enabling other developers to use Higgins Mary: Getting our build process running smoothly has been a challenge, especially
because we need to support multiple targets. Due to events this week, this is
now very high priority. Not only getting our nightly build process established
for all components, but also making it easier for persons outside the project
to build and use Higgins. Mike, you created a token service build this week. Please
tell us about what you have been doing. Mike: I had to create a war file and was having a hard time. Each
person maintaining a subproject does it with their dominant scenario in mind. There
are lots of inconsistencies. Some were changed to build plug-ins as a default,
some not. Things were changing under me. Didn't have a consistent set of
dependencies. I ended up creating a branch so that they were buildable. I took
a branch of m 0.8 and created an m 0.8 TS and was then able to build on top of
that. It has gotten to be very hard. Different component owners have different
dominant scenarios that are of primary focus. Need to keep things easily
buildable for others consuming it. Mike: Also we need to talk about how difficult it is to make a war file
that you can deploy. Most developers want to create one that contains all of
the dependent jars. That means that they want to build-in jars that they can't
redistribute. So he needed to create a separate war target that didn't have the
non-redistributable jars. Mike: Need to split dependencies into those that can and can't be
redistributed. It very cumbersome to have the same jar files in lots of components. Mike: In summary, as discussed last week, I recommend we have two
categories of dependencies. As the status changes a jar can be moved from the
can’t distribute list to the OK to distribute list. Brain: As someone who is also building the STS. I second everything. Daniel: I’m also building. I have my own ant script and like this
too Jeff: Have a need to build in a clean environment. I’m willing to
be a guinea pig. My goal is a war file to deploy on tomcat. Am willing to track
the changes. Am willing to do this for this group. Mary: Thank you for volunteering. ???: If we could have a tarball that included source, then that would
meet a lot of needs. 99 % of developers aren't interested in downloading from
CVS so many pieces.... even if you have a cookbook... ???: We should post something that is a week behind current development
that would build with ant and not need Eclipse. Jeff: Can these things be done in an order? build from scratch, then ??? We
should start with tarball ???: 1 binaries, 2 tarball, then really detailed stuff Drummond: So you have the basic, the more detailed, then a package for
those really getting in deep ??? Most people who go to an open source project want binaries. Jeff : Yes for XML. But he
also wants level 2 Daniel: Agree. The first level is binaries, then the tarball for those going
deeper, then build from scratch for those really going in deep or who are
Higgins developers. Jeff: 3rd is most important. Daniel?: Adoption will come with the first two most easily. Can submit
patches with a source tarball. ???: Regarding the source tar bar –is better if have build XML... Jeff: Need to focus on pushing to get the ability to download third
party binaries. Mary: I will review the status of the open CQ’s and make a push. This
is crucial for our success. Jeff: I want to get IDP up and running in a war Jim: I'm done that for Wagg. He has a build XML. He has posted a war
file on the bandit site. He also
has a tarball. Jeff: Will try and post questions to the list. Jeff: Also want to put the build environment in net beans. Brian: ALF also wants to build from the source. Jeff: We should put instructions on the Higgins wiki: “start here.” Mary: Yes, there needs to be instructions for building each deployment
from scratch. Jim: I agree with what Daniel
says. It is more likely that people will want binaries first, then the source
tarball, and then to build from scratch. To be successful, need to do one and
two on a regular, reproducible schedule so that we can get things done. The first
step is that we need to be able to build. It would be nice if all the
components had had the same build experience... Mary: Quality and consistency Daniel?: Our first goal is to get binaries. He hopes progress towards
this goals will make it easier to do 3. Mary: There is demand for documentation of how to build deployments. We
need to start by iterating on the format for the first one (IdP). Brian: Whoever sets up a page on how to page for how to build a
deployment. Brian will contribute that. Jeff: Will do this. We can provide feedback. Brian: Having pulled dependent jars multiple times. He thinks this is great. Mary: We do have a list of dependencies that have been sent to Eclipse
legal and their status. It is http://wiki.eclipse.org/Higgins_Third_Party_Dependencies.
It is sorted alphabetically with a status. Brian: For each component, we need to know minimum list of third party
dependencies needed. But, instead of inserting 30 separate libraries, he would
rather insert just 2 libraries. Mike: If he puts all the redistributable libraries in one place. The other issue is that this is strictly
build dependencies. There are runtime vs. build dependencies for some components. Jim: Issue that Brian
brought up that it would be nice to know, which jars are just needed for 1 or
two projects, we still preserve that in their build processes. Mary: For each component, build and runtime dependencies should still
be listed in the component pages of the wiki. Jeff: That would be great. To have a matrix that cross lists. There is
a lot of information out there - just hard to find. Mary: We have started to add cross references for the CQ statuses of
each third party library in each component. Jim: So some projects dependency pages are better then others. So you
are saying have one wiki place to download all the stuff not checked into CVS. Jim: So those links would just be in a file somewhere. Jim: If all of these dependencies were in a file the build script could
just pick them up. Valery: I’m working on automated build scripts now that should be
easy to maintain. To make it work need project dependencies... Jim: I like that proposal, don't like to have to maintain a list of
dependencies in multiple places: Wiki and the actual build process. It would be
nice if there was just one place Brian: One other simple idea: There are a number of obsolete projects. If
there was just a wiki page - this project is obsolete and has been refactored
into x and Y… This will be helpful to someone new who wants to build everything. Jim: Paul was going to create a list of all current projects. Valery: Paul is going to create a list of current projects. Jim: Can we put a read me at the top of each obsolete one Valery: To delete the projects from cvs need to go to webmaster Jim: Maybe Paul could have the obsolete ones deleted. We could do this
on a regular basis. Mary: Summarizing: so we are agreed that this topic is very important.
We need to enable developers to consume Higgins in three ways: build your own,
jar with source, build without source. Valery is working on the automated build
scripts. Jeff is going to do a clean build from scratch to test new process for
people who want to create their own build. Mary is going to review the IPR
status of all the third party dependencies and update the third party
dependency list found at http://wiki.eclipse.org/Higgins_Third_Party_Dependencies
, and the component dependency lists. 2) IdAS Registry Mary: The next topic is the work being done on the IdAS registry Markus: Have been working on the IdAS registry, trying to put together
documentation and examples then he will share to get people's feedback Jim: Seems like it is going
well to him. Hopefully when Markus puts out the draft, people can com can
comment and flesh it out Markus: Discussion of how many of the use cases really need to be
supported for 1.0 Jim: Echo’s Markus’ issue Drummond: How do we determine if this is a hard requirement? There is never a magic bullet. Should start
with the easiest [cleanest] design possible Jim: Not too worried about it. Need to take care of Valery’s real
use case and worry about theoretical stuff later. Mary: We are out of time and will continue next week. Action items: Several: Continue to address build issues Mary: Review status of all IPR items Mary: Make sure that all the IPR statuses are cross referenced on both
the third party dependency and component dependency wiki pages. Markus: Get out draft on IdAS Deferred action items Mary: Procedure for writing to the download server Paul: Send email about m 0.8 and m 0.9 build processes Paul: Create a list of all current projects All: Work on m 0.9 deliverables list/bugzilla items |