|[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.
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
*Jim Sermersheim - Novell
*George Stanchev - Serena
Abhi Schelat - IBM
Paul Trevithick - Parity/SocialPhysics
Paul Trevithick - Parity/SocialPhysics
Tony Nadalin - IBM
• 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.
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
Back to the top