db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Tarter (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2376) Patch available to make .classpath entries portable - relative to ECLIPSE_HOME
Date Tue, 06 Mar 2007 19:06:24 GMT

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

Aaron Tarter commented on DERBY-2376:
-------------------------------------

Thanks for your comments Army:
I made the source changes that you recommended.  Now, to answer your question - your assumption
is correct that the absolute path *always* starts with the expanded form of  the variable.
 It would never start with anything else in the current implementation.  There is no chance
that the existing users of the Derby UI plugin will see altered behavior.

> Patch available to make .classpath entries portable - relative to ECLIPSE_HOME
> ------------------------------------------------------------------------------
>
>                 Key: DERBY-2376
>                 URL: https://issues.apache.org/jira/browse/DERBY-2376
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Eclipse Plug-in
>    Affects Versions: 10.2.2.0
>         Environment: any with eclipse
>            Reporter: Aaron Tarter
>             Fix For: 10.2.2.1
>
>         Attachments: DerbyUtils.diff, DerbyUtils.diff
>
>
> This patch modifies the DerbyUtils class to add variable entries relative to ECLIPSE_HOME
as described in the comments below, so that eclipse projects with Derby Nature can be committed
to an SCM without causing build path errors. I did not think any of the derby functional tests
were applicable to this ui action, so I manually tested the code by trying the following:
> 1) Adding Derby Nature to a java project
> 2) Starting and stopping a database with the derby nature
> 3) Removing the Derby Nature from a java project
> The code modification is only required on the add and not on the remove since the current
remove looks for any entry that ends with the correct JAR names.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message