Re: JAWin install

Hi Roger

1) I have uploaded the refactored documentation to the Jawin mainsite:
http://jawinproject.sourceforge.net/ - I cross my fingers that I have
not created any dead links.

2) I have build the 1.0.19 and uploaded it to the upload.sourceforge.net
ftp-server, but I need you to perform the last few steps, as described here:
http://sourceforge.net/docman/display_doc.php?docid=6445&group_id=1#createrelease

(the uploaded file is named: jawin-1.0.19.zip - I think it will be
present for the next 24 hours on the release server).

I suggest something like the following for the release and change notes
(according to the SourceForge documentation, they should be set on the
"Step 1" section?):

Notes:
        Binary release of Jawin 1.0.19.
        MD5: 86f05b8abaf95e7ed02f2382e986a904 jawin-1.0.19.zip


Changes:
        - Deprecated the com.develop.jawin source and moved to org.jawin (Roger
I Martin and Paul Marquis).
        - New tool for stub generation: Jawin Type Browser (Josh Passenger and
Roger I Martin).
        - Refactored documentation to document the org.jawin branch (Morten
Andersen).
        - Refactored build to match the org.jawin branch (Morten Andersen).

For the full release history please see:
        http://jawinproject.sourceforge.net/jawinrevisions.html
.."

I have not uploaded any source-files. But hopefully I will get around to
making an ant target for building a src-release within the next couple
of days.

With regard to considerations about refactoring the marshalling, I must
admit I have already started slightly on that. Well, there are so
extremely many religious holidays in the spring in Denmark, so I had
some spare time. So what started out as a task to delve into some of the
Jawin classes and write some more Javadoc, evolved into refactoring some
of the marshalling for the Dispatch-code (amongst other things, I think
I added full support for SafeArrays, both [in] and [out]). To make sure
I did not create (to many) errors, I started by updating the JUnit
test-cases to test the org.jawin tree of the source. And I also added a
few new test-cases that gives an indicative time for certain calls
(something like calling the same native method X-thousand times), which
hopefully will be of good use if/when refactoring for speed with java.nio.

Unfortunately I newer got around to check my changes in to CVS, because
I must admit I broke a few of the existing "contracts" for the
interfaces. So before the checkin, I would ask here on the mailing list,
whether we should set out for eg. a 2.x version of Jawin, so we are
"allowed" to break existing behaviour. A good way to do that would
probably be to create a jawin_ver_1-branch in CVS, so that small fixes
could still be applied to stable version 1.x, while we develop the
unstable version 2.x on the HEAD of the CVS - with any changes we would
like.

If you, Robert, Josh and others think we should do this, we should
perhaps do a quick brainstorm here on the mailing list of what we would
like to change from today (unfortunately I am out of town during the
coming weekend, otherwise I could have posted a starting suggestion-list
- now I probably won't find time for it until some time next week)?

Best Regards
Morten

Roger I Martin PhD wrote: