Hmmmmm.... !
I noticed your checkins on jboss-dev and wondered what
you were up to....
there is one issue that we need to address before
going into this in more depth.
There are plans afoot to merge a repackaged version of
Jetty into the main JBoss tree and use it as the
default web container with JBoss. i.e. my
understanding is that unless you explicitly download a
JBoss-Tomcat package you will end up with a
JBoss/Jetty one.
Marc is driving this. I shall be sitting between the
JBoss and Jetty communities and trying to maintain the
code.
I haven't been following build-magic too closely, but
as I figure it, it makes the intra-module dependencies
in JBoss more explicit so it is easier to build a
complete and up-to-date distribution????
In this case you should bear in mind the forthcoming
changes to the Jetty codebase, since the whole tree
may suddenly move from contrib into jboss, a number of
directories will change names and pretty much every
source file will be altered. I don't know how heavily
this will impact on you - but we should coordinate our
efforts here...
Now on to the rest of your mail...
--- Jason Dillon <[EMAIL PROTECTED]> wrote: > Hello,
I have a version of the contrib/jetty module
> (from the
> jboss_buildmagic) branch, which has been updated to
> function with the new
> build system. It looks like you work with most of
> the jboss-jetty releases,
> so I wanted to pass this by you before I commit
> anything back to HEAD.
>
fair enough....
> As the changes stand now (in the jboss_buildmagic)
> branch, the plugins/jetty
> module can be included in the jboss-all supermodule.
> When a release is
> built it will compile the support classes into
> jetty-plugin.jar and copy
> over all of the jetty support jars into lib/ext.
>
> There are a few issues that I wanted to touch on
> here.
>
> First, I added the Jetty 3.1 rc7 & Jetty3Extra
> v0.0.5 (which I just
> downloaded from SF) into thirdparty/mortbay/...
You should talk to Marc about this. The issues that I
have mentioned above may mean that we will have to
change this directory...
> This is the first issue,
> that currently there is no way to allow per module
> thirdparty libraries to
> be included selectivly. It is possible to trim down
> the stuff from
> thirdparty, but then when items are added, users are
> forced to `cvs
> checkout` of that module to use the newest
> CVSROOT/modules defintions.
>
> The Jetty support jars are small, so for now I just
> added them. I would
> like to have a general solution to this problem
> though. It might be
> including per module specific jars in a local lib
> directory, or it might be
> defining thirdparty includes for each module, which
> would mean that each
> module would have copies of each jar that it
> depeneds on, but there would
> really be only one version in the repository. Not
> sure what is best at the
> moment.
I'll leave that all to you - sounds like an
interesting can of worms. If each plugin keeps it's
own copy of it's consumables, but ultimately they all
share the same copy in the distrib, then I assume they
are built against the local copy and run against the
shared one. We'll need to be very careful about having
different versions of popular jars flying around (have
I missed the point here?). I think it would be much
safer to build and run against the same platform -
i.e. do the sharing of these resources in the build
tree as well as the runtime.....
>
> Second, I think that it would make life easier for
> releasing the jboss-jetty
> distribution, but setting up a new jboss-jetty
> module, which would compile
> and create the proper jboss-jetty-xxx.zip. This is
> currently possible, as
> was done for the standalone JBossMQ, but there are
> some minor problems.
> One is that since modules "export" files into a
> rather static namespace, it
> is mostly an all or nothing when it comes to
> including released files from a
> module into a project release.
>
The stuff I mentioned above will also impact on this.
I figure I will be excused release duties once it is
done, since Jetty will be going out in every JBoss
release... So this bit is not so relevant. It all
depends on whether you need to check in your stuff
before I am ready to for the repackaging.
> I plan to have this fixed. I am thinking about a
> few ways which this could
> be implemented, but I will probably not have time to
> actually implement this
> for a little while.
>
> Third, there is no really easy way to add custom
> plugin configuration to the
> bits generated by the jboss/server module. I hope
> that once RH is ready
> that this can be done by simply installing a .sar
> and a .jcml-configlet into
> a deploy/service/ directory or something.
Sounds interesting...
>
> Any ways, I would like to merge the changes from
> jboss_buildmagic for the
> plugins/jetty (contrib/jetty) module, so that things
> do not get out of date.
>
You are welcome to go for it, just bear in mind that
things will change over the next month or so...
I'm not sure if Marc has me on a timeline for this
repackaging or not and if so whether this is pre-RH or
post (and when is RH?).
Maybe he will enlighten us...
Jules
> What do you think?
>
> --jason
>
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
