Hi,
I am looking to make MiSphere, a subset of iSphere for the users of MiWorkplace. I am examining the core plugins and it looks like the architecture is such, that this could be done.
I have a question about the iSphere core plugin. It looks like the design was such to depend on open source tooling only, but I see a couple of dependencies to com.ibm.etools.* which I believe is RDi only.
Is it possible to find jt400/internal solutions for the couple of dependencies that use closed source classes? The "pollution" is very light and it would be great if the project would consider to drop com.ibm.etools* in the core bundles.
The following classes are used:
AbstractSourceFileSearchDelegate / AbstractMessageFileSearchDelegate
import com.ibm.etools.iseries.comm.filters.ISeriesMemberFilterString;
import com.ibm.etools.iseries.comm.filters.ISeriesObjectFilterString;
import com.ibm.etools.iseries.comm.filters.ISeriesObjectTypeAttrList;
import com.ibm.etools.iseries.comm.filters.ISeriesObjectFilterString;
These classes are used internally to generate a filter via the toString() method. If only the String is passed around, it looks replaceable.
StringListEditor
import com.ibm.etools.iseries.util.NlsUtil;
SLE uses the toUppercase method which seems trivial.
Member / IProjectMember / CompareAction / CompareInput
import com.ibm.etools.iseries.comm.interfaces.ISeriesHostObjectLock;
It looks like ISeriesHostObjectLock can be replaced by ObjectLock which is provided by the ObjectLockManager.
Internal interface Member, uses this class in method signatures.
Hi Wim,
Just a short notice, the iSphere Core Plug-in must not have dependencies to any RDi plug-ins. The iSphere Core plug-in should run in any Eclipse. If that is not given, then something went wrong in the past, which must be fixed.
I did not yet had a close look at that, but will check that next.
Regards,
Thomas.
Ok, I figured this was the case. Thanks for looking into this.
I think, that I solved all issues. I could not remove the "com.ibm.etools.iseries.toolbox" dependency, because that dependency exists since the beginning of iSphere. But I created the "iSphere Standalone Plugin" that contributes that dependency in case of a pure Eclipse environment. I could not yet test that with a pure Eclipse IDE, but I assume it is worth a try.
When I remove that dependency, I get a classpath loading conflict between jt400.jar and the IBM Toolbox provided by the "com.ibm.etools.iseries.toolbox" plug-in.
The iSphere Standalone plug-in lives in sub-folder "incubator". I used the following plug-ins to start a pure iSphere debug application:
Thanks, Thomas.
AFAICT all usage is internal. You don't re-export it so it can be removed. What am I missing?
Did you commit this? I can't find the folder in the Files section.
Is this the issue?
Hi Wim,
the iSphere Core Plugins are almost independent from RDi. The only dependency of the iSphere Core Plugins to RDi is the com.ibm.etools.iseries.toolbox plugin. This means, if you plan to use the iSphere Core Plugins in a None-RDi Eclipse installation, then you have to deliver the com.ibm.etools.iseries.toolbox plugin from RDi to the None-RDi Eclipse installation too. If you dont wanne do this because of license problems, then you can build a new plugin with the id com.ibm.etools.iseries.toolbox which contains the JTOpen jars and deliver this to your None-RDi Eclipse installation. This would work as well.
Greetings
Frank
Closed due to the new public API that was added with 4.0.