Re: AW: Proposal for restructuring JuiCE files - and some new functions

> Berin,
>
> don't worry too much :-). I've tried to keep the C files
> clean and without compiler warning  even in Visual C
> (maybe not always the newest ... ) .
>
> Once we are somehow convinced we can have a first alpha
> or beta we need to think about to package the Windows
> native library (installer?)
>
> Regards,
> Werner
>
>
>>-----Ursprüngliche Nachricht-----
>>Von: Berin Lautenbach [mailto:berin@...]
>>Gesendet: Dienstag, 21. März 2006 09:17
>>An: juice-dev@...
>>Betreff: Re: Proposal for restructuring JuiCE files - and
>>some new functions
>>
>>+1.  I really must get onto the Project files.  I've been
>>trying to tie
>>up some stuff on the xml-security library.
>>
>>Cheers,
>> Berin
>>
>>Dittmann, Werner wrote:
>>
>>>All,
>>>
>>>after some tests and discussions with the BC guys a first step
>>>of the Elliptic Curve (EC) functions is available:
>>>
>>>- key generation for various key lengths according to X9.62
>>>- EC DSA with SHA1
>>>
>>>During the interop tests we got some problems with older versions
>>>of BC. Thus to interop with BC you have to use version 1.31 (or
>>>greater).
>>>
>>>While looking at EC and some other security stuff it became clear
>>>that a restructuring of the JuiCE files will be necessary. The
>>>Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several
>>>enhancements of security both in java.security.* and javax.crypto.*
>>>that are _not_ compatible and/or fully upward compatible.
>>
>>To overcome
>>
>>>this problem we should introduce a structure similar to BC (similiar
>>>problems lead to similar solutions :-)  )
>>>
>>>Currently we have:
>>>
>>>JuiCE/java/src/org/...
>>> and the classes stored in
>>>JuiCE/build/classes/...
>>>
>>>I propose the following structure:
>>>
>>>Juice/java/common/src/... the Java source files
>>>Juice/java/common/build/classes/... the class files
>>>Juice/java/common/build/... other files, dirs, (resources,
>>>etc)
>>>Juice/java/common/test/... test cases
>>>
>>>Juice/java/jdk14/src/...
>>>Juice/java/jdk14/build/classes/... the class files
>>>Juice/java/jdk14/build/... other files (resources, etc)
>>>Juice/java/jdk14/test/... test cases
>>>
>>>Juice/java/java5/src/...
>>>Juice/java/java5/build/classes/... the class files
>>>Juice/java/java5/build/... other files (resources, etc)
>>>Juice/java/java5/test/... test cases
>>>
>>>Such a structure would also support an Eclipse setup
>>
>>defining common,
>>
>>>jdk14,
>>>java5, ... as single projects that have dependencies. This
>>
>>is somehow
>>
>>>similar to the Axis2 setup with its modules (in our case
>>
>>the modules are
>>
>>>"common", "jdk14", "java5", ...).
>>>
>>>The distribution would then combine "common" and one of the
>>
>>Java version
>>
>>>dependent module to build a JuiCE jar. The names of the
>>
>>JuiCE jars would
>>
>>>be:
>>>
>>>juice-jdk14-0.9.jar
>>>juice-java5-0.9.jar
>>>
>>>where 0.9 would be a current JuiCE version number.
>>>
>>>I don't see any problems for the native code. It would always be a
>>>superset
>>>of functions required by the various Java JCE classes.
>>>
>>>Any thoughts, ideas?
>>>
>>>Regards,
>>>Werner
>>>
>>>
>>
>>---------------------------------------------------------------------
>>
>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>For additional commands, e-mail: juice-dev-help@...
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>For additional commands, e-mail: juice-dev-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>
>