directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre-Arnaud Marcelot">
Subject Re: [Studio] Eclipse 3.3.1 dependencies + "Mavenization" of the trunk
Date Wed, 02 Jan 2008 17:49:02 GMT
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>

I'm completely OK with that.

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

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