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
