You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Immanuel, Gidado-Yisa" <av...@cdc.gov> on 2002/03/05 18:30:56 UTC
RE: Notes on building Struts from scratch (CVS Main)
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:avm3@cdc.gov]
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>