I just wanted to add a few comments to the build process that I went through. Please take my suggestions with a grain of salt: I'm usually lurking, and not slugging it out on struts-dev, commons-dev like the rest of you, so I don't know all the implications of what I'm suggesting.
In the process of building struts... > I ended up with: > PRODUCT VERSION > commons-collections.jar 1.0 > commons-pool.jar CVS-Main > commons-logging.jar CVS-Main > commons-validator.jar CVS-Main > commons-dbcp.jar CVS-Main > commons-digester.jar CVS-Main > commons-beanutils.jar CVS-Main > commons-services.jar CVS-Main > regexp.jar 1.2 1. Struts has dependencies on products that are not released: . commons-pool.jar . commons-dbcp.jar It makes it impossible to check out the same libraries that the nightly-builder and other developers have checked-out when they build struts. This, I think can make things more difficult when tracking down dependency bugs. SUGGESTION: Only use dependent-products (i.e. libraries) that are released (with a version number) 2. Struts has dependencies on commons-sandbox products that are not released: . commons-services.jar Note that when I build services itself, it does not use any of released products (only the latest and greatest from CVS-Main). I then have to cascade these dependencies up to the rest of my builds (I think). SUGGESTION: Don't inlucde an commons-sandbox products. It just seems to me that if it's in sandbox, it has not graduated to something that can be included in a released product. (Now this is a general statement and not aimed at Oleg or common-services by any means!...from what I understand, Oleg, you do great work.) 3. SUGGESTION: If a prodcut is to be released, it should only include libraries that are released (i.e. have a version number, and are downloadable). Can get the same versions of libraries for building products. I guess an alternative to using releases is to specify a date on which certain products were built, so that I can go back into CVS and checkout the dependent-product from that date. More work...but not impossible. I can understand some of Jon's frustrations when trying to build workflow some months ago. Also, I KNOW that this versioning stuff has been hashed out on commons-dev before, so I'm not certainly not baiting that discussion. Anyway, as I recall, JJAR should take care of the automating getting the right version of a dependent-library. Thanks for hearing me out, Gidado > -----Original Message----- > From: Immanuel, Gidado-Yisa [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 05, 2002 11:59 AM > To: 'Struts Developers List' > Subject: Notes on building Struts from scratch (CVS Main) > > > I was trying to build struts from source (nightlies and CVS-MAIN), and > found it a little less than straight forward. I did not see any help > in the archives...So this text documents my trials to > succesfully build > struts from scratch...it's here for the record. Also, if > there is a much > simpler way to do this, please let me know. If this text is > helpful in > the installation doc, let me know and I'll write a patch > (especially now > that I can build struts :) > > I started with the following jars: > commons-digester.jar (v. 1.1) > commons-beanutils.jar (v. 1.0) > commons-collections.jar (v. 1.0) > > > A. BUILD STRUTS (MAIN branch) > ----------------------------- > 1. Download nightly (our checkout jakarta-struts MAIN) > 2. Create the file ${user.home}/build.properties > 3. Set properties in build.properties > . commons-collections.jar > . commons-beanutils.jar > 4. We find that out that we need > . commons-dbcp.jar > . commons-pool.jar > See: > http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg0 > 4437.html > But since there was no released version (that I could > locate) of dbcp, > I checked out the source from CVS and began to build. Go > to Step B-1 > 4. Set properties in build.properties > . commons-dbcp.jar (v. CVS-Main) > . commons-digester.jar > 5. We find that out that we need > . commons-logging.jar (v. CVS-Main) > See: > http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg0 > 4271.html > And there *is* a 1.0 for logging :) > Get it from http://jakarta.apache.org/commons/logging.html > and install > 6. Set properties in build.properties > . commons-logging.jar > 7. We find that out that we need > . commons-services.jar > See: > http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg0 > 4739.html > But since there was no released version (that I could locate) of > services, > I checked out the source from CVS and began to build. Go > to Step D-1 > 8. Set properties in build.properties > . commons-services.jar (v. CVS-Main) > 9. We find that out that we need > . comomons-validator.jar > Go to Step F-1 > 10. Set properties in build.properties: > . commons-validator.jar (v. CVS-Main) > . servlet.jar > 11. We find that out that we need DynaBean support found in the latest > . comomons-beanutils.jar > Go to Step F-1 > 12. Set properties in build.properties: > . commons-beanutils.jar (v. CVS-Main) > 13. Need to specify how to locate xalan.jar for ANT build. See: > > http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg0 > 4210.html > You've got to get a copy of Xalan and put it in ${ANT.HOME}/lib > 14. Builds...great! Done. > > > B. BUILD DBCP (MAIN branch) > --------------------------- > 1. Checkout jakarta-commons > 2. Go into dbcp, and 'ant dist' > 3. Dependency on 'commons-pool'. (Did not see a release of > this, so have > to build myself). Got to Step C-1 > 4. Set properties in build.properties > . commons-pool.jar > . jdbc20ext.jar > 5. Builds...great! Continue with Step A-5 > > > C. BUILD POOL (MAIN branch) > --------------------------- > 1. Go into jakarta-commons/pool, run 'ant dist' > 2. Builds...great! Continue with Step B-4 > > > D. BUILD SERVICES (MAIN branch) > --------------------------- > 1. Checkout jakarta-commons-sandbox > 2. Go into jakarta-commons-sandbox/services, run 'ant dist' > 3. Uhhhh.oooh, it requires some digester code...what version could it > possibly want? Let's check the build file to see if there are any > indications. Hmmm, no info here...(tried 1.1.1, but no success). > Well, we probably cannot go wrong with CVS-Main branch. > Go to Step E-1. > 3. Reset properties in build.properties > . commons-digester.jar (v. CVS-Main) > 4. Builds...great! Continue with Step A-8 > > > E. BUILD DIGESTER (MAIN branch) > ------------------------------- > 1. Go into jakarta-commons/digester, run 'ant dist' > 2. Uhhhh.oooh, it requires some beanutils code...what version could it > possibly want? Let's check the build file to see if there are any > indications. Hmmm, no info here...(tried 1.2 and it works) > 3. Reset properties in build.properties > . commons-beanutils.jar (v. 1.2) > 4. Builds...great! Continue with Step D-3 > > > F. BUILD VALIDATOR (MAIN branch) > ------------------------------- > 1. Go into jakarta-commons/validator, run 'ant dist' > 2. We find that out that we need > . regexp.jar (v. 1.2) > See: http://jakarta.apache.org/regexp/index.html > 3. Set properties in build.properties > . regexp.jar (v. 1.2) > 4. Builds...great! Continue with Step A-10 > > > F. BUILD BEANUTILS (MAIN branch) > ------------------------------- > 1. Go into jakarta-commons/beanutils, run 'ant dist' > 4. Builds...great! Continue with Step A-12 > > > We started with the following requirements as specified in the doc: > http://jakarta.apache.org/struts/userGuide/installation.html > PRODUCT VERSION > commons-digester.jar 1.1 > commons-beanutils.jar 1.0 > commons-collections.jar 1.0 > > I ended up with: > PRODUCT VERSION > commons-collections.jar 1.0 > commons-pool.jar CVS-Main > commons-logging.jar CVS-Main > commons-validator.jar CVS-Main > commons-dbcp.jar CVS-Main > commons-digester.jar CVS-Main > commons-beanutils.jar CVS-Main > commons-services.jar CVS-Main > regexp.jar 1.2 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>