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 Fri, 28 Dec 2007 16:58:23 GMT
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



Mime
View raw message