RE: Zeus: Version numbers

["Ben Cottrill" <cottrill@xxxxxxxxxx>]

Using zeus now to send WCTP messages and examine responses.  My project is
in the feasibility testing stage.  Zeus seems ideal for this, and will most
likely be in a production system in a few months.  I have been able to
create, send and receive and receive objects from skytel's gateway server,
though I have only done the most rudimentary testing.  Also, the code is
fairly straightforward to modify for non-standard responses, BUT ....

One minor gripe I have, that is already on the todo list, is the very
non-specific io errors.  It took me a while yesterday to trace a method
access error to a capitalization difference (skytel's implementation... yes
vs Yes).  The error should have said that I was trying to set an invalid
value for an attribute (IllegalArgumentException is thrown from the
generated class, but is somehow mangled into an ioexception) instead of
saying that there was merely an io error in accessing the object.  Once
found, the error took 1 minute and 4 lines of code to fix, but finding the
error took about 90 minutes.  I am not quite sure what the best way of
implementing the change would be, but I do know that better propogation
would have been a great help in debugging my generated classes.  The way I
did it was pretty lame(added a myriad of System.out.prinln() statements to
the unmarshaller class).


Zeus seems to be a great package so far, and has really flattened what I
thought would be a steep learning curve.

Regards,
Ben



-----Original Message-----
From: zeus-admin@xxxxxxxxxxx [mailto:zeus-admin@xxxxxxxxxxx]On Behalf Of
Sean Ogle
Sent: Friday, July 27, 2001 11:00 AM
To: zeus@xxxxxxxxxxx
Subject: RE: Zeus: Version numbers


Hi Maciej,

A stable Zeus would be nice indeed. But also one that works well. Performing
nightly builds isn't such a bad idea. It would also be nice if we could find
some slaves to write test code. I can write alot of JUnit tests for the code
I am working on now but we need some black box testing. As well as a way to
automatically run all of the tests.

Here are my goals for "1.0":

0. What we have now.

1. The level of DTD structure support that we currently have. No tricky1 or
tricky2, I just can't think of a reasonable way to do this automatically.
People always have the option to write their own Impl classes that can
handle unusual cases (especially in the self marshalling/unmarshalling
classes.)

2. Only very basic Schema support. Enough to associate a class with an
attribute and a class with an element, and simple enumerations. I don't know
where the Schema support is right now but I am going to dig into it this
weekend.

3. Stable generators: SimpleGenerator as well as the AutoGenerator.

4. Ability for the user to map any XML name to any Java variable name. I
have code to do that already but it needs more testing. I will do a big post
before I go home tonight. The code also allows the programmer to build his
own NameTransform classes independent of the binder and the generator. These
classes take care of any kind of funky XML name to Java name people want.
They also completely empower the user to avoid any naming conflict.

These goals will allow Zeus to generate code slightly better than the hand
generated code that one of my colleagues toiled over for a month. And many
other people have toiled over the inherent mistakes in that code. And we
have found that our DTD's actually change often at this stage of
development. With the code I have in my hands now the only major thing
missing is the little bit of Schema support that I need, and lots of
testing.

I propose we create a branch where I can checkin all of my changes and then
run tests against both branches. Of course some tests won't work in both
branches. Let's set a target date for 1.0. How about one month from now?
Does anybody else care?

-Sean


-----Original Message-----
From: zeus-admin@xxxxxxxxxxx [mailto:zeus-admin@xxxxxxxxxxx]On Behalf Of
Maciej Zawadzki
Sent: Friday, July 27, 2001 4:31 PM
To: Zeus
Subject: Zeus: Version numbers


Hello,

How many people are using Zeus in production projects?

The reason I ask is that we should think about starting to produce builds of
Zeus tagged with version numbers.  I'm not talking about releasing zeus or
claiming that it is now stable (release quality) code.  I'm talking about
possibly making nightly builds that are tagged with a build number.  That
may get us started thinking more about getting the code base stable and to
release quality.

I think that the recent work on the test cases is very needed and very
helpful.  I also think that we need to set some goals for version 1.0 of
Zeus.  Without explicitly stated goals, how will we know whether we have met
or even surpassed the requirements of version 1.0.  For example, is it the
goal of version 1.0 to support all the possibilities presented by a DTD.
I'm talking about some of the complex examples pointed out by Sean Ogle on
6/25/01:

        <!ELEMENT tricky1 (childA, (childB, childC)+, childD)>

        <!ELEMENT tricky2 (childA | (childB, childC)+ |childD)+ >

Another example is, -- what is the intended support for Schemas in version
1.0?  It is OK for us to release version 1.0 without support for every
possible functionality out there.  But we need to identify what
functionality we will support and what functionality is beyond the scope of
verison 1.0 and should be put off to future versions.

I guess that my whole point is that we should try to introduce stability
into the code base, or at least into the API and features.  That kind of
stability makes it a lot easier to actually use Zeus in other projects.

Anyhow, I've rambled on long enough.  Give me some feedback guys, let me
know what you think.

Thanks,

--Maciej

_______________________________________________
Zeus mailing list
Zeus@xxxxxxxxxxx
http://www.enhydra.org/mailman/listinfo.cgi/zeus

_______________________________________________
Zeus mailing list
Zeus@xxxxxxxxxxx
http://www.enhydra.org/mailman/listinfo.cgi/zeus