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 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? 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 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. 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-3.3.1.1). 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
