Felix Knecht schrieb: > 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>
We really should name them like this looking at the threads (discussions about mavenization of eclipse artifacts) http://mail-archives.apache.org/mod_mbox/maven-dev/200711.mbox/[EMAIL PROTECTED] and http://mail-archives.apache.org/mod_mbox/maven-dev/200711.mbox/[EMAIL PROTECTED] (Sorry, haven't found a better link) and (Eclipse jars now in maven by Carlos Sanchez) http://www.jroller.com/carlossg/entry/eclipse_jars_now_in_maven Reagards Felix PS and BTW I'm going to 'migrate' the local-repository to the same structure as Carlos used (unfortunately most of the eclipse 3.3.1.1 are not yet in the official maven repository) and adapt the maven-studio-plugin/build process to work with the migrated local-repository. > > 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 > >
