> Hmmmmm.... !
>
> I noticed your checkins on jboss-dev and wondered what
> you were up to....
Making life better I hope.
> 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.
Cool. The entire source? Or as a dependency lib with JBoss
specific adapters?
> Marc is driving this. I shall be sitting between the
> JBoss and Jetty communities and trying to maintain the
> code.
So I guess source then. Why? Sounds like it might be maintenance headache.
> 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????
Exactly. No more binary integrations for modules, they are all built from
sources.
> 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...
Well, right now the contrib/jetty module is integrated in the jboss-all
supermodule as plugins/jetty in the jboss_buildmagic branch. This is
basically just the stuff from HEAD in contrib/jetty with its build system
modified for buildmagic.
Note, that jboss/plugins/jetty and contrib/jetty are the exact same CVS
module. The namespace changes due to some magic in CVSROOT/modules.
I suggest that anyone having troubles with this concept should checkout
CVSROOT and read the comments in the modules file. I will get to adding a
web page for this soon, but until then take a look a the source.
> > 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...
If we are actually thinking of (or activly planning) to import the whole of
jetty sources then this can go away. Otherwise the general model is to
check in thridparty stuff that is required to make things work into cvs in
the thirdparty module.
I will eventually figure out a nice way to limit what gets pulled from cvs
from module to module, but for now all modules share it.
> > 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
That is what the thirdparty modules solves. Only one copy is ever checked
in. But all modules share it so, if you wanted to just built module x which
had one dependency from thirdparty, you will still have the check then
entire beast out.
> 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.....
It is a trade of between sharing and avoiding duplication, as well as
working around the problem with CVSROOT/modules and `cvs update`. I is
possible to selectivly include thirdparty directories on a per-module basis
at the cost of duplicating files which are common between modules.
Note sure which is the lesser of the two evils. For now one directory is,
cause it is already working like that.
> > 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.
True. Can I get some more details how this, so I can better advise on how
to continue with respect to the build system?
> > 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...
Cool. I will merge these changes then and add the plugins/jetty to the
standard plugin list.
Let me know when it comes closer to any imports.
> 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...
Perhaps when the time is right, the moon will align with the sun and dogs
might fly... who knows =)
--jason
ps. flying dogs might be kinda neat.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
