[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with >= JDK6

[Kathy Saunders (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095596#comment-13095596
 ] 

Kathy Saunders commented on DERBY-5363:
---

I just wanted to comment on this issue as I have worked with Derby for a long 
time and have also worked in a support capacity with customers who use Derby.  
I think that Kathey said it well--the embedded solution was originally designed 
to be zero admin, and not secure by default (to keep administration to a 
mimimum).  Many people who use embedded Derby protect it at other levels within 
their solutions.  I have seen many uses of embedded Derby that would break if 
the permissions of the DB files change.  From a support perspective, changing 
the default behavior generally causes confusion.  I would expect that a change 
like this would generate issues when people upgrade, as they may not have read 
the documentation that talks about the new behavior. My vote would be to leave 
the default permissions as is in the embedded case. 

> Tighten default permissions of DB files with >= JDK6
> 
>
> Key: DERBY-5363
> URL: https://issues.apache.org/jira/browse/DERBY-5363
> Project: Derby
>  Issue Type: Improvement
>  Components: Miscellaneous, Services, Store
>Reporter: Dag H. Wanvik
>Assignee: Dag H. Wanvik
> Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, 
> derby-5363-basic-2.diff, derby-5363-basic-2.stat, permission-5.diff, 
> permission-5.stat, permission-6.diff, permission-6.stat, property-table.png, 
> z.sql
>
>
> Before Java 6, files created by Derby would have the default
> permissions of the operating system context. Under Unix, this would
> depend on the effective umask of the process that started the Java VM.
> In Java 6 and 7, there are methods available that allows tightening up this
> (File.setReadable, setWritable), making it less likely that somebody
> would accidentally run Derby with a too lenient default.
> I suggest we take advantage of this, and let Derby by default (in Java
> 6 and higher) limit the visibility to the OS user that starts the VM,
> e.g. on Unix this would be equivalent to running with umask 0077. More
> secure by default is good, I think.
> We could have a flag, e.g. "derby.storage.useDefaultFilePermissions"
> that when set to true, would give the old behavior.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: 10.2 plans (was Re: 10.2 licensing issue)

[Kathy Saunders]

Lance J. Andersen wrote:






2 - Regarding the Mustang and JDBC 4 issue, my general opinion is 
that if Mustang is still coming out in October then it may be worth 
it to continue on our current path and do a release that includes 
JDBC 4.  If Mustang is delayed, then I think it's just time to get 
10.2 done to get some of the other good features out there.  It's 
been quite a while since we've had a feature release.  Does anyone 
know the current schedule for Mustang?



see http://blogs.sun.com/mr/entry/java_se_6_schedule_update  for 
details on the SE 6 schedule




Kathy



Thank you for the link, Lance.  Given these new dates, my vote is to go 
ahead and release Derby 10.2 without JDBC 4.


Kathy

Re: 10.2 plans (was Re: 10.2 licensing issue)

[Kathy Saunders]

Myrna van Lunteren wrote:


For what it's worth, my position is somewhere in the middle. I think
there are some worrying aspects to some of those optimizer-related
regressions. Also, I feel we're still scrambling on 10.2.; still
documentation changes are being worked on...Now that in a way some of
the pressure to release is off, we need to take another look at
changes slated for 10.2.2 and see if there are any that really should
go in to make the first release of 10.2 but we've dropped because of
lack of time.

If we release now, we should focus activities for 10.2.2 with the goal
of making it more robust as well as having the jdbc40 support in.

Myrna


Hi,

To clarify my opinions, here's what I'm concerned about:

1 - If there are quality issues that  anyone thinks we should fix, then 
what are those specific issues?  Advocate to get them on Rick's list to 
fix before a release should happen.  General concerns about quality at 
this point are a problem for me as I don't understand what we are to do 
before we can have a release.  I do believe there are regressions out 
there.  I do believe there are regressions in the optimizer specifically 
because that's difficult code and from other products I've worked on 
when you make significant changes to the optimizer, you almost always 
have other issues pop up, and it's not necessarily easy to get them to 
surface.  But, if you continue to hold up a release because of 
regression concerns, you'll never have one.  In my opinion, it's 
generally time to get this release done, once we have the known 
significant issues resolved.  If we really believe we need more testing, 
then what is that testing and who is going to do it?  Discussion on 
quality is healthy, but at this point in the release process I believe 
we need to be specific about what actions or outcome we need to complete 
the release. 

2 - Regarding the Mustang and JDBC 4 issue, my general opinion is that 
if Mustang is still coming out in October then it may be worth it to 
continue on our current path and do a release that includes JDBC 4.  If 
Mustang is delayed, then I think it's just time to get 10.2 done to get 
some of the other good features out there.  It's been quite a while 
since we've had a feature release.  Does anyone know the current 
schedule for Mustang?


Kathy

Re: 10.2 plans (was Re: 10.2 licensing issue)

[Kathy Saunders]

Andrew McIntyre wrote:


Taking this over to derby-dev...

On 9/11/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:



Many of these regressions sadly have already made their way into 10.1.3
and therefore are being picked up by users for production.  I
think we need to notify the user community of the situation, try to get
more user input on 10.2 and  flush out more regressions.   We port fixes
to 10.1 to try to get it to  a stable state and then release 10.2.  Also
any ideas anyone has for new optimizer tests would be good and folks
could write those.

Those are all my ideas for now.  It could be that lots of users  have
tried 10.2 without problems but haven't reported in and then it is just
a matter of getting them to speak up.



I don't think we should hold up the 10.2 release except for known
regressions. I think it's a chicken-and-egg problem. Users aren't
motivated to try out the beta, because it's extra time and effort on
their part, so you aren't actually informed about regressions until
the regression is in a release that people actually try to use. Better
to release early so new code gets into actual user's hands so
regressions can be flushed out sooner. Regressions happen, and no
release is ever go to be perfect (although that would be nice,
wouldn't it?).
Better to release often so code where regressions have been identified
and fixed get into user's hands sooner.

I think releasing early and often is an area we as a community, and
individually through the tasks we take on for any particular release,
could improve.

andrew

I second Andrew's comments.  Kathey has been a great quality advocate 
for Derby, and I hope will continue to speak up.  But, in this case, I'm 
not sure what decisive action we can take prior to a 10.2 release.  
We've asked the user community to test with some response, but not a 
lot.  The users will only do their testing when they are motivated.  I 
think it's excellent that users were invited to do testing, and I see 
that Kathey posted again asking for more testing, which is great.  
However, unless we have a specific regression or action that needs to be 
taken, I don't believe it makes sense to talk about holding up Derby 
10.2 for quality issues.  Let's get it out there, and if there are 
regressions (in my experience working in technical support for 
commercial products for 15 years, there are always regressions), we can 
get new builds and/or a maintenance release out.  On the other hand, if 
we have any specific quality issues that should be addressed prior to a 
10.2 release, let's talk about those.


Kathy

Re: [jira] Commented: (DERBY-1691) jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6

[Kathy Saunders]

You can also get JCC separately (but it looks like it's version 2.4) by 
going to 
http://www14.software.ibm.com/webapp/download/search.jsp?go=y&rs=cloudscape.  
Look for IBM DB2 JDBC Universal Driver in the list.


Andrew McIntyre wrote:


On 8/17/06, Bryan Pendleton <[EMAIL PROTECTED]> wrote:

>> jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 
2.6


Is there a download site where one can get access to the 2.6 JCC driver?

I think I asked this last spring and at the time there wasn't
one available. It would be nice to be able to run JCC 2.6 tests
myself occasionally.



The Cloudscape installer on the IBM Cloudscape website contains JCC 2.6.

Click "Trials and Demos" at http://www.ibm.com/software/data/cloudscape/

The Java version is the smallest download, while the Windows and Linux
versions also come with IBM JDK 1.4.2 for those platforms.

andrew


.

Re: Proposal for 10.2 release schedule

[Kathy Saunders]

Rick Hillegas wrote:

Thanks, Kathy. I think I'm getting the message that the following 
would be an acceptable and more traditional schedule:


August 10 : Last feature work commits
August 11 : First release candidate generated
August 24 : Second release candidate generated
September 7: Third and hopefully last release candidate generated
September 15: Targetted end of voting on release candidates

Is this a realistic schedule or is it still too aggressive?

Thanks,
-Rick



In my opinion that is a reasonable schedule.  Of course, number of 
release candidates and final dates are dependent on the quality of  the 
code.  But, based on what I've seen with Derby releases so far, this 
timeframe seems like it can work.


Hopefully the licensing issues will be resolved prior to August 10 as well.



Kathy Saunders wrote:


Rick Hillegas wrote:

Thanks, Rajesh. In your scheme, when should feature work on 10.2 
wrap up? I had budgeted 2 weeks between the end of feature work and 
the first release candidate. Is that overkill? Should we propose 
that feature work wraps up by, say, July 27?




Do we need to have a feature wrap up and then time to do  more 
development?  Can't we just say that all planned work--features, bug 
fixes, etc. should be done by August 10?  Then you could post the 
first RC on August 11 or shortly after that. It's true that feature 
check-ins might cause some bugs that need to be dealt with, but those 
can be dealt with in RC2 if need be.


Kathy



Rajesh Kartha wrote:


Rick Hillegas wrote:

Last week, Sun Microsystems announced that it will bundle Derby 
with the next major release of the reference jdk, Java SE 6, also 
known as Mustang or jdk1.6. If you download the latest Mustang 
build, you will see that it contains our Derby 10.2.0.3 snapshot 
in the "db" directory parallel to "lib" and "bin".


This is big news. It means that over the course of the next year, 
Derby will turn up on the desktops of millions of developers. 
Hopefully, Derby's user and developer communities will both grow 
dramatically.


I would like to support this bundling. Note that Mustang will need 
our vetted 10.2 release candidate by September 15 so that they can 
QA it. This is expected to take about 5 weeks, after which Mustang 
should go GA in late October.


The JCP requires that our JDBC4-exposing release can not be 
generally available until the JDBC4 specification is finalized, 
which happens when Mustang is generally available. Until that 
date, this means that our final, vetted release candidate can not 
be officially stamped as "GA"  and we can not promote it to the 
various Apache mirrors.


Here are proposed dates for 10.2 milestones:

August 10 - Feature work committed. 10.2 branch created.
August 24 - Last day to commit changes for 10.2
August 25 - Begin vetting 10.2 release candidate
September 15 - Target date for finishing the voting on Derby 10.2
End of October - Expected GA of JDBC4 with Mustang
End of October - GA of Derby 10.2. Release promoted to Apache 
mirrors.


Are this proposal and its dates reasonable?



Hi Rick,

On careful review of the dates you posted, it looks like the time 
frame for testing is just about 3 weeks (Aug 25 - Sept 15).  10.2 
being a major release with lots
of new features/fixes,  we need to make sure there is enough time 
for the community to test the release and 3 weeks sure seems less.
My experience during all the previous releases of Derby is that  we 
invariably had multiple release candidates - hence the 10.2 testing 
time frame

needs to take this into account.

I suggest one of the following two:

1) Keep the date to complete voting for Derby 10.2 as Sept 15:

  To achieve this,  we move the last day to commit changes early, 
which would mean:August 10 - Last day to commit changes for 10.2

   August 11 - Release Candidate 1 ready for testing
   September 15 - Target date for finishing the voting on Derby 10.2

2)  Push the date to complete voting for Derby 10.2 to Oct 2:
  August 24 - Last day to commit changes for 10.2
   August 25 - Begin vetting 10.2 release candidate
   Oct 2nd - Target date for finishing the voting on Derby 10.2
 This will give us  about 5 weeks in both the cases, within 
which we can provision for RC2 if needed.


Let me know what you think.

Regards,
Rajesh

Re: Proposal for 10.2 release schedule

[Kathy Saunders]

Rick Hillegas wrote:

Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap 
up? I had budgeted 2 weeks between the end of feature work and the 
first release candidate. Is that overkill? Should we propose that 
feature work wraps up by, say, July 27?


Do we need to have a feature wrap up and then time to do  more 
development?  Can't we just say that all planned work--features, bug 
fixes, etc. should be done by August 10?  Then you could post the first 
RC on August 11 or shortly after that. It's true that feature check-ins 
might cause some bugs that need to be dealt with, but those can be dealt 
with in RC2 if need be.


Kathy



Rajesh Kartha wrote:


Rick Hillegas wrote:

Last week, Sun Microsystems announced that it will bundle Derby with 
the next major release of the reference jdk, Java SE 6, also known 
as Mustang or jdk1.6. If you download the latest Mustang build, you 
will see that it contains our Derby 10.2.0.3 snapshot in the "db" 
directory parallel to "lib" and "bin".


This is big news. It means that over the course of the next year, 
Derby will turn up on the desktops of millions of developers. 
Hopefully, Derby's user and developer communities will both grow 
dramatically.


I would like to support this bundling. Note that Mustang will need 
our vetted 10.2 release candidate by September 15 so that they can 
QA it. This is expected to take about 5 weeks, after which Mustang 
should go GA in late October.


The JCP requires that our JDBC4-exposing release can not be 
generally available until the JDBC4 specification is finalized, 
which happens when Mustang is generally available. Until that date, 
this means that our final, vetted release candidate can not be 
officially stamped as "GA"  and we can not promote it to the various 
Apache mirrors.


Here are proposed dates for 10.2 milestones:

August 10 - Feature work committed. 10.2 branch created.
August 24 - Last day to commit changes for 10.2
August 25 - Begin vetting 10.2 release candidate
September 15 - Target date for finishing the voting on Derby 10.2
End of October - Expected GA of JDBC4 with Mustang
End of October - GA of Derby 10.2. Release promoted to Apache mirrors.

Are this proposal and its dates reasonable?



Hi Rick,

On careful review of the dates you posted, it looks like the time 
frame for testing is just about 3 weeks (Aug 25 - Sept 15).  10.2 
being a major release with lots
of new features/fixes,  we need to make sure there is enough time for 
the community to test the release and 3 weeks sure seems less.
My experience during all the previous releases of Derby is that  we 
invariably had multiple release candidates - hence the 10.2 testing 
time frame

needs to take this into account.

I suggest one of the following two:

1) Keep the date to complete voting for Derby 10.2 as Sept 15:

  To achieve this,  we move the last day to commit changes early, 
which would mean:August 10 - Last day to commit changes for 10.2

   August 11 - Release Candidate 1 ready for testing
   September 15 - Target date for finishing the voting on Derby 10.2

2)  Push the date to complete voting for Derby 10.2 to Oct 2:
  August 24 - Last day to commit changes for 10.2
   August 25 - Begin vetting 10.2 release candidate
   Oct 2nd - Target date for finishing the voting on Derby 10.2
 This will give us  about 5 weeks in both the cases, within which 
we can provision for RC2 if needed.


Let me know what you think.

Regards,
Rajesh

Re: New Main class for derbytools.jar

[Kathy Saunders]

Andrew McIntyre wrote:



This sounds reasonable to me. I was a little hasty in wanting to just
get rid of the scripts. Experience has shown that having an example of
how to set the classpath has always been useful, especially for people
who might be new to Java, and it is pretty common to have server start
and stop scripts.

Perhaps we should advertise that the frameworks scripts are deprecated
as of 10.2 and will be removed in 10.3, and provide new scripts in a
bin directory that rely on DERBY_HOME and JAVA_HOME and self-configure
from there, like practically every other Java project at Apache (think
Ant).

Should I formalize that with a vote? Or perhaps the vote to deprecate
the scripts can happen once we have new, better ones.

Now, off to file a JIRA for myself to write some better scripts...

andrew


 

+1 I like this approach.  It should work well for existing customers and 
make it easier for new customers.


Kathy

Re: New Main class for derbytools.jar

[Kathy Saunders]

Daniel John Debrunner wrote:


Kathy Saunders wrote:

 


I agree with Oystein.  I do think there are customers who use these
scripts--they are not just viewed by everyone as sample files.  I also
think that it's very common to have a bin directory that contains
scripts like these.  In particular, I believe that users expect to see a
startserver script or executable in a bin directory.  My opinion is that
we keep the scripts (with appropriate clean up), but move them to a bin
directory under DERBY_HOME where they will be easier to find.
   



Do we need to leave the scripts in the frameworks directory as well?
If we care about backwards compatibility for these then they should
remain where they are.

We may want to look at what useful scripts should be provided in a new
bin directory. Ones that work without the user having to modify them or
run separate setup scripts.

Dan.





 

That's a good question.  I suspect we'll be ok if we move them and still 
have the same commands available, but it would certainly need to be 
documented in the release notes as something that might affect existing 
applications.  But, if we want to be *very* careful we could leave them 
or announce they would be moved (or removed) in a later release.  I've 
seen applications that rely on these scripts, but my take is that they 
would make the adjustment to a bin directory without much fuss.  I think 
that if someone decides to move the scripts, it would be good to post a 
question to the user list.  Some of us who work with existing customers 
could also check.  I could check with some of the Cloudscape customers 
to see what they think.  If someone decides to take ownership of moving 
the scripts and wants me to query my customers, let me know.


Kathy

Re: New Main class for derbytools.jar

[Kathy Saunders]

Myrna van Lunteren wrote:

On 2/22/06, *Øystein Grøvlen* <[EMAIL PROTECTED] 
> wrote:


Andrew McIntyre wrote:

> Great, let's take it one step further. Why don't we remove the
> frameworks directory. Completely. All the scripts there are for
> running the above three classes, and NetworkServerControl, which we
> also recently added the ability to run with -jar. Perhaps we could
> have a top-level bin directory with a simple readme on how to
run the
> tools.

I would think there might be applications that currently depend on
these
scripts.  They would break if the scripts are removed.

--
Øystein


 
It's a point...Although I always thought of the scripts as more of a 
'sample' type file, I would expect a production application to need 
additional things, like their own jars, additional settings and the 
like, and/or have the jars in another place than the derby-home dir as 
indicated by the scripts...
 
Myrna
 
 


I agree with Oystein.  I do think there are customers who use these 
scripts--they are not just viewed by everyone as sample files.  I also 
think that it's very common to have a bin directory that contains 
scripts like these.  In particular, I believe that users expect to see a 
startserver script or executable in a bin directory.  My opinion is that 
we keep the scripts (with appropriate clean up), but move them to a bin 
directory under DERBY_HOME where they will be easier to find.


Kathy

Re: derby bay area lunch

[Kathy Saunders]

I'd be interested in coming if it's open to non-developers :-)

Rick Hillegas wrote:

So far, Jeff, David, and Kathey have rsvd. Anyone else interested?  
Would people prefer a different day?


Thanks,
-Rick

Rick Hillegas wrote:

I'd like to setup a lunch for those of us in the Bay Area who are 
working on Derby. I'm thinking of Wednesday February 1 in San 
Francisco. Any interest?


Thanks,
-Rick

Re: [VOTE] Apache Derby logo

[Kathy Saunders]

David W. Van Couvering wrote:


This is a vote for choosing a logo for Apache Derby.

Rules of engagement:

- Please vote for one and only one logo.

- Respond to both derby-dev and derby-all and put an X to the logo of 
your choice


- Please vote only once.  Multiple votes by the same person will be 
discarded.


- The vote will follow DB project guidelines at 
http://db.apache.org/decisions.html.  Anyone can cast a vote, but only 
committers have binding votes.


- Only entries submitted to the JIRA item DERBY-297 will be considered.

- The list of logos is officially frozen to those on this ballot.  
Logos added later will not be considered in the vote.


- If no logo has more than 50% of the votes, there will be a runoff 
vote of the top three vote getters.


- Voting closes at 12:00 noon Pacific Standard Time (GMT-8) on 
Wednesday, December 7


=

Logo candidates (place an X by your choice).

1. [ ] 
http://issues.apache.org/jira/secure/attachment/12320870/DerbyLogo_Hat_option1.jpg 



2. [ ] 
http://issues.apache.org/jira/secure/attachment/12321016/DerbyLogo_Hat_option2.jpg 



3. [ ]
http://issues.apache.org/jira/secure/attachment/12321017/DerbyLogo_Hat_option3.jpg 



4. [ ]
http://issues.apache.org/jira/secure/attachment/12320873/DerbyLogo_text.jpg 



5. [ ] 
http://issues.apache.org/jira/secure/attachment/12310607/andrew-derbyhat1.jpg 



6. [ ]
http://issues.apache.org/jira/secure/attachment/12310608/andrew-derbyhat2.jpg 



7. [ ]
http://issues.apache.org/jira/secure/attachment/12310614/andrew-derbyknight1.jpg 



8. [ ]
http://issues.apache.org/jira/secure/attachment/12310615/andrew-derbyknight2.jpg 



9. [ ]
http://issues.apache.org/jira/secure/attachment/20155/derby4.jpg

10. [X ] (these all belong together...)
http://issues.apache.org/jira/secure/attachment/12321022/derby_logo_only.jpg 

http://issues.apache.org/jira/secure/attachment/12321023/derby_with_text.jpg 

http://issues.apache.org/jira/secure/attachment/12321055/roger_full_showcase.jpg 



11. [ ]
http://issues.apache.org/jira/secure/attachment/12320752/derbyhatlogo-lettersaligned.png 

Re: Modular build, was: VOTE: Approach for sharing code

[Kathy Saunders]

Daniel John Debrunner wrote:


Kathy Saunders wrote:


 


Thank you very much for the clear explanation.  From a usability
perspective, I would vote for approach 2.  Requiring a classpath to be
in a particular order is always an issue.  However, the saving grace is
that it sounds like the ordering issue only comes up if you mix versions
of the derby.jar and the derbyclient.jar in the same classpath.  I don't
believe most users put the client and engine in the same classpath
(unless there's a new requirement I don't know about), so that
definitely helps.  Requiring classpath in a specific order can easily
lead to complications though, so I'm not in favor of it in general.
   



Derby's client and engine may be in the same classpath and at different
versions if the JVM is hosting more than one application, or the
application installers have modified the system/user's classpath to add
their required jars.

The issue is that today this is fully supported because the client and
engine do not share code.

Some of the code sharing approaches regress Derby in this area by not
supporting this, or require class path ordering for it to be supported.

While it is true that multiple class loaders solve the issue, this
approach is not always possible, I believe, for example, some of the
major application servers do not support different class loaders for
different JDBC providers (eg. the Derby client at 10.3 and engine and 10.2).

Thus the argument really is, are we willing to accept regression in this
area to gain code sharing, or should the code sharing solution not
regress Derby?

Dan.






 

I don't think we should regress and I don't think we should have 
classpath ordering issues (sorry if my rambling mail last time was 
misleading).  I think that means I would vote for option 2 if we proceed 
with code sharing which means no change from a customer 
perspective--same number of jars and no ordering issues.

Re: Modular build, was: VOTE: Approach for sharing code

[Kathy Saunders]

David W. Van Couvering wrote:

Hi, Kathy, thanks for your email.  The timing is actually pretty good, 
I was just talking with Francois trying to understand his concerns 
better.


After quickly describing the two approaches, I'd like to summarize the 
experience/impact of these approaches from the perspectives of the end 
user, the developer/maintainer, and the test developer/runner.


Goal:
 - Reduce code duplication while continuing to support different 
versions of client and embedded driver in the same VM


Approach 1:
 - Create a common package and put all common code there 
(org.apache.derby.common)
 - Use compatibility guidelines to ensure backward compatibility and 
some degree of forward compatibility
 - Common classes are embedded in derby.jar and derby-client.jar 
(based on lots of negative feedback for having a separate jar)


Approach 2:
 - Create a common package and put all common code there 
(org.apache.derby.common)
 - During build process, "clone" all common classes into at least two 
generated packages, one for the engine and one for the network client 
(org.apache.derby.engine.common and org.apache.derby.client.common). 
 - This approach avoids having to implement compatiblity 
guidelines/constraints and guarantees, as the engine and client 
continue to be fully isolated


USER EXPERIENCE

Approach 1
 - No new jar files, everything looks the same
 - For the vast percentage of users who don't mix versions in the same 
VM, everything works great
 - For the small percentage of users who mix versions, the order in 
which jar files are loaded.  For example, if they want to use 
derby-10.2.jar and derby-client-11.0.jar, then if derby-10.2.jar is 
first in the classpath, they will get an exception saying that the 
client code is incompatible with the common code and that they need to 
re-order their jar files, whereas it will work fine if the order is 
reversed.


Approach 2
 - No new jar files, everything looks the same
 - Ordering of jar files does not matter, everything works fine


DEVELOPER EXPERIENCE

Approach 1
 - Pretty much as it is today, nothing surprising

Approach 2
 - When navigating code either during source browsing or debugging, 
they will see the *generated* common code, not the master common code.
 - If a developer is not aware of how things work, or just forgets, 
he/she will try to edit this generated code, and will be confused and 
surprised when his/her changes disappear after a build
 - Stack traces will point to generated code, and the developer will 
have to remember to translate that back to the master version.
 - The generation process must be very careful not to adjust line 
numbers or all stack traces will be off and misleading.  This means 
for instance we can't add comments saying "THIS IS GENERATED CODE, DO 
NOT EDIT"
 - We may need to generate more copies if different types of version 
mixing are required (e.g. if the tools.jar and derby.jar need to be at 
different versions)



TESTER EXPERIENCE
Approach 1
 - We would have to build and run compatibility tests to make sure 
that compatible versions run correctly and incompatible ones correcty 
raise the exception


Approach 2
 - No real change, although debugging of tests may be confusing due to 
issues I already listed under developer experience



I also am uncomfortable with the "twistiness" of approach 2.  There is 
something to be said for a clean architecture and build environment.  
I have seen time and again that a good architecture allows you to 
scale and grow, whereas "twisty" architectures tend to wrap you up and 
tie you down at some point.  I think this has to be taken into 
consideration.


My main question is: is it OK to sometimes throw an exception for the 
small set of users who mix versions, and for them to then have to 
rearrange their jar ordering.  If the answer is that this is not 
acceptable and would be considered a showstopper regression for some 
part of our user base, then I think we have no choice but to go with 
Approach 2, even if we do risk painting ourselves into an 
architectural corner.  Otherwise, it is my strong recommendation to go 
with Approach 1.


Thanks!

David


Hi David,

Thank you very much for the clear explanation.  From a usability 
perspective, I would vote for approach 2.  Requiring a classpath to be 
in a particular order is always an issue.  However, the saving grace is 
that it sounds like the ordering issue only comes up if you mix versions 
of the derby.jar and the derbyclient.jar in the same classpath.  I don't 
believe most users put the client and engine in the same classpath 
(unless there's a new requirement I don't know about), so that 
definitely helps.  Requiring classpath in a specific order can easily 
lead to complications though, so I'm not in favor of it in general. 

Re: Modular build, was: VOTE: Approach for sharing code

[Kathy Saunders]

Jeremy Boynes wrote:


Kathy Saunders wrote:









I'm a bit concerned because I see a lot of discussion about what is 
good from a derby development perspective, but not so much how these 
changes may affect users of Derby.  Although some Derby users have 
complex applications (like application servers), many are 
implementing much more simple solutions.



I would argue that we are actually making life easier for people 
implementing simple solutions. To me, a simple environment does not 
need to cater for multiple versions being concurrently loaded or for 
multi-classloader operation; it also means being able to select just 
the functionality you need without having to worry about which jar 
file a class may have come from.


I think for that environment, just adding the component jars to the 
classpath (without any concern for ordering) is reasonable.


To make things even simpler, it has also been proposed that we bundle 
all components together into one jar (containing everything, client 
and server). This gives you less flexibility and a larger footprint 
but is a really simple solution.




I have to say that I don't see how adding more jar files to figure out 
whether you need to deploy and add to your classpath makes things easier 
for the simple case.  And, so far, I don't see what our users would 
reasonably be able to  pick and choose--what would they be able to leave 
out of our database engine other than how the jar files are already 
separated (embedded, network server, tools...)?  Unless I'm missing 
something, David is currently working on internationalizing error 
messages.  Would it really make sense to tell someone they may not need 
that functionality? Will they be able to get error messages for network 
server without having those classes in their classpath? I could imagine 
scenarios in the future where there may be significant pieces of 
functionality that we would want to separate because not everyone 
wants/needs that functionality and it would significantly add to 
footprint, but I can't think of anything in that category that currently 
exists other than what we already have.  For example, we do have a 
separate jar file for tools.


Footprint is an interesting argument, but will we really see any 
significant differences there yet?  Strictly looking at this from a 
usability perspective, I still believe that having a common.jar file 
which has no real meaning to a Derby user (since I believe you'll always 
need in the network server case at this point), so why have them keep 
track of yet another jar file?


If we do have a separate jar file for these classes, I believe that it 
should only be one at this point and classpath order should not matter.  
Again, I'm not saying there may not be a need for more jar files in the 
future.  I'm only looking at what I believe is proposed right now.




In addition, I work on Derby now in the testing area, so I'd also 
like to understand the implications for what additional testing might 
need to be done.  If we create more jar files, is there more testing 
requirements for different combinations?




I don't think there are any more combinations - in fact probably less 
as you would not need to test all possible classpath orderings. We are 
dealing with the same amount of code, just modularizing its structure.


By modularizing the build we also allow for in-depth testing on each 
individual component in isolation. With a clear definition of the API 
contract for each component and testing (unit, functional, 
compatibility) of that contract we can perform more thorough testing 
on each one before integrating into a whole. Integration and system 
testing can focus on the interfaces between components rather than on 
the entire black box.


Add in too that modularization makes it easier for users and 
developers to come up to speed with the design and implementation of 
that component. More eyes on the code with comprehensible component 
leads to better review and higher quality.


Finally, you can see this pattern at work with many open source 
projects: a common core and then a very modular structure that allows 
people to participate at the component level. Examples of projects 
with this type of structure are:

* Apache HTTPD + mod_*
* Apache Maven + plugins
* Eclipse + plugins
* Apache Jakarta/Tomcat + Commons
and many more.

--
Jeremy





Thanks for your perspective on the testing issue.

Kathy

Re: Modular build, was: VOTE: Approach for sharing code

[Kathy Saunders]

David W. Van Couvering wrote:


Well, we're at a bit of a standoff here.  What I'm looking for is a
nail-in-the-coffin data point that would move us in one direction or
the other.


I've been following this discussion with some interest as my background 
is technical support.  In fact, I supported Cloudscape for the first 4 
years (from release 1.0 of Cloudscape).  My experience is that 
developers (particularly Java developers) really liked Cloudscape (now 
Derby) because it was so easy to use and deploy.  And, I found 
historically that one of the most common issues to come up were 
classpath issues (in particular we got in trouble a few times when we 
introduced something that caused the order of the jar files to be 
important).  You should note that I'm not, and never have been, a Derby 
developer, so I don't claim to be an expert on what's correct and best 
from a development perspective.


I'm a bit concerned because I see a lot of discussion about what is good 
from a derby development perspective, but not so much how these changes 
may affect users of Derby.  Although some Derby users have complex 
applications (like application servers), many are implementing much more 
simple solutions. 

Having said that, I'm a bit lost in what is being proposed from the 
user/functional perspective.  David, as soon as you have a more concrete 
proposal (may not be the time yet), can you post that information?  
Could you  provide information on what the users of Derby will have to 
do with this change (how would our documentation need to be changed) and 
maybe footprint, performance, etc. impacts vs. the benefits  from making 
this change.  I'd like to be able to provide my input from a 
usability/documentation perspective.


In addition, I work on Derby now in the testing area, so I'd also like 
to understand the implications for what additional testing might need to 
be done.  If we create more jar files, is there more testing 
requirements for different combinations?


Thanks,
Kathy

Re: boolean type

[Kathy Saunders]

Lance J. Andersen wrote:

IMHO do not think that is a good idea.  Derby is now open source so if 
you add a switch for DB2, you will then need to do the same to have it 
behave as Sybase, Oracle, MySQL etc...


This datatype is part of the ansi stanard so it should be part of  the 
supported data types.


Rick Hillegas wrote:

As I dig into this issue, it has become apparent that the BOOLEAN 
datatype was removed so that Derby would be compatible with DB2. The 
regression test lang/db2Compatibility.sql monitors this behavior.


The IBM folks clearly invested a fair amount of effort in building a 
DB2-compatible Derby. I don't want to simply undo that work. Would it 
be reasonable to introduce a startup property which causes Derby to 
operate in a DB2-compatible mode? The default for this property would 
be false, but it might be useful for developers who want to use Derby 
as a baby DB2.


-Rick

Rick Hillegas wrote:

I have assigned this issue (bug 499) to myself. I plan to do the 
following:


1) Re-enable the BOOLEAN datatype by removing the parser short-circuit.

2) Re-enable the TRUE and FALSE literals.

3) Add appropriate unit tests.

Cheers,
-Rick




Hi,

Dan is on vacation and can't give you the history, so I guess I'll give 
you my own opinions.  It is true that IBM did disable some features to 
make Cloudscape DB2 compatible.  This work was done before the decision 
was made to contribute the code as open source.  When Derby was created, 
a charter was written (see 
http://db.apache.org/derby/#Derby+Project+Charter) that talks about 
being a standards-based database and making it easy to migrate to other 
databases if a user chooses.  So, I think it is reasonable to re-enable 
a feature like BOOLEAN if it's part of the standard (and this one 
clearly is).  I actually agree with Lance that a switch for DB2 (and 
other databases) is not a good idea, but thanks for the thought :-) 

I would suggest since this is a feature, that you put it out for an 
official vote and see what happens. 


Regards,
Kathy

[jira] Commented: (DERBY-382) Doc Review: Derby Reference Manual

[Kathy Saunders (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-382?page=comments#action_12314636 ] 

Kathy Saunders commented on DERBY-382:
--

I reviewed functions. data types and expressions.  All of my comments refer to 
the page numbers on a printed version of the PDF.

Page 72: 
Keep the list of built-in fuctions in alphabetical order to match the later 
writeups.  So, LENGTH should be moved.

Concatenation and CASE expressions are not functions.  The correct place is 
probably expressions.

Change CURRENT_DATE to CURRENT_DATE or CURRENT DATE

Add CURRENT SCHEMA to the list

Change CURRENT_TIME to CURRENT_TIME or CURRENT TIME

Change CURRENT_TIMESTAMP to CURRENT_TIMESTAMP or CURRENT TIMESTAMP

Page 73: 

The aggregates section has been mixed in with the functions section. They 
should be seprate.  So, there should be a section called Built-in funtions with 
the list that is on page 72 and 73, followed by all of the writeups on each 
function.  Then, you should have a separate section called aggregates with the 
overview on that, followed by the individual writeups on each aggregate.

The table on page 73 has characters in cells that should be blank.

Page 74: Move AVG writeup to aggregate section

Page 81: Move COUNT writeup to aggregate section

Page 82: Move COUNT(*) writeup to aggregate section.

Page 90: Move MAX writeup to aggregate section.

Page 91: Move MIN writeup to aggregate section.

Page 95: Move SUM writeup to aggregate section.

Page 99: Change the paragraph under Buil-In system procedures to something like 
the following:

Some built-in procedures are not compatible with standard SQL syntax use by 
other relational databases.  These procedures can only be used with Derby.

Page 109:

Put the list in alphabetical order to match the writeups.  So, CHAR FOR BIT 
DATA, VARCHAR FOR BIT DATA, LONG VARCHAR FOR BIT DATA are out of order

Add BLOB, CLOB and VARCHAR to the list of data types.

Change DOUBLE PRECISION to be DOUBLE PRECISION or DOUBLE

Page 127: Table needs cleaning up


> Doc Review: Derby Reference Manual
> --
>
>  Key: DERBY-382
>  URL: http://issues.apache.org/jira/browse/DERBY-382
>  Project: Derby
> Type: Improvement
>   Components: Documentation
>  Environment: all
> Reporter: Jeff Levitt
> Priority: Minor
>  Fix For: 10.1.1.0

>
> This issue tracks comments for the Derby Reference Manual. The deadline for 
> posting comments is Tuesday, June 28, noon Pacific time.
> Some guidelines to follow when posting comments to this issue are:
> - Try to make clear and concise comments about what you want changed whenever 
> possible.  Provide concrete comments that say "Please change  to 
> " instead of generic comments like "This section needs to be 
> rewritten."
> - If you're reviewing the HTML Files copy, include the URL for the page in 
> the review comment. Obtain the URL like this:
> * highlight the topic in the left frame
> * right click
> * choose "Properties"
> * copy and paste the address in the pop up box.
> - If you're reviewing the PDF copy, in the review comment:
> * Include the page number for the PDF, and indicate whether the number is 
> the PDF sheet number or the printed page number.
> * Include the title of the section that the problem occurs in. If it's in 
> a subsection, try to include the hierarchy of titles.
> - Please don't review the HTML Book copy -- it'll be time consuming to match 
> up that copy with the underlying DITA source.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-381) Doc review: Derby Server and Admin Guide

[Kathy Saunders (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-381?page=comments#action_12314251 ] 

Kathy Saunders commented on DERBY-381:
--

I reviewed the Administration section of the Server and Admin Guide and have 
the following comment:

On page 47 (sheet #) of the PDF doc, under Backing Up a database then Using the 
backup procedure, it says:

The SYSCS_UTIL.SYSCS_BACKUP_DATABASE() procedure locks the database and 
performs the copy operation.  

We need to be more specific about what locking the database means.  Maybe 
something like:

...procedure locks the database so that any connection trying to write to the 
database will be frozen until the backup completes.  Database reads can 
continue while the backup is running.



> Doc review: Derby Server and Admin Guide
> 
>
>  Key: DERBY-381
>  URL: http://issues.apache.org/jira/browse/DERBY-381
>  Project: Derby
> Type: Improvement
>   Components: Documentation
>  Environment: all
> Reporter: Jeff Levitt
> Priority: Minor
>  Fix For: 10.1.1.0

>
> This issue tracks comments for the Derby Server and Administration Guide. The 
> deadline for posting comments is Tuesday, June 28, noon Pacific time.
> Some guidelines to follow when posting comments to this issue are:
> - Try to make clear and concise comments about what you want changed whenever 
> possible.  Provide concrete comments that say "Please change  to 
> " instead of generic comments like "This section needs to be 
> rewritten."
> - If you're reviewing the HTML Files copy, include the URL for the page in 
> the review comment. Obtain the URL like this:
> * highlight the topic in the left frame
> * right click
> * choose "Properties"
> * copy and paste the address in the pop up box.
> - If you're reviewing the PDF copy, in the review comment:
> * Include the page number for the PDF, and indicate whether the number is 
> the PDF sheet number or the printed page number.
> * Include the title of the section that the problem occurs in. If it's in 
> a subsection, try to include the hierarchy of titles.
> - Please don't review the HTML Book copy -- it'll be time consuming to match 
> up that copy with the underlying DITA source.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-386) Create new backup examples in the Server Guide that are not Windows NT

[Kathy Saunders (JIRA)]

Create new backup examples in the Server Guide that are not Windows NT
--

 Key: DERBY-386
 URL: http://issues.apache.org/jira/browse/DERBY-386
 Project: Derby
Type: Improvement
  Components: Documentation  
Versions: 10.1.1.0
Reporter: Kathy Saunders
Priority: Minor


The section on backups in the Derby Server and Administration Guide provides 
several Windows NT examples for performing offline backups and using the freeze 
and unfreeze methods.  These examples should be changed to another operating 
system as Microsoft has announced end of support for NT (see 
http://www.microsoft.com/technet/archive/winntas/ntendlife.mspx).  Perhaps 
Linux examples would be better here.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: PLEASE RESPOND: RSVP for Derby lunch during JavaOne

[Kathy Saunders]

Hi David,

I would like to attend.

Regards,
Kathy Saunders

David Van Couvering wrote:

Hi, all.  I suspect my request for RSVP may have been lost in the high 
volume of email on this list, so I thought I would try a more 
attention-getting subject.


So far I have confirmed for our lunch at noon on Tuesday June 28 in 
San Francisco the following derby-devvers:


Dag Wanvik
David Van Couvering
Francois Orsini
Jeff Lichtman
Kathey Marsden
Lance Andersen
Olav Sandstaa
Rick Cattell
Rick Hillegas

I would like to make restaurant reservations soon, so please RSVP as 
soon as you can if you are planning on coming.  I'll make the final 
tally at EOB Wednesday.


Hope to see you there!

Thanks,

David

Re: [RESULT] [VOTE] accept derby client contribution

[Kathy Saunders]

Satheesh Bandaram wrote:
Passed, with nine +1 votes and no -1 vote. However, Derby client checkin
into trunk may get delayed, pending resolution of CCLA discussion,
initialied by Geir:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL 
PROTECTED]
Follow up questions from Ken and Dan are pending still:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL 
PROTECTED]
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL 
PROTECTED]
Satheesh
 

Hi,
IBM faxed an amended CCLA, which includes the contribution of the Derby 
client, to Apache this morning.

Kathy

Re: Availability of Derby client ...

[Kathy Saunders]

[EMAIL PROTECTED] wrote:
Satheesh Bandaram <[EMAIL PROTECTED]> wrote on 14/04/2005 08:34:32 AM:
 

As Kathy Saunders announced in February, IBM is contributing 
attached Derby client to Apache Derby project. Derby client is a 
type 4 JDBC client driver that is designed to work with Derby Network 
   

Server.
 


Can someone from IBM tell us what the status of the DB2 Universal Driver 
is with future versions of Cloudscape.  Is it being replaced by the Derby 
Client?

The reason I ask is that in the past an application that could be used 
with Derby or Cloudscape 10 may have documented how to configure/use the 
DB2 Universal Driver.  Should this documentation be changed to refer to 
the Derby client, or will future versions of Cloudscape continue to use 
the IBM DB2 Universal Driver for some reason and therefore we need to 
document both?

Thanks,
John
 

Hi,
It's currently my intention to continue supporting the DB2 Universal 
Driver for use with Derby (and Cloudscape) version 10.0.  But, IBM will 
most likely move to the Derby client for Cloudscape in the future, and 
my vote would be that Derby uses the new client as well.  If the Derby 
community votes to accept the new Derby client and it becomes part of 
the next release, I will probably only leave the existing  DB2 Universal 
Driver available on the IBM developerWorks Cloudscape site for download 
for a while (for use with Derby 10.0); however, it will continue to be 
available as part of the DB2 product. 

If the new client is adopted by Derby, then it seems to me the 
documentation should be changed for the next Derby release.

I won't make any final decisions regarding Cloudscape until Apache Derby 
has decided what to do.

Kathy
(In case anyone is wondering, I'm the release manager for IBM Cloudscape)

Re: Status of the New Client network JDBC driver

[Kathy Saunders]

Jean T. Anderson wrote:
Wow -- you're right! It's already April in most time zones. I don't 
know what the proposed contribution date will be, but I do know it's 
moving along well. Kathy Saunders is on vacation until next week and 
can post specifics when she's back.

 -jean
Lance J. Andersen wrote:
I was wondering if there is any update to when the New Client JDBC 
driver will be added to the derby workspace?  Last I had heard it was 
to be march.

Regards
Lance


As Jean says, the proposed client code contribution is moving along 
well, but it's not quite there yet.  I estimate that the contribution is 
about 1 to 2 weeks from now.  I'll let you know if that changes.

Regards,
Kathy

Re: JDBC driver for Derby network server mode?

[Kathy Saunders]

Kathy Saunders wrote:

It would seem to be in the best interests of Apache.org, IBM and 
potential users.

I agree.  It's up to the ASF and users to lobby IBM to do the Right 
Thing (tm)(sm)(R)

geir
I am looking into what can be done on the IBM side, but I don't 
guarantee an immediate resolution.  I'll keep everyone informed on any 
progress :-)

Kathy

Hi,
IBM would like to contribute a client JDBC driver to the Apache Derby 
project.  If all goes according to plan, we hope to have the 
contribution available for Apache Derby around March 2005.

Kathy

Educational grants for Derby

[Kathy Saunders]

I recently came across the following program which may be of interest to 
some of you.  Although the email talks about Eclipse, if you go to the 
web site, you will see that they are including Derby in this grant 
program.  Here's the email I saw:

IBM is pleased to announce the IBM Innovation Grant program for 2005, 
with a broadened focus which includes topics related to run-time 
environments that can be targeted by Eclipse-based tools. Particularly 
encouraged are proposals that feature innovations in teaching, research 
or community building around Eclipse, Apache Derby open-source 
relational database management system, Autonomic Computing technologies, 
Scalability and Availability technologies, the Unstructured Information 
Management Architecture, and scripting environments such as PHP, Perl, 
and Python. Awards are valued in the range of US$10,000 to US$30,000 
each. Qualified faculty and researchers should submit proposals via the 
IBM Innovation Grants web site.

Key dates:
October 25, 2004: Online submission opens.
November 12, 2004: Evaluation begins for proposals submitted by this date.
November 26, 2004: Deadline for initiating a proposal.
December 2, 2004: Online submission closes at 11:59 p.m. Eastern Time. 
E-mail requests or proposals received after this date will be rejected.
January 2005: Award winners will be notified via e-mail and postal mail.

For full details, please visit:
http://www.developer.ibm.com/university/scholars/innovation.html
Kathy

[jira] Closed: (DERBY-53) Update Derby doco regarding free DB2 Universal Driver license restrictions

[Kathy Saunders (JIRA)]

 [ http://nagoya.apache.org/jira/browse/DERBY-53?page=history ]
 
Kathy Saunders closed DERBY-53:
---

 Assign To: Kathy Saunders
Resolution: Invalid

The license is not restricted to personal and home computers so the 
documentation does not need to be updated.

> Update Derby doco regarding free DB2 Universal Driver license restrictions
> --
>
>  Key: DERBY-53
>  URL: http://nagoya.apache.org/jira/browse/DERBY-53
>  Project: Derby
> Type: Task
>   Components: Documentation
> Reporter: John Sisson
> Assignee: Kathy Saunders
> Priority: Minor

>
> In a number of places, the Derby documentation points users to the IBM DB2 
> JDBC Universal Driver and in a number of places uses the words "free 
> download".  
> It is true that the "download" is free, but what is not obvious on the Derby 
> or IBM web pages is that the free license for the IBM DB2 JDBC Universal 
> Driver (downloaded via the links in the Derby documentation) restricts use to 
> a Home/Portable Computer (refer to the Lic_en.txt file that accompanies the 
> driver).
> ** This rules out use of the driver (without paying a license fee to IBM) on 
> servers or on your company desktop. **
> I suggest that the Derby documentation be updated wherever it provides a link 
> to the IBM DB2 JDBC Universal Driver, to mention that the license 
> accompanying the free download has some usage restrictions.
> Some of the pages that reference the driver are:
> http://incubator.apache.org/derby/manuals/admin/hubprnt09.html
> http://incubator.apache.org/derby/derby_resources.html
> http://incubator.apache.org/derby/manuals/getstart/gspr36.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-53) Update Derby doco regarding free DB2 Universal Driver license restrictions

[Kathy Saunders (JIRA)]

 [ http://nagoya.apache.org/jira/browse/DERBY-53?page=comments#action_54992 
]
 
Kathy Saunders commented on DERBY-53:
-

The intention of the license file that comes with the DB2 Universal JDBC Driver 
is not to restrict use to a personal or home computer, but to allow you to use 
it on a personal or home computer.  Here is the text from the license file:

Authorization for Use on Home/Portable Computer:  1

EXPLANATIONS OF TERMS:

Authorization for Use on Home/Portable Computer:
"1" means that the Program may be stored on the primary machine and another 
machine, provided that the Program is not in active use on both machines at the 
same time.
"2" means that You may not copy and use this Program on another computer 
without paying additional license fees.

This is actually standard IBM text and either option 1 or 2 is chosen.  Option 
1 is less restrictive than option 2.  Also, there is text in the license file 
that allows you to redistribute the software as you like, provided you meet 
some requirements to provide the files "as is" etc.  If you are still concerned 
about the terms from a legal perspect, let's discuss this on the derby user's 
list.  I'll be happy to get clarification from the IBM attorney.  --Kathy

> Update Derby doco regarding free DB2 Universal Driver license restrictions
> --
>
>  Key: DERBY-53
>  URL: http://nagoya.apache.org/jira/browse/DERBY-53
>  Project: Derby
> Type: Task
>   Components: Documentation
> Reporter: John Sisson
> Priority: Minor

>
> In a number of places, the Derby documentation points users to the IBM DB2 
> JDBC Universal Driver and in a number of places uses the words "free 
> download".  
> It is true that the "download" is free, but what is not obvious on the Derby 
> or IBM web pages is that the free license for the IBM DB2 JDBC Universal 
> Driver (downloaded via the links in the Derby documentation) restricts use to 
> a Home/Portable Computer (refer to the Lic_en.txt file that accompanies the 
> driver).
> ** This rules out use of the driver (without paying a license fee to IBM) on 
> servers or on your company desktop. **
> I suggest that the Derby documentation be updated wherever it provides a link 
> to the IBM DB2 JDBC Universal Driver, to mention that the license 
> accompanying the free download has some usage restrictions.
> Some of the pages that reference the driver are:
> http://incubator.apache.org/derby/manuals/admin/hubprnt09.html
> http://incubator.apache.org/derby/derby_resources.html
> http://incubator.apache.org/derby/manuals/getstart/gspr36.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1) Can't create a new db on OS X

[Kathy Saunders (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1?page=comments#action_54632 ]
 
Kathy Saunders commented on DERBY-1:


Mario,

derby.properties must be placed in derby.system.home.  By default 
derby.system.home is your current directory when you start Derby.  You can read 
more about how to explicitly set derby.system.home to a directory of your 
choice in the Tuning Guide at 
http://incubator.apache.org/derby/manuals/tuning/perf14.html#HDRSII-SETPROP-16827.

> Can't create a new db on OS X
> -
>
>  Key: DERBY-1
>  URL: http://issues.apache.org/jira/browse/DERBY-1
>  Project: Derby
> Type: Bug
> Versions: 10.0.2.0
>  Environment: OS X 10.3.5, Java 1.4.2_05, Dual G5
> Reporter: Tom Santos

>
> This problem does not occur when I use the same jars on Linux.
> I am unable to create a new database in ij by using the following command:
> connect 'jdbc:derby:testdb;create=true';
> I get the following output:
> ERROR XJ041: Failed to create database 'testdb', see the next exception for 
> details.
> ERROR XBM01: Startup failed due to an exception, see next exception for 
> details.
> ERROR XJ001: Java exception: 
> '/Users/tom/dev/java/derby-bin/lib/testdb/log/log1.dat (File exists): 
> java.io.FileNotFoundException'.
> All users have write permissions to the directory so it's not getting blocked 
> there.  I'm not sure what's going on.  I've included the contents of 
> derby.log below.  I've also included the result of running sysinfo on my 
> machine below that.
> 
> 2004-09-24 20:33:53.762 GMT:
>  Booting Derby version IBM Corp. - Apache Derby - 10.0.2.0 - (30301): 
> instance c013800d-00ff-3226-5601-0015bd70
> on database directory /Users/tom/dev/java/derby-bin/lib/testdb 
> 2004-09-24 20:33:53.821 GMT:
> Shutting down instance c013800d-00ff-3226-5601-0015bd70
> 
> 2004-09-24 20:33:53.837 GMT Thread[main,5,main] Cleanup action starting
> ERROR XBM01: Startup failed due to an exception, see next exception for 
> details.
> at 
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
> at 
> org.apache.derby.iapi.services.monitor.Monitor.exceptionStartingModule(Monitor.java)
> at org.apache.derby.impl.store.raw.log.LogToFile.boot(LogToFile.java)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java)
> at 
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java)
> at 
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java)
> at 
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory(BaseDataFileFactory.java)
> at 
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFactory(BaseDataFileFactory.java)
> at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java)
> at 
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java)
> at 
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java)
> at 
> org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java)
> at 
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java)
> at 
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java)
> at 
> org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java)
> at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java)
> at 
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.createPersistentService(BaseMonitor.java)
> at 
> org.apache.derby.iapi.services.monitor.Monitor.createPersistentService(Monitor.java)
>  

Re: JDBC driver for Derby network server mode?

[Kathy Saunders]

It would seem to be in the best interests of Apache.org, IBM and 
potential users.

I agree.  It's up to the ASF and users to lobby IBM to do the Right 
Thing (tm)(sm)(R)

geir
I am looking into what can be done on the IBM side, but I don't 
guarantee an immediate resolution.  I'll keep everyone informed on any 
progress :-)

Kathy

Re: JDBC driver for Derby network server mode?

[Kathy Saunders]

Dick Applebaum wrote:
Does this mean that Apache can/will include the driver in the Derby 
distro --kind of a pita to have to go 2 places to assemble a runnable 
Derby

Dick
Apache can include the driver in the Derby distrobution (I believe there 
are some license requirements to do so.  If the Derby community wants to 
do that,  it should be OK.I don't know what Apache's general policy 
is on inlcuding non-open source in one if its releases.  I do know that 
Apache often points to other sites to obtain free software.

Kathy

Re: JDBC driver for Derby network server mode?

[Kathy Saunders]

Will the license also allow for redistribution?
--
Jeremy
I just wanted to let everyone know that the JDBC driver for the network 
server mode has been refreshed at  
http://www.ibm.com/developerworks/db2/downloads/jcc/.  The only change 
is that the license now allows redistribution of the driver. 

Thanks,
Kathy

Re: SQL/DDL Limitations (and DB2)

[Kathy Saunders]

In my opinion Derby should make decisions based on what is the best 
thing for the Derby project, not just how it works with DB2.  The 
proposal for submitting Derby to Apache at 
http://incubator.apache.org/derby/derby_proposal.html talks about 
promoting a standards-based, database-agnostic approach to application 
development.  I believe that we should be sure changes we make adhere to 
standards.  So, I believe that you should go ahead and submit the 
"patch".  As it changes functionality, I see it more of an enhancement 
which may require a vote, but I'm still learning about the process.

Having said that, you should note that the decision was made to make 
Cloudscape DB2 compatible prior to IBM's decision to contribute the code 
to Apache.  Much of this work was done before the Apache decision was 
made.  There may be places where reasonable adjustments can be made 
within standards guidelines, assuming the Derby community agrees.  I 
personally believe that we should maintain general compatibility with 
enterprise databases, including Oracle, Sybase, Informix, DB2 etc,. 
where possible.  The standards position should help.  I agree with Jason 
that transition flags would be a painful way to go.

Kathy
Jason Rimmer wrote:
While a reasonable suggestion on its face adoption puts Derby on a 
slippery slope.  Why favor DB2?  Why not add transition flags for any 
'enterprise-class' database such as PostgreSQL, Oracle, Sybase, 
Informix, and what the heck SQL Server, MySQL, and Firebird as well? 
The tracking of versions and capabilities alone introduces maintenance 
issues of the most enjoyable variety.
No, Derby should be its own database.  Better yet, if the 
developer base so determines Derby could be an 'enterprise-class' 
database rivaling any previously listed.  I don't see where political 
sensitivity even enters the equation.  While I certainly appreciate 
and am grateful for IBM's contribution of Derby's original source, in 
order for the project to flourish it will have to determine a destiny 
of its own. (Though I understand that such a determination could lead 
to the maintenance of these DB2 compatibility flags).
If you love it, set it free.

Joel Rosi-Schwartz wrote:
I am just guessing that IBM would be less than overjoyed if Derby 
lost its ability to be an easy migration path to DB2. Would it not be 
fairly reasonable, however, to fulfil both requirements. At database 
creation time a flag could be set to dictate DB2 mode or extended 
mode. The database could then set an immutable database level 
property and behave accordingly. True this would introduce some 
complexity into the system, but it would be politically sensitive 
while still achieving better functionality.

- joel

Re: IBM DB2 JDBC Universal Driver now available

[Kathy Saunders]

Kathy
Thanks for clarifying the redistribution issue - that goes a long way 
to help. However, there may be a few people who don't wish to or may 
be unable to redistribute it - the ASF is likely to be one of those.

Is there anything (e.g. IP constraints on the protocol) that would 
hinder the independent development of a alternative, open source, 
network driver?

--
Jeremy

Hi Jeremy,
I certainly understand that an open source solution is preferable.  By 
all means, someone can develop an alternative, open source, network 
driver.  The Network Server is open source and speaks DRDA.  So, someone 
can certainly develop an open source driver to talk to the network 
server.  Or, someone could pursue another solution completely if the 
community agrees that's best.  If you or someone else is interested, I 
suggest you make a proposal on the dev mail list about how to proceed.  
There are members of the community who are familiar with DRDA if you 
need information on that route.

Kathy

Re: IBM DB2 JDBC Universal Driver now available

[Kathy Saunders]

Ben Walding wrote:
Is it planned that the JDBC driver (+ source code) will be under the
same licence (ASL2) as the main Derby codebase?
Cheers,
Ben
 

 

The Derby project provides an embedded JDBC driver as part of the Derby 
codebase under ASL2 license.  The network JDBC driver  is the DB2 
Universal JDBC driver and is part of the DB2 product family.  At this 
time, IBM has no plans to provide the DB2 JDBC driver under the AS2 
license.  However, you are welcome to download it from the IBM site as a 
binary pacakge and use it as you choose.  Within the next 4-6 weeks, IBM 
will add terms to the license so you will be able to redistribute it 
without charge. 

Kathy

Re: JDBC driver for Derby network server mode?

[Kathy Saunders]

Kathy Saunders wrote:

Will the license also allow for redistribution?
--
Jeremy

The license will be a standard non-warranted IBM license.  There are 
no restrictions on redistribution.

Kathy

I spoke to soon regarding the license for the network server JDBC 
driver.  It is available now for download as Susan mentioned in her 
post.  However, the current license does not allow for redistribution.  
IBM does intend to allow you to redistribute the JDBC driver.  I am 
working on new licensing terms now, but it will probably take 6 weeks or 
so to get through legal, translation, etc.  For now, feel free to work 
with the driver on your own machine.  I will post again when the license 
has been updated.

Kathy

Re: JDBC driver for Derby network server mode?

[Kathy Saunders]

Jeremy Boynes wrote:
Daniel John Debrunner wrote:
The standalone download will have a licence that enables unlimited use
by Derby users for connections to the Derby network server.
Will the license also allow for redistribution?
--
Jeremy

The license will be a standard non-warranted IBM license.  There are no 
restrictions on redistribution.

Kathy