I tried to add the ELBE-plugins as-is into LDAP studio (LS) and it works fine
with some exceptions:
- Standard menus and keybindings reused from Eclispe are not available
We'll have to add all the standard "File" & "Edit" Menu in the LDAP
Studio RCP App, as well as the associated key bindings.
I'll fill a Jira for that.
- New created LDIF files can't be saved
I think this is due to the previous issue... Once we
have all the standard menus and key bindings it should be working. What
do you think ?
- There is a problem with the antlr.jar. When LS starts with the ELBE
perspective, then the views in schema editor perspective are not available.
Also when adding the LS-plugins into eclipse works fine. The antlr problem also
I'll fill a Jira and start to investigate on that.
Some words about the architecture of elbe-core:
- JNDI is used to connect to server, but all JNDI stuff is encapsulated in
4 classes in a so-called ConnectionProvider.
- A Connection object is a central object for accessing the directory. It
provides search and modify operations and caches entries.
- Any interaction with the remote directory is done asychronly using the
Eclipse Job-API. (package
- A search works as follows:
1.) Create a Search/SearchParameter object.
2.) Create a SearchJob and execute it
3.) Job calls Connection.search()->ConnctionSearchHandler.search()->
4.) Search results are returned as Enumeration of LDIF records, so in the
ConnectionProvider JNDI objects are transformed to LDIF
5.) In ConnectionSearchHandler the LDIF records are transformed to the
internal Entry/Attribute/Value model.
6.) When search is finished the SearchJob fires an event.
- A modify works as follows:
1.) Get/create your modification objects (Entry/Attribute/Value)
2.) Create a <Modify>Job,
e.g. a ModifyValueJob and execute it.
3.) Job calls Connection.modify()->ConnectionModifyHandler.modify()
4.) The ConnectionModifyHandler converts all model objects to LDIF modify
operations and calls
5.) The ConnectionProvider converts the LDIF to JNDI calls.
6.) When modification is finished the Job fires an event.
- The usage of LDIF as interface between Controller and I/O makes it easy to
log modify operations and to perform LDIF import/export.
- Event handling: Views don't register at each object, but register at the
EventRegistry for specifc events (e.g. EntryModificationEvent). On model
modification the events are fired using the EventRegistry. When executing a
job, e.g. reading attributes from LDAP, the job suspends event-fireing in
its thread. When finished the job resumes event-fireing and fires one
Thanks. This is now clearer how the core works. This is a great architecture that we should adopt in LDAP Studio.
We should discuss how to merge our tools. Here are some issues we could discuss,
I brainstormed a bit:
I created ELBE primary as Eclipse plugin whereas LS is designed as RCP-App.
For a eclipse plugin IMO it is important that it doesn't add too much
menus and icons to keep the UI clear. That is the reason why the entry
editor and the search result editor are are singeltons, to avoid wasting
the editor area. Perhaps we could create a separate plugin that adds all
the menus and icons for the RCP-App but not for the plugin. Additional we
could provide separate distributions for users, admins and ADS-developers.
Yes it could make sense, but since the
menu is hidden when the LDAP Perspective isn't the frontmost
perspective, I think the menu isn't a really big issue. Regarding the
singleton entry editor and search result editor, several distributions
could be a solution. We have to think about that.
Do you want to continue development on your browser plugin? It seems that
it is not as powerful as ELBE. On the other hand the ELBE code could
receive some refactorings.
LDAP Studio Browser Plugin is at early stage of development and ELBE is
much more functional and has a lot more features. I'm now focusing on
integrating gradually some of ELBE features into LDAP Studio.
It seems we have two similar approaches to access the directory: we use a
pivot format (LDIF vs. DSMLv2). Till now the LDIF was sufficient for me and
it is quite easy to log modifications. But I think the DSML is more powerful,
I think it makes sense to switch to DSML and to use your DSML-Engine.
I agree. DSML is more powerful than LDIF.
I still have some issues with the DSML parser, especially with base64
encoding but we can handle that easily I think. We may also need to
adapt and open a little bit the DSML-Engine API.
Both ELBE and ADS have a LDIF parser and model. The LDIF parser in ADS is
good for import/export. But in ELBE I use the model also for the LDIF editor
and therefor I need a more powerful model.
see. It could be great to provide a LDIF editor to LDAP Studio using
the shared-ldap (which contains all LDIF related utilities).
I'm also planning on adding a DSML editor to complete the set of editors.
This way, we will be able to edit LDIF, DSML and Schema Files.
We could also work on a visual editor for LDIF and DSML.
As I have seen that ldap-shared contains a Schema parser and model. Perhaps we
could replace the ELBE schema stuff with ldap-shared.
Yes it could be great to do that.
Is there a plan to migrate the build environment to maven or would we keep
already tried to migrate to maven a few weeks ago and I got some issues
regarding the internal Eclipse computed dependencies (that are
necessary to build and run tests on plugins but should not be exported
in the plugin itself since those dependencies will be supplied by the
Eclipse platform or the RCP app). Have you ever successfully build an
Eclipse plugin using Maven ?
Is there a plan to provide a online schema editing?
in ADS we plan to be able to modify a schema within the server but this
isn't a trivial thing since we have to modify then the already existing
entries affected by the schema changes.
In ELBE-UI all texts are in source code :-(. We should externalize the strings.