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 Wed, 02 Jan 2008 18:11:28 GMT
Pierre-Arnaud Marcelot schrieb:
> Hi Felix,
>     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>
>     WDOT?
> I'm completely OK with that.
> +1
>     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. 
> Yeah, at some time, we'll need to integrate the dsml-parser inside
> shared-ldap.
> We have ideas to use it to build a DSML gateway for Apache DS.
>     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.
> I'm not sure....
> I was looking at the help plugins (studio-apacheds-configuration-help,
> studio-ldapbrowser-help, studio-ldifeditor-help, studio-rcp-help,
> studio-schemaeditor-help) and there's a lot of duplicated instructions
> to generate the user guides in various formats (html for web, pdf, html
> for eclipse). It would be very good to have that stored only at one place.

I agree. Let's try to find a solution for this.

> I'm also wondering if the repositories definitions we can find at the
> end of each pom.xml could not be moved up in the pom inheritance tree.

I'm still fighting with the 'local-repository'.
We can also create our 'own' maven2 remote repository with the needed eclipse dependencies
and have it online instead of
putting all the binaries into the repository, e.g. (or any other url)
and add this repository in the studios root pom.xml.

Doing so we could avoid definitely the problems we the generation of those nasty '${local-repository}'
(or so)
directories which happens depending of the location (studio root or subproject) you start
the mvn command from.

>     Yes, please go ahead. I think tar (or zip) is a more logical format
>     than a jar (which would also be possible)
> Yes, I agree, tar or zip is more appropriate for our need here.
> I'll try to prepare these package as soon as possible. ;)


View raw message