why documentum webtop is shiped with java windows jre - documentum

I found 2 big files in documentum webtop
webtop\wdk\contentXfer\win-jre1.6.0_16.zip
webtop\wdk\contentXfer\win-jre1.5.0_06.zip
Why webtop is shipped with it?

If all your users have java on their PCs then you can delete the JREs packaged with webtop. I have done this before. Also I stripped out other files not used. For example:
the help files (not used as client did their own help)
Delete Sources and Web Workflow manager
Remove Themes
Remove UCF Jars and JRE
Make sure to check the runtime java version setting in: "wdk/contentXfer/ucf.installer.config.xml"
Your PC clients must have at least this version of java installed. This is from Webtop 6.7

Webtop version 6.0 and above uses Java Applet for file operations
such as check-in, check-out, import etc.
EMC named this technology as UCF. So to execute the Java Applet of this UCF
technology Webtop shipped with Windows JRE.

Related

Using Atlassian QuickReload with java 7

Developing a JIRA Plugin and would like to use the QuickReload feature. However I am using the 5.0.x SDK and that uses Java 7. QuickReload appears to need Java 8. Is there a way to get this working for java 7?
I have successfully used QuickReload with Java 7 on JIRA standalone releases as far back as JIRA 6.1 (without regard to the Plugin SDK version in use).
To get this to work, you can download the QuickReload sources, build it as a JAR with atlas-mvn package, and then upload the JAR as a plugin to JIRA. Then add a quickreload.properties to the root of your JIRA install directory and everything should work as expected.
(I suppose it's possible that newer versions of quickreload might require a higher version of Java, but this worked fine as of commit a8e25f30fbd.)

Dependencies / Source of certain JAR files with Worklight version

I have downloaded an iFix from IBM fix central (6.1.0.02.20150520-1015) for Worklight Server and Worklight Studio but I could not locate the below jar files.
Applicationcenterdeploytool.jar
Ibm-java-x86_64-sdk-7.0.-6.0.bin
Json4j.jar
Wlpdevelopers-runtime-8.5.5.2.jar
Can you confirm if the above jar files are also specific to worklight version and will be seen post WL server installation or are they generic files which can used with any WL version which can be used by jenkins build scripts.
Ibm-java-x86_64-sdk-7.0.-6.0.bin - this is IBM's version of Java. This is not bundled with either a GM or iFix or Fix Pack. You're downloading this yourself prior to any installation, if you choose to use it.
Wlpdevelopers-runtime-8.5.5.2.jar - I have no idea what that is. Looks like some WAS or WAS Liberty profile file, which you also install separately from Worklight
Applicationcenterdeploytool.jar - located post-install at install-directory/ApplicationCenter/tools/applicationcenterdeploytool.jar and is the deploy tool of Application Center, used by the ant task scripts.
Json4j.jar - located post-install at install-directory/ApplicationCenter/tools/json4j.jar and is used to handle the JSON file format

Integrate Apache ACE with Equinox

I've read in the documentations of Apache Ace 2 that it works with Equinox OSGi targets as well, but I can't find out how to configure it. I am aware there is already p2 for Equinox but I also want to integrate it with the Ace software.
I've found somewhere that I should edit managementagent bundle, if that's true still don't know how.
The binary release of Apache ACE ships with:
An executable jar that contains Apache Felix and the management agent. It can be found in the server-allinone/store folder and is called ace-launcher.jar
A "development" target in the target/ folder that can be used to for development/testing and pre-installs a shell, logging and the management agent.
Neither gives you Equinox out of the box.
However, if you checkout the ACE sources, there is a project called org.apache.ace.agent.launcher which creates two jar files:
felix.bnd which creates the ace-launcher.jar mentioned above and embeds Apache Felix
base.bnd which relies on the standardized launcher API of OSGi and will bootstrap the first framework it finds on the classpath
So, you can either use the artifact generated by base.bnd and put Equinox on your classpath, or take felix.bnd and modify it so it will run equinox instead.
By the way, we would be happy to accept such work as a patch so we can provide this out of the box.

Force Eclipse (Helios) to use a newer version of SWT at application runtime

I'm developing an RCP project using Eclipse-Helios.
The version of SWT that is installed (in the plugins directory) is [org.eclipse.swt-win32-3.6.2, & org.eclipse.swt.jar]
I require new API functionality that is only available from swt-3.8. (specifically, I wish to set the custom colours, for an SWT color dialog before opening.)
I have downloaded 3.8.1 from the SWT/Eclipse downloads site [ http://download.eclipse.org/eclipse/downloads/drops/R-3.8-201206081200/#SWT ]
The SWT download is NOT a plugin (couple of jars, src.zip and some readme files), so I am unable to add it to my "Target Platform" (it doesn't appear as an available jar even after adding the containing directory in "locations")
I was unable to find an update site for SWT (or any site where i could get a plugin for the newer version)
If I add the swt.3.8.jar to my classpath (and then increase it's order-priority in the project build-path), I am able to access the newer api functionality from my code (as well as view the source).
When I run the application however, it seems as though the runtime is still using the older SWT jar, as i get an unknown method error, when attempting to access the newer functionality.
Questions:
Is there an SWT repository location that I can use to download a newer version of SWT using the eclipse install manager?
If not, is there a way I can force the runtime to ignore the older version (I assume via plugin.xml)?
Is there a better way to achieve what I am trying to do?
What is the difference between the two SWT jars currently in the helios plugins directory (as the 3.8 download only contains the win-32 version)?
Thanks in advance.
SWT is downloadable as a separate plugin here:
http://download.eclipse.org/eclipse/downloads/drops/R-3.8-201206081200/#SWT
Eclipse 3.8 contains regular plugins including the SWT (the win32 specific as well as the generic "org.eclipse.swt_.jar"). I am currently using the 3.8 version and they appear as plugins.
I also have Eclipse 3.6 (Helios) and I was able to import the swt plugins using the "File->Import->Plug-in Development->Plug-ins and Fragments" wizard. I just specified the eclipse 3.8 directory and could import them in my workspace. Once imported I can of-course use them to be included in the runtime environment. Eclipse should use the latest version automatically.

IDE for websphere/jython

I would like to develop administrative jython-scripts for WebSphere 7. Is there any IDE (or may be plugins for eclipse) which provides code auto-completition functions, ability to start/stop server, debug jython scripts? I know that there is the Application Server Toolkit 6.1 but it is for WebSphere 6.1 and couldn't be applied to WebSphere 7.
In WAS 7, "IBM Rational Application Developer Assembly and Deploy V7.5" has replaced the AST. "IBM Rational Application Developer V7.5 for WebSphere" is a superset of "IBM Rational Application Developer Assembly and Deploy V7.5". Both ship with your copy of WAS, but the license for RAD is just a trial one, while the license for the assembly and deploy tool does not expire. See:
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/catk_assemblytools.html
Either should allow you to create/debug Jython/wsadmin scripts.
As for Python/Jython there is PyDev Eclipse plugin.
I got frustrated with Jython Wsadmin myself. I built a tool that uses a Groovy-DSL for my configuration:
Datasource
JdbcProvider
SIB, JmsQueue, Top
ActivationSpec
etc.
You can add it as a project dependency in IntelliJ and you got completion and inspection. You will be able to step through the script with a Debugger as in a regular Java program. I didn't test the start/stop server functionality, though.
I went as far as to make it useful for my purpose, pull requests welcome:
https://github.com/revaultch/wsadmin-groovy