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 23:17:28 GMT
Felix Knecht schrieb:
> 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
> .../studio/trunk
> .../studio/trunk/studio
> .../studio/trunk/aciitemeditor
> .../studio/trunk/apacheds-configuration
> .../studio/trunk/apacheds-configuration-feature
> to be continued
> and a dependency would look like
> <dependency>
>   <groupId></groupId>
>   <artifactId>aciitemeditor</artifactId>
> </dependency>

We really should name them like this looking at the threads (discussions about mavenization
of eclipse artifacts)

(Sorry, haven't found a better link)

and (Eclipse jars now in maven by Carlos Sanchez)


PS and BTW
I'm going to 'migrate' the local-repository to the same structure as Carlos used (unfortunately
most of the eclipse are not yet in the official maven repository) and adapt the maven-studio-plugin/build
process to work with the
migrated local-repository.

> 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')
>> WDYT?
> 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
> 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)
> Regards
> Felix

View raw message