directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Knecht <fel...@apache.org>
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 org.apache.directory.studio 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>org.apache.directory.studio</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
>     org.apache.directory.project:project)
>     - 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.
http://people.apache.org/~felixk/maven2 (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. ;)

Thanks
Felix


Mime
View raw message