You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <Ri...@Sun.COM> on 2007/10/23 16:55:11 UTC
building j2me support in Derby
Right now, we need 2 jar files in order to build the small device
support into Derby. Let me give them the following names:
1) foundation.jar
These are the pared-back versions of the core jdk classes in packages
like java.lang, java.util, etc.
2) jsr169.jar
These are the pared-back versions of the java.sql and javax.sql classes
needed to implement jsr 169, the small device version of the JDBC api.
Getting these jarballs is time-consuming and requires clicking through
licenses. For these reasons, the small device support is an optional
part of the Derby build. It would be good if we could eliminate this
time-consuming, license-encumbered step so that the standard Derby build
always compiled the small device support.
I can knock on doors here at Sun to see if I can get Derby versions of
these jarballs which are licensed for inclusion in our subversion
repository and usable by Derby's build process. I can't promise that
I'll succeed but I'm willing to try. Before I do this, I would like to
hear the community's advice:
A) Would it be sufficient to get versions which are licensed for use in
the Derby build but not for commercial use? Would that satisfy the AS IS
nature of our Apache license?
B) Are there other ideas about how we could get Derby unencumbered
jarballs so that we always build the small device support?
Thanks,
-Rick
Re: building j2me support in Derby
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Right now, we need 2 jar files in order to build the small device
> support into Derby.
> I can knock on doors here at Sun to see if I can get Derby versions of
> these jarballs which are licensed for inclusion in our subversion
> repository and usable by Derby's build process
Just to be clear, if a jar is in Derby's subversion repository then it
is also part of Derby's source release. Thus such jars would need to
have a licence that the ASF was comfortable with for releasing them.
See Category B: Binary Licenses Only in this page.
http://people.apache.org/~cliffs/3party.html
Dan.
Re: building j2me support in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>
>>>> Getting these jarballs is time-consuming and requires clicking
>>>> through licenses. For these reasons, the small device support is an
>>>> optional part of the Derby build. It would be good if we could
>>>> eliminate this time-consuming,
>
>> This would reduce the thrashing for new Derby release managers.
>
> I must be missing something, how much thrashing and time consuming is
> there really? Does this one-time step take longer than 15 minutes?
>
> Dan.
>
In my experience, yes it does. I found it to be a very frustrating
process with many false turns.
Regards,
-Rick
Re: building j2me support in Derby
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
>>> Getting these jarballs is time-consuming and requires clicking
>>> through licenses. For these reasons, the small device support is an
>>> optional part of the Derby build. It would be good if we could
>>> eliminate this time-consuming,
> This would reduce the thrashing for new Derby release managers.
I must be missing something, how much thrashing and time consuming is
there really? Does this one-time step take longer than 15 minutes?
Dan.
Re: building j2me support in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Right now, we need 2 jar files in order to build the small device
>> support into Derby. Let me give them the following names:
>>
>> 1) foundation.jar
>>
>> These are the pared-back versions of the core jdk classes in packages
>> like java.lang, java.util, etc.
>>
>> 2) jsr169.jar
>>
>> These are the pared-back versions of the java.sql and javax.sql
>> classes needed to implement jsr 169, the small device version of the
>> JDBC api.
>>
>> Getting these jarballs is time-consuming and requires clicking
>> through licenses. For these reasons, the small device support is an
>> optional part of the Derby build. It would be good if we could
>> eliminate this time-consuming, license-encumbered step so that the
>> standard Derby build always compiled the small device support.
>
> It would be good to simplify the build but I'm not sure who this would
> really help. For anyone using the official releases the J2ME support
> is already there. For anyone building their own jars for J2ME then
> they must already have the libraries for their own application.
This would reduce the thrashing for new Derby release managers.
>
>> I can knock on doors here at Sun to see if I can get Derby versions
>> of these jarballs which are licensed for inclusion in our subversion
>> repository and usable by Derby's build process. I can't promise that
>> I'll succeed but I'm willing to try. Before I do this, I would like
>> to hear the community's advice:
>>
>> A) Would it be sufficient to get versions which are licensed for use
>> in the Derby build but not for commercial use? Would that satisfy the
>> AS IS nature of our Apache license?
>
> Best to go to legal-discuss.
Thanks for that advice and for your follow-on post.
>
>> B) Are there other ideas about how we could get Derby unencumbered
>> jarballs so that we always build the small device support?
>
> Two possible options:
> 1) Look for an open-source J2ME option, Motorola has done MIDP but I
> haven't seen any Foundation open source projects.
I'm not aware of any either.
> 2) Take the Apache Harmony J2SE source and produce foundation &
> jsr169 jar files.
> 2a) As 2) but kick off an Apache J2ME project so that all can share.
>
> Dan.
Re: building j2me support in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:
>>> Daniel John Debrunner wrote:
>>>>
>>>>> B) Are there other ideas about how we could get Derby unencumbered
>>>>> jarballs so that we always build the small device support?
>>>>
>>>> Two possible options:
>>>> 1) Look for an open-source J2ME option, Motorola has done MIDP
>>>> but I haven't seen any Foundation open source projects.
>>>> 2) Take the Apache Harmony J2SE source and produce foundation &
>>>> jsr169 jar files.
>>>> 2a) As 2) but kick off an Apache J2ME project so that all can share.
>>> Or
>>>
>>> 2b) Provide stubbed out implementations of the foundation and jsr169
>>> classes. These would just throw runtime exceptions. You couldn't
>>> test against these classes, but you could compile against them.
>>
>> Actually I think 2) and 2b) are not possible. The ASF is part of the
>> JCP and thus is contracted to only distribute standard Java code if
>> it implements the spec (which 2b doesn't) and passes the TCK (which 2
>> fails on because I don't think the Derby project wants to get into
>> producing certified J2ME environments). If you want to check this you
>> can ask questions on jcp-open@apache.org.
>>
>> Dan.
> Thanks, Dan. I will follow up with that mailing list
>
> -Rick
I asked jcp-open@apache.org for advice and I received 2 responses. Both
responses thought that the JCP rules allow stub implementations. Here is
the email thread:
http://news.gmane.org/gmane.comp.apache.jcp-open/cutoff=955
Regards,
-Rick
Re: building j2me support in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Daniel John Debrunner wrote:
>>>
>>>> B) Are there other ideas about how we could get Derby unencumbered
>>>> jarballs so that we always build the small device support?
>>>
>>> Two possible options:
>>> 1) Look for an open-source J2ME option, Motorola has done MIDP but
>>> I haven't seen any Foundation open source projects.
>>> 2) Take the Apache Harmony J2SE source and produce foundation &
>>> jsr169 jar files.
>>> 2a) As 2) but kick off an Apache J2ME project so that all can share.
>> Or
>>
>> 2b) Provide stubbed out implementations of the foundation and jsr169
>> classes. These would just throw runtime exceptions. You couldn't test
>> against these classes, but you could compile against them.
>
> Actually I think 2) and 2b) are not possible. The ASF is part of the
> JCP and thus is contracted to only distribute standard Java code if it
> implements the spec (which 2b doesn't) and passes the TCK (which 2
> fails on because I don't think the Derby project wants to get into
> producing certified J2ME environments). If you want to check this you
> can ask questions on jcp-open@apache.org.
>
> Dan.
Thanks, Dan. I will follow up with that mailing list
-Rick
Re: building j2me support in Derby
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>>
>>> B) Are there other ideas about how we could get Derby unencumbered
>>> jarballs so that we always build the small device support?
>>
>> Two possible options:
>> 1) Look for an open-source J2ME option, Motorola has done MIDP but I
>> haven't seen any Foundation open source projects.
>> 2) Take the Apache Harmony J2SE source and produce foundation &
>> jsr169 jar files.
>> 2a) As 2) but kick off an Apache J2ME project so that all can share.
> Or
>
> 2b) Provide stubbed out implementations of the foundation and jsr169
> classes. These would just throw runtime exceptions. You couldn't test
> against these classes, but you could compile against them.
Actually I think 2) and 2b) are not possible. The ASF is part of the JCP
and thus is contracted to only distribute standard Java code if it
implements the spec (which 2b doesn't) and passes the TCK (which 2 fails
on because I don't think the Derby project wants to get into producing
certified J2ME environments). If you want to check this you can ask
questions on jcp-open@apache.org.
Dan.
Re: building j2me support in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
>
>> B) Are there other ideas about how we could get Derby unencumbered
>> jarballs so that we always build the small device support?
>
> Two possible options:
> 1) Look for an open-source J2ME option, Motorola has done MIDP but I
> haven't seen any Foundation open source projects.
> 2) Take the Apache Harmony J2SE source and produce foundation &
> jsr169 jar files.
> 2a) As 2) but kick off an Apache J2ME project so that all can share.
Or
2b) Provide stubbed out implementations of the foundation and jsr169
classes. These would just throw runtime exceptions. You couldn't test
against these classes, but you could compile against them.
Regards,
-Rick
>
> Dan.
Re: building j2me support in Derby
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Right now, we need 2 jar files in order to build the small device
> support into Derby. Let me give them the following names:
>
> 1) foundation.jar
>
> These are the pared-back versions of the core jdk classes in packages
> like java.lang, java.util, etc.
>
> 2) jsr169.jar
>
> These are the pared-back versions of the java.sql and javax.sql classes
> needed to implement jsr 169, the small device version of the JDBC api.
>
> Getting these jarballs is time-consuming and requires clicking through
> licenses. For these reasons, the small device support is an optional
> part of the Derby build. It would be good if we could eliminate this
> time-consuming, license-encumbered step so that the standard Derby build
> always compiled the small device support.
It would be good to simplify the build but I'm not sure who this would
really help. For anyone using the official releases the J2ME support is
already there. For anyone building their own jars for J2ME then they
must already have the libraries for their own application.
> I can knock on doors here at Sun to see if I can get Derby versions of
> these jarballs which are licensed for inclusion in our subversion
> repository and usable by Derby's build process. I can't promise that
> I'll succeed but I'm willing to try. Before I do this, I would like to
> hear the community's advice:
>
> A) Would it be sufficient to get versions which are licensed for use in
> the Derby build but not for commercial use? Would that satisfy the AS IS
> nature of our Apache license?
Best to go to legal-discuss.
> B) Are there other ideas about how we could get Derby unencumbered
> jarballs so that we always build the small device support?
Two possible options:
1) Look for an open-source J2ME option, Motorola has done MIDP but I
haven't seen any Foundation open source projects.
2) Take the Apache Harmony J2SE source and produce foundation &
jsr169 jar files.
2a) As 2) but kick off an Apache J2ME project so that all can share.
Dan.