Sharing Eclipse Preferences Across Multiple Eclipse Installation with Oomph

Introduction

Eclipse is an excellent Java programming IDE tool. There are many pre-configured installation packages that allow us to work on specify project requirements. As time passes by, I end up with many installations of Eclipse of various versions.

Eclipse has the capability to safe disk space by enabling the plugin sharing features. But this is good only if all the Eclipse installations are the same version. Sharing plugins across different versions of Eclipse will cause conflicts as one plugin might work in one version but not in the other.

All my Eclispse installation is standalone because I do not want to share the plugins. But I do want to share some preferences, such as text editor colors. For example, if I change the syntax colors of the Javascript Editor in one of the Eclipse installation, I want the changes to be applied to the other Eclipse installation as well. For this, Oomph is a handy tool.

Capturing the Preferences

First you need to capture the preferences that you want to apply to other installations. Go to Preferences->Oomph->Setup Tasks

Check the checkboxes "Show toolbar contributions" and "Show progress in setup wizard".

The following will be added to the toolbar.

Open User Preferences to capture:

Then click on Capture Preference icon:

Then choose the specific preferences, for example, the colors of JSP tag attribute name, equal and value:

Note that I have other preferences selected earlier to capture.

You can now close the user.setup:

Launch the other Eclipse installation and Perform Setup Tasks:

Choose the preferences and click Finish to sync.

You will see the changes take effect.

If you have the automatic task execution at start time enabled, you don't have to manually perform setup tasks.

When you start Eclipse the Oomph setup task automatic run:

Rename Multiple Files with DOS Command RENAME

The Syntax

RENAME [drive:][path]filename1 filename2.
REN [drive:][path]filename1 filename2.


Note that you cannot specify a new drive or path for your destination file.

For example,

ren c:\temp\test.txt abc.txt
ren *.txt abc.txt

The first parameter is the file selection criteria. It selects all files that match this criteria, then renames the files based on the second parameter.

The selected files are renamed one at a time, with character by character mode. As it works through the files, it stops as soon as an error is encountered, and the rests of the files will be left untouched.

Wildcards

Wildcards * and ? can be used with REN for matching and renaming.

The * wildcard will match any sequence of characters
               (0 or more, including NULL characters)

The ? wildcard will match a single character
               (or a NULL at the end of a filename)

Consider Renaming the Following Files

X-test-01.txt
Y-test-02.txt
Z-test-03.txt

Some middle characters are fixed throughout the files while they varies at the beginning and the ending part of the names.

Renaming Middle Part, Same Number of Characters

Renaming the middle part is straightforward when the targeted result has the same number of characters.

For example,

ren ?-test-0?.txt ?-good-0?.txt
ren ??test???.txt ??good???.txt
ren ??test???.txt ??good*

These rename middle part "test" to "good". i.e. they become

X-good-01.txt
Y-good-02.txt
Z-good-03.txt

Renaming Middle Part, Different Number of Characters

It is a bit tricky if you want to rename the middle part but with different number of characters. This cannot be done with a single REN command, because REN works in character by character mode.

If you try these,

ren ??test???.txt ??goodjobs???.txt

"job" will not be inserted, but copied over character by character. The result will be,

X-goodjobs.txt
Y-goodjobs.txt
Z-goodjobs.txt

Insertion will work only if the characters immediately after the part you intend to change is fixed across all files.

For example, you can rename the following files,

X-test-a.txt
Y-test-a.txt
Z-test-a.txt

to

X-goodjob-a.txt
Y-goodjob-a.txt
Z-goodjob-a.txt

Using the following command:

ren ??test??.txt ??goodjob-a.txt

Returning to the original set of files, the following batch script works:



for %%i in (??test???.txt) do (set fname=%%i) & call:rename
goto finish

:rename
ren %fname% %fname:~0,2%goodjob%fname:~-7%

goto :eof

:finish



%fname:~0,2% selects the first two characters from the filename.
%fname:~-7% selects the last seven characters from the filename.

Note:
Use LFNFOR to turn on long file name support when processing for command.

Recreate TEMP Tablespace

Step 1: Create another temporary tablespace, TEMP2

create temporary tablespace TEMP2
tempfile 'd:\oracle\oradata\sid\TEMP02.DBF' size 100m
extent management local uniform size 100m;

alter database tempfile 'd:\oracle\oradata\sid\TEMP02.DBF' autoextend on next 100m maxsize unlimited;

Step 2: Set it as default temporary tablespace

alter database default temporary tablespace TEMP2;

Step 3: Make sure No sessions are using your Old Temp tablespace

Skip this step if you are recreating temp tablespace without any user accessing the db.

Find Session Number from V$SORT_USAGE:

SELECT USERNAME, SESSION_NUM, SESSION_ADDR FROM V$SORT_USAGE;

Find Session ID from V$SESSION:

If the resultset contains any tows then your next step will be to find the SID from the V$SESSION view. You can find session id by using SESSION_NUM or SESSION_ADDR from previous resultset.

SELECT SID, SERIAL#, STATUS FROM V$SESSION WHERE SERIAL#=SESSION_NUM;
OR
SELECT SID, SERIAL#, STATUS FROM V$SESSION WHERE SADDR=SESSION_ADDR;

Kill Session:

Now kill the session with IMMEDIATE.

ALTER SYSTEM KILL 'SID,SERIAL#' IMMEDIATE;

Step 4: Drop Old TEMP tablespace

drop tablespace TEMP including contents and datafiles;

Step 5: Recreate TEMP tablespace

create temporary tablespace TEMP
tempfile 'd:\oracle\oradata\sid\TEMP02.DBF' size 512m
extent management local uniform size 100m;

alter database  tempfile 'd:\oracle\oradata\sid\TEMP01.DBF' autoextend on next 100m maxsize unlimited;

Step 6: Set TEMP as the default Temporary Tablespace

alter database default temporary tablespace TEMP;

Step 7: Drop TEMP2

drop tablespace TEMP2 including contents and datafiles;

ORA-25152: TEMPFILE cannot be dropped at this time

The temporary tablespace can have more than one tempfile. You can drop the tempfile by running the following command:

Advice: You should do this when no user is using the database.

Oracle 9i R2 and above:

alter database tempfile 'd:\oracle\oradata\sid\temp04.dbf' drop including datafiles;

Oracle 10g R2 and above:

alter tablespace temp drop tempfile 'd:\oracle\oradata\sid\temp04.dbf';

The commands above are usually successful if there is no active session using the tempfile. The tempfile do not need to be in OFFLINE status in order for it to be dropped. However, you can bring it OFFLINE first before dropping with the following command:

alter database tempfile 'd:\oracle\oradata\sid\temp04.dbf' offline;

A tempfile cannot be dropped is usually caused by active sessions.

If you receive error such as below, try to kill the active session:

ORA-25152: TEMPFILE cannot be dropped at this time

Find out the active session:

SQL> SELECT s.sid, s.username, s.status, u.tablespace, u.segfile#, u.contents, u.extents, u.blocks
  2  FROM v$session s, v$sort_usage u
  3  WHERE s.saddr=u.session_addr
  4  ORDER BY u.tablespace, u.segfile#, u.segblk#, u.blocks;

       SID USERNAME   STATUS   TABLESPACE  SEGFILE#  CONTENTS  EXTENTS BLOCKS
---------- ---------- -------  ----------- --------- --------  ------- ------
       213 DBUSER1    INACTIVE TEMP        203       TEMPORARY 5279    675712


SQL> select sid,serial# from v$session where sid = 213;

       SID    SERIAL#
---------- ----------

       213      48649

Kill the session:

SQL> alter system kill session '213,48649';

System altered.

Retry drop the tempfile:

SQL> alter database tempfile 'd:\oracle\oradata\oradb\temp04.dbf' drop including datafiles;


Database altered.

If the command above is successful, but the physical tempfile is not deleted. You might have to restart the database and delete the physical file at OS level.

Multiple Eclipse Installations in a Single User Environment

Cascaded and Shared Configuration

It is possible to install multiple copies of Eclipse in the same computer. Each copy of Eclipse might work on different development projects and share common plugins as well as having plugins of their own. This kind of setup works well if all copies of Eclipse have similar and compatible versions. If the Eclipse installs are different versions, you may experience problems. For example, it is not advisable to setup shared configuration if you have one instance of Eclipse Kepler to work on JBoss related projects, and another instance of Eclipse Mars to work on Birt report related projects.

If your Eclipse versions are compatible, you can setup each copy for shared configuration by editing the eclipse.ini file as follow:

Add these lines after the -vmargs line:

-Dosgi.configuration.cascaded=true
-Dosgi.configuration.area=@user.dir/configuration
-Dosgi.sharedConfiguration.area=@user.home/.eclipse/configuration
-Dosgi.sharedConfiguration.area.readOnly=false
-Dosgi.install.area.readOnly=true

Standalone Configurations

While having a shared configuration setup on a particular Eclipse version, you may setup an instance of Eclipse of different version with standalone configuration. By default, Eclipse are shipped with standalone configuration.

Updates of plugins in standalone Eclipse does not affect the updates of a shared configuration and vice versa.

Standalone Eclipse installation is straightforward. i.e. After the Eclipse package zip file had been downloaded, unzip it to your desired install drive and directory. That's it. You might want to rename the Eclipse home folder.

The following is the default setup environment:

-Dosgi.configuration.area=@user.dir/configuration

Common Mistake

Note: Never unzip one version of Eclipse over another version of Eclipse on the same directory.

Oracle Data Pump Export / Import Multiple Dump Files

Usually, we choose to export the database into multiple dump files rather than a single dump file is because there are hardware limitations such as hard disk space constraints and limited network bandwidth when moving the dump files to a different backup locations.

This will not delve into multiple dump files in different locations due to disk space constraints. Basically, I cover only multiple dump files in the same location for easy copying over a limited network bandwidth.

Even though it is possible to configure a network drive location in Oracle and export straight to that location, it is highly not recommended because it places a huge amount of stress on Oracle itself. It is best to export the dump files to a local drive and let the file transfer over the network handled by the operating system.

In order to export a schema and split the dump file into smaller size files, we specify the filesize parameter:

Syntax:

expdp 'sys/pwd as sysdba' directory=dumpdir dumpfile=mydump-%u.dmp filesize=500M logfile=mydump.log schemas=schema1,schema2

%u is the substitution variable for the number of dump files generated. Large file transfer over the network could use up a lot of RAM and might cause the system to hang.

Importing the dump files is straight forward as follow:

impdp 'sys/pwd as sysdba' directory=dumpdir dumpfile=mydump-%u.dmp logfile=imp.log remap_schema=schema1:newschema1,schema2:newschema2

The remap_schema parameter is optional and can be omitted if you are importing back to the same schema. You do not need to pre-create the schema (db user) if it does not already exist, though you could. If a schema is remapped to a different name that does not already exist, the password (db user password) remains the same as the original schema.

If the original schema is assigned to a different tablespace, the import syntax above does not create the tablespace. Instead, the schema will be created on the default tablespace, USERS. If you need the schema to use a different tablespace, you must pre-create the schema before importing.

Reducing the Temporary Tablespace Size in Oracle 11g

The TEMP tablespace is used when there is a large quantity of sort operations cannot be handled in RAM. It could grow to a very large size if many such database queries are executed at the same time, where a large temporary tablespace is required. Those queries might be badly written or require optimization.

A sustainable long-term solution is to optimize or rewrite the badly written SQL queries.

Meanwhile, if you must free some hardisk space right now, the following is how you should shrink the TEMP tablespace.

Firstly, have a view of the TEMP tablespace usage (numbers are in bytes):

SELECT * FROM DBA_TEMP_FREE_SPACE;

Then, you can decide to shrink the TEMP tablespace online:

ALTER TABLESPACE TEMP SHRINK SPACE KEEP 10G;

You might want to shrink a specific tempfile using the TEMPFILE clause:

ALTER TABLESPACE temp SHRINK TEMPFILE '/u01/app/oracle/oradata/DB11G/temp01.dbf' KEEP 30M;

Note:

You might want to do the shrinking during off peak hours as the TEMP could be busy during the peak hours.

Eclipse: AERI failed with an error

This is not a serious error. I'd say you can ignore it. However, if it bothers you, please try the following:

Steps that reproduce the Symptom:

- Import an existing project (from the worksapce of another copy of Eclipse), with "copy project into workspace" selected.
- Clean and rebuild the project
- Close the project
- Exit and restart eclipse

The following error (warning) is displayed on the Error tab:

AERI failed with an error. Please report this error: null ; version: 1.100.0.v20160211-1103

java.lang.NullPointerException
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:217)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:90)
at org.eclipse.epp.logging.aeri.core.SystemControl.executeHandler(SystemControl.java:103)
at org.eclipse.epp.logging.aeri.core.SystemControl.isActive(SystemControl.java:65)
at org.eclipse.epp.logging.aeri.core.util.LogListener.logging(LogListener.java:45)
at org.eclipse.core.internal.runtime.RuntimeLog.logToListeners(RuntimeLog.java:161)
at org.eclipse.core.internal.runtime.PlatformLogWriter.logged(PlatformLogWriter.java:103)
at org.eclipse.osgi.internal.log.ExtendedLogReaderServiceFactory.safeLogged(ExtendedLogReaderServiceFactory.java:88)
at org.eclipse.osgi.internal.log.ExtendedLogReaderServiceFactory.logPrivileged(ExtendedLogReaderServiceFactory.java:217)
at org.eclipse.osgi.internal.log.ExtendedLogReaderServiceFactory.log(ExtendedLogReaderServiceFactory.java:189)
at org.eclipse.osgi.internal.log.ExtendedLogServiceFactory.log(ExtendedLogServiceFactory.java:65)
at org.eclipse.osgi.internal.log.ExtendedLogServiceImpl.log(ExtendedLogServiceImpl.java:87)
at org.eclipse.osgi.internal.log.LoggerImpl.log(LoggerImpl.java:54)
at org.eclipse.core.internal.runtime.Log.log(Log.java:65)
..
..
at org.eclipse.core.internal.runtime.PlatformLogWriter.logging(PlatformLogWriter.java:44)
at org.eclipse.core.internal.runtime.RuntimeLog.log(RuntimeLog.java:97)
at org.eclipse.core.internal.jobs.JobManager.endJob(JobManager.java:701)
at org.eclipse.core.internal.jobs.WorkerPool.endJob(WorkerPool.java:105)

at org.eclipse.core.internal.jobs.Worker.run(Worker.java:72)

Causes:

Most likely because the build path environments are not properly bound during import. The system environment settings such as JRE and JBoss Server of both Eclipse are configure with the exact same names. The project uses these environments when it is compiled. In fact, the compile is successful without error, but after compile and close the project, it complains the project is not open. When Eclipse is closed and it tries to save project preferences, a warning (error) is recorded.

Solution:

Remove all build path environments for the project. Add all dependencies one by one from scratch.

Allowing (Unblock) Self-signed Java Applet in Java 7 Update 51 and Later

Java Security

Starting from Java 7 Update 51, Java does not allow users to run applications that are not signed (unsigned), self-signed (not signed by trusted authority) or that are missing permission attributes. This is a good security feature.

The older Java (1.4 to 1.6) are able to run unsigned applet without any prompt. However for self-signed applets, a prompt is displayed and you must explicitly tell the Java runtime that you trust the applet.

Whether it is required to add the website address to the Trusted Site zone depends the IE version. For IE10 and above, you must add the website IP address to the Trusted Site zone for a signed applet to run without hiccups.

Applet for Internal Usage (Intranet)

On the other hand, if you have developed an application for internal use, it is not worth the effort and cost to purchase a verified certificate by a trusted authority since the users can trust you and that your application is not going to perform anything malicious.

The following article illustrates how you can create a self-signed certificate and install in the users' machine so that their browsers do not complain that your java applet has been blocked, or that the applet poses security risks every time the user accesses the page.

Java Security Default Behaviour (Java 1.7 Update 51 onwards)

By default, the following dialog is displayed when an unsigned applet is accessed.

Exception Site List

Nevertheless, you can still allow an unsigned applet to be executed by adding a URL to the Exception Site List.

However, the browser will still nag at the user every time the user brings up the page.

This security feature may seem like a nuisance for those who know the apps can be trusted as it was developed by their own developer. Because the applet is not signed, so it keeps nagging. Therefore, the developer could self-sign the applet, create a self-signed certificate, and then distribute and install the certificate on the users' computer.

Java Certificate Repository (use Signer CA for self-signed certs)

Do not confuse yourselves with Microsoft Windows Certificate because this is the Java Certificate which is stored in a different repository from the Windows certificate repository.

The Java Certificate repository is located at:

C:\Users\<user name>\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs

for certificates verified by a Trusted Authority

and

C:\Users\<user name>\AppData\LocalLow\Sun\Java\Deployment\security\trusted.cacerts

for self-signed certificates (Signer CA, Signer Certificate Authority, where the signer is the authority)

If you import the self-signed certificate into trusted.certs, it is ignored and the applet will still be blocked.

Permission Attributes

You may remove the URL from the Exception Site List if the signed jar manifest contains the appropriate permission attributes. If the permission attributes is not set, and the URL is removed from the Exception Site List, the self-signed applet will be blocked as follow even after the cert is imported into the Signer CA repository.

Therefore, set the jar manifest appropriately as follow with ant build tool,

    <jar destfile="applet/Abc.jar">
      <manifest>
        <attribute name="Permissions" value="all-permissions"/>
      </manifest>
     ...
     ...
    </jar>

Before Signing the Applet JAR

Generate a key pair in the Java key store so that this security key pair can be used to sign the applet as well as create a public certificate to be distributed.

Generate Key Pair

C:\Users\<user-name>\AppData\LocalLow\Sun\Java\Deployment\security>keytool -genkeypair -alias Aliasname -keyalg DSA -keysize 1024 -dname "CN=PublisherName, OU=LineOfBusiness, O=CompanyName, C=Country" -keypass keypwd -storepass storepwd -validity NoOfDaysToExpire

This will create a file named .keystore in the Users\<user-name> folder. After this file has been created, you may sign the applet Jar and create (export) a public certificate file.

Create Self-signed Public Certificate File

C:\Users\<user-name>\AppData\LocalLow\Sun\Java\Deployment\security>keytool -exportcert -storepass storepwd -alias Aliasname -file mycert.csr

Certificate stored in file <mycert.csr>

Copy this file to the client computers, then import it into the Java Signer CA repository.

Import Certificate into Signer CA Repository of Client Machine

C:\Users\<user-name>\AppData\LocalLow\Sun\Java\Deployment\security>keytool -importcert -keystore c:\users\<user-name>\appdata\locallow\sun\java\deployment\security\trusted.cacerts -storepass ""  -alias Aliasname -file mycert.csr
Owner: CN=PublisherName, OU=LineOfBusiness, O=CompanyName, C=Country
Issuer: CN=PublisherName, OU=LineOfBusiness, O=CompanyName, C=Country
Serial number: 56c2a5d8
Valid from: Tue Feb 16 12:30:16 SGT 2016 until: Fri Feb 13 12:30:16 SGT 2026
Certificate fingerprints:
         MD5:  29:4F:49:3B:5D:44:4D:D4:11:BA:EB:0E:F7:9A:63:76
         SHA1: 67:6A:B8:68:0F:C2:19:DD:CE:F4:C8:C0:46:C4:13:D5:AF:85:39:21
         Signature algorithm name: SHA1withDSA
         Version: 3
Trust this certificate? [no]:  yes

Certificate was added to keystore

 Run Applet First Time

Once it is approved (check "do not show this again"), it will not prompt again.

That's it.