some details about source tree and 3rd party libs (was Re: [Laszlo-dev] Intro)

[Eric Bloch]

Hey Robby,

1) The build instructs for 2.2 and 3.x are actually the same right now. 
  Holy cow!

2) We're hoping to expose the source tree before the end of the year, if 
we're lucky.

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.

And finally

(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 
isn't enough.

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.

Others

* 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 
sometime.



Best,
-Eric


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
> 
> 
> 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,
>> Cheers,
>> Robby
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>
> 
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev