Great idea - as a recent first time user of JBoss + CVS, I was somewhat
confused with the CVS and build processess. A couple of other ideas:

1.      A per-module build property for CVS updates - so for any given JBoss
build, I can get a given tagged version of a module or the entire project.
2.      Some documentation for new users of CVS + JBoss - ie. which modules are
necessary to build a complete installation of JBoss.

Having browsed this mailing list and SourceForge for a while, I cannot find
any release plans indicating what features added, bugs fixed, etc for the
next release (now 2.3 beta). Are these discussions held offline, or are they
publicly available?

Regards,

Liam.

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jason
> Dillon
> Sent: Tuesday, 24 April 2001 7:01 AM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] Build system & source organization improvements
>
>
> Hello,
>
> I am a little frustrated with the JBoss build system, and I would like to
> try and find a way to fix it.  The purpose of this email to try and get a
> feel for what other developers needs are and how we can modify the system
> to meet those needs.
>
> My basic complaints are these:
>
>  o Inconsistent build support organization
>
>    Build files (build.xml) seem to live in different places depending on
>    which part of the system you check out.  For example, jboss/admin has
>    admin/build/build.xml (with only win32 .bat files) and jboss/jboss has
>    src/build/build.xml (and builds files into jboss/build).
>
>    Having a single consistent structure for the location of these
> files will
>    make it dramatically easier to construct a modular system to build any
>    part of JBoss (either core or support module).
>
>  o Poor module and external project integration
>
>    It appears that the current system relies on imported binaries built
>    from other modules (such as the jbossmq module).  This seems like it
>    will make it increasingly difficult to separate support modules from
>    the core infrastructure.
>
>    Each of the external modules wants to have a JBOSS_HOME environment
>    variable or something similar set, but each declares, or makes use of
>    it in different ways.  This makes it difficult to rebuild a
> given module
>    if you are not familiar with the requirements that it has.
>
> I strongly feel that this project could benefit greatly by implementing
> a more modular build system.  I believe that by doing so it will make it
> easier to isolate the core infrastructure from any external modules, which
> should make it easier to extend and maintain.
>
> I am not really sure what the best way is to go about implementing this
> though, and I would like to know what the rest of you think about this.
>
> I think that this could be broken down into a build system for a module
> (ie core, jbossmq, jbosssx) and then a system to aggregate the module
> build systems together.  The later could be used to produce a release
> archive for the entire system.
>
> I looked a little at NetBeans, which basically does something very
> similar to this, but is a bit clumsy to get working correctly.  I would
> like to have the JBoss build system be very easy to use, such that a new
> user, who wanted to get all of the modules from CVS and build the entire
> system could do something like this:
>
>  > cvs -d ... get jboss-all
>
> This would produce a directory 'jboss-all', which would contain sub-
> directories for each module (core, jbossmq, admin...)
>
>  > cd jboss-all
>  > ./build
>
> This would execute the build system for each of the modules under
> jboss-all,
> then build a release directory which would contain the aggregate of each
> of the modules release directories.
>
> To get this sort of thing to work, we would need to have a very consistent
> directory structure under each module, that contained a set of standard
> targets that built files into common directories under that module.
>
> I am probably going to play around with some ideas that I have on how to
> implement this.  If anyone has any comments on this I would really like
> to hear them.
>
> Thanks for your time,
>
> --jason
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development


_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to