directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Knecht <>
Subject Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Date Fri, 28 Dec 2007 16:58:23 GMT
Pierre-Arnaud Marcelot schrieb:
> Hi Felix,
>     Building .classpath and Manifest file seems to work with 3.3
>     dependencies and I can start the plugins from within
>     eclipse without any error messages.
> I just tested them and they work fine. Except the name of the projects
> (which are very long now), 

I wonder if we need
a) the prefix 'studio' for the modules
b) having the in the artifact name

so a checkout directory structure could look like
to be continued

and a dependency would look like


everything is really great and works very
> very well within Eclipse. Thanks a lot for that. :)

I'm happy it's working :-)

> I had a look at the different pom.xml files and they are pretty long
> now, and there seem to be some duplicate build instructions.
> I'm wondering if we should not try to create differents parents pom
> files, 1 for each type of project we have.
> I can see 4 different types of projects that requires 4 different builds:
> - Classic java project (e.g. 'studio-dsml-parser')
> - Eclipse plugin project (e.g. 'studio-ldapbrowser-core' or
> 'studio-connection-ui')
> - Feature project (e.g. 'studio-schemaeditor-feature')
> - Help plugin project (e.g. 'studio-ldapbrowser-help')

In fact we can separate to modules on it's own projects, because they are not 'immediately'
involved in the studio project:
- studio-plugin (parent pom is already
- studio-dsml-parser (need to change the parent pom to ?)
- All the others I'd them as they are now.

If taking also the dsml-parser out of the build process we need either to make sure that it
exists as dependency in a
remote repository or have a note in the documentation saying that you also need to build the
dsml-parser (like the
plugin) before the studio can be built.

I don't now if it's a good idea but e.g. we can have a new directory project called directory-plugins
where the
maven-studio-plugin comes into and also the ones from apacheds which are intend of a more
global use in future.
The dsml-parser could be moved into the shared project. If you think that dsml parser can
be used that globally why not
put it in the studio-ldapbrowser-core module? I couldn't find any other place where it's used.

I think most of these duplications are a result of trying to do all of it in one build. If
we can create the above
mentioned modules on it's own it probably would make things easier.

>     Distribution build needs still some work.
> I can help with that. :)
> I tested the distribution build on Linux and it works great. 

Happy to read :-)

It fails on
> Mac OS X and Windows but it's easy to fix.
> The key is to use our specific application launchers (the ones located
> in the /dependencies/eclipse/3.3.1/macosx,
> /dependencies/eclipse/3.3.1/linux, /dependencies/eclipse/3.3.1/win32
> folders) instead of re-using the ones from the eclipse distribution (
> e.g. eclipse-RCP-macosx-carbon- They all work great and include
> the correct branding (with the correct icons for example).
> So I think we have to tar gzip these launchers, install them in our
> local-repository and use them when building the application instead of
> the ones we use at the moment.

Yes, please go ahead. I think tar (or zip) is a more logical format than a jar (which would
also be possible)


View raw message