some details about source tree and 3rd party libs (was Re:
bloch at laszlosystems.com
Tue Dec 14 21:54:54 PST 2004
1) The build instructs for 2.2 and 3.x are actually the same right now.
2) We're hoping to expose the source tree before the end of the year, if
3) Opening up bug tracking will come in 2005.
4) The contributors process/agreement should be in place any day now.
Oliver may have more details and updates to some of this.
(5) re: updating jakarta libs -
I'd prefer we discuss each upgrade. We are careful and conscious about
upgrading 3rd party packages. Upgrading packages includes some risk --
sometimes enough risk that the potential gain and eased maintenance
Some of the classes we package up in the lps webapp are there for
"transitive" purposes - we use package A and package A uses package B so
we need package B, etc. We have to be careful to make sure the
dependencies and versions are _just right_ here. Hopefully, moving to
maven for some of this will help; at least I'm told it should.
Also, the "if it ain't broke, don't fix it" maxim holds some value. We
test and verify against a fixed, known set of versions of 3rd-party
packages. We don't encourage mixing and matching. Our set of
dependencies is large enough that sometimes, when you want to use Laszlo
with other java server-side code, we recommend you use two webapps to
avoid java class conflicts. That is, you can keep the lps in one webapp
and have your LZX code refer to another webapp for its data/services.
All that said, here's what I can say on a number of the packages in the
3.0a2 source tree in WEB-INF/lib
* jdom should be updated to 1.0 and is non-trivial since an api changed
from the b8 version we use now. (Henry has more details and a few other
folks have posted about it). You could do this, but I think someone
else has already posted that they've gone about it already.
Things from commons:
* commons-collections.jar - Culd be updated if there's a reason. We
make use of a few things there.
* commons-discovery.jar - We don't use this, I believe it can actually
be removed now.
* commons-httpclient-2.0-rc1.jar - we use this and I would like to be
involved in any upgrades/updates. Going to the latest 2.x should be
safe, but I'd want to review their changelog and haven't. Going to 3.x
would be nice, too, but there's a few other things that should probably
happen at the same time. It's also possible we may want to build this
from source so that we can avoid commons-logging. I contributed an ant
build file that does this for 2.0-rc1.
* commons-jexl-1.0-dev.jar - Needed by jgenerator 2.2 source - would
prefer not to upgrade this. it's likely we only need this for compiling
the jgenerator classes and could avoid keeping it in WEB-INF/lib since
we don't ever hit it at runtime.
* commons-logging.jar (used in one place in com.laszlosystems and used
by other 3rd-party pieces including axis) - I'd actually love to remove
our dependence on this package.
* jakarta-regexp-1.2 - Could be upgraded if there's a reason. We could
also drop our use of this and move to the support available in java 1.4
(now that we no longer support 1.3). But it's stable and works fine
afai know and I see no reason to upgrade it.
* log4j - This could be upgraded to latest 1.2.x and would probably be
as simple as replacing the jar in the handful of places we have it
(including inside tomcat). We make standard use of this package afai
know and I don't believe any of the apis we use have changed.
* batik-svggen.jar - We use the ttf parser in this package for our
TTF2FFT code. It could be upgraded if there was a reason. I believe
our version of this jar was build from 1.5 source and includes a bug fix
or two we made. So we'd need to make sure those fixes have been rolled in.
* axis.jar - I think we might want to move to compiling this from source
or, at least, move to something recent. Pablo Kang should have details.
* tomcat - latest 5.0.x might be prudent but 5.0.24 is working fine for
us wrt to using it for development. we have minor changes (mostly to
start up scripts to increase the default mem size) that would have to be
merged. We could talk about 5.5 if folks think it's stable and worth it.
If I was a better boy, I might move some of these details to the wiki
Robby Lansaw wrote:
> Also, one would assume that the build instructions between 2.2 and 3.x
> have changed, is there a build sheet for 3 around somewhere? Cheers
> Robby Lansaw wrote:
>> Just seen that the list has been quiet as of late, so I figured I'd
>> stir the pot.
>> Where are we at with source access? I know it's a busy time of year,
>> so it's not an official complaint. I'm just aware it's been talked
>> about for a while now.
>> To get around the tree, I figured I would venture into updating all of
>> the jakarta libs in use (commons etc), is there any objections to that
>> target, any catchalls I should be aware of? Is there a contrib
>> agreement setup, or timescale when it's going to be?
>> Think that's all for now,
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
More information about the Laszlo-dev