Re:

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hello Stefan,

My week-end in Porto was wonderful.
We had a nice weather and I took some good pictures (especially some very
wide panoramic shots that are gorgeous).

I saw you started working this week-end on Apache DS and LDAP Studio
reporting some bugs and filling some Jiras.

We should discuss this directly on the Dev List, so that other developers
can follow us. I'm forwarding this answer to the Dev List.

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


True... 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
> exists there.


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 net.sf.elbe.core.jobs)
> - 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()->
>       ConnectionProvider.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 ConnectionProvider.appplyModification()
>   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
>   consolidated event.


Thanks. This is now clearer how the core works. This is a great architecture
that we should adopt in LDAP Studio.

Discussion:
> -----------
> We should discuss how to merge our tools. Here are some issues we could
> discuss,
> I brainstormed a bit:
>
> 1.)
> 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.

2.)
> 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.


No, 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.

3.)
> 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.

4.)
> 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.


I 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.

5.)
> 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.

6.)
> Is there a plan to migrate the build environment to maven or would we keep
> ant?


I 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
?


> 7.)
> Is there a plan to provide a online schema editing?


Indeed, 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.

8.)
> In ELBE-UI all texts are in source code :-(. We should externalize the
> strings.
>

Yes, although I think some LDAP Studio projects also have UI Strings
directly in source code. An effort should be made in this direction.

I think we have to talk on IM to compare and share our vision on the LDAP
Browser Plugin. It may be a good thing to write down some specification
together and a timeline for LDAP Studio LDAP Browser Plugin.

See you.

Pierre-Arnaud

Re:

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hello Stefan,

I will show if the shared-ldap LDIF utils could be used for the LDIF
> editor. Does it makes sense to move the DSML parser to ldap-shared?


Not yet I think. It still has major opened issues but as soon as it support
binary values and those major issues are closed, its best place may be
shared-ldap.

There are some issues with big files in eclipse (see
>
> https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=big+large+files
> ).
> If we want to use the eclipse features (syntax coloring folding, content
> assistence) this could be a real problem. The LDIF editor currently
> rejects files bigger than 1MB.


So, we may have exactly the same problem with a DSML Editor. It may even
come sooner, since XML files are more verbose

> I 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 ?
> No, not yet.
>

Ok, we'll work together on spare time to get LDAP Studio building with
Maven.

P-A

Re:

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

> I will show if the shared-ldap LDIF utils could be used for the LDIF
> editor.


If you need any help whith the Ldif library, just post a mail to the ML, I
may help.

Does it makes sense to move the DSML parser to ldap-shared?


Sure !

There are some issues with big files in eclipse (see
>
> https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=big+large+files
> ).
> If we want to use the eclipse features (syntax coloring folding, content
> assistence) this could be a real problem. The LDIF editor currently
> rejects files bigger than 1MB.


Hmmm... Not sure that it make sense to edit a LDIF file which is bigger than
1MB. In my mind, what you should do is to load the entries, not the ldif
file. The shared-ldap ldif tool is able to grab one entry at a time, may be
we can add some kind of curser to navigate through the file without loading
it in memory.

--
Cordialement,
Emmanuel Lécharny

Eclipse Plugin Building With Maven

[Ole Ersoy <ol...@yahoo.com>]

Hey Guys,

One thing that I do know that works is 
generating a model plugin using eclipse 
emf and overlapping the java directories with
thoee of Maven's.

I wrote a little mini tutorial and executed it ... So
it works :-)

I'm uploading it to my sandbox right after this mail
goes out.  Note that in the root directory there
is a library-maven.apt document.  It contains all the
steps I did to get the code generated and the
dependencies I added to the pom.

You can use this as a baseline to see how to get the
Studio working with Maven.

Also note that there is a dependency scope in maven
called System, that is for jars provided explicitly
(Not looked up in the repository) that may be of help
for eclipse repository dependencies.  I still need to
look up how to set explicit dependencies in maven
though.

Cheers,
- Ole

 







--- Stefan Seelmann <ma...@stefan-seelmann.de> wrote:

> Hello Pierre-Arnaud,
> >
> >     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
> >
> >
> > True... 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 ?
> Yes, you are right.
> >
> >     4.)
> >     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.
> >
> >
> > I 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.
> I will show if the shared-ldap LDIF utils could be
> used for the LDIF
> editor. Does it makes sense to move the DSML parser
> to ldap-shared?
> 
> There are some issues with big files in eclipse (see
>
https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=big+large+files).
> If we want to use the eclipse features (syntax
> coloring folding, content
> assistence) this could be a real problem. The LDIF
> editor currently
> rejects files bigger than 1MB.
> 
> >     6.)
> >     Is there a plan to migrate the build
> environment to maven or would
> >     we keep
> >     ant?
> >
> >
> > I 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 ?
> No, not yet.
> 
> Best regards,
> Stefan
> 



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Re:

[Stefan Seelmann <ma...@stefan-seelmann.de>]

Hello Pierre-Arnaud,
>
>     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
>
>
> True... 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 ?
Yes, you are right.
>
>     4.)
>     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.
>
>
> I 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.
I will show if the shared-ldap LDIF utils could be used for the LDIF
editor. Does it makes sense to move the DSML parser to ldap-shared?

There are some issues with big files in eclipse (see
https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=big+large+files).
If we want to use the eclipse features (syntax coloring folding, content
assistence) this could be a real problem. The LDIF editor currently
rejects files bigger than 1MB.

>     6.)
>     Is there a plan to migrate the build environment to maven or would
>     we keep
>     ant?
>
>
> I 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 ?
No, not yet.

Best regards,
Stefan