Apache Directory Studio Maven Build System Issues

Missing of building the .classpath and the .project files for eclipse">Missing of building the .classpath and the .project files for eclipse

Here are the steps to prepare the sources for eclipse development using the ant/ivy build:

• Checkout sources
• Run "ant resolve"
• Start eclipse (using a fresh workspace)
• Select File->Import->General->Existing Projects into Workspace
• Choose the folder with the sources
• After some time there should be a list of projects, select all and finish

One important thing is that the .project and .classpath files within each project are present. Right now they are managed by eclipse and they are under source control.

In maven there is an task "mvn eclipse:eclipse" that generates these files. I tried this command and it generates the files but with wrong content. There are too much jars included and one jar was missing.

Not sure if it helps. I added a .classpath and a .project file to svn (I don't think it's a good idea to have them under version control because these files may differ from IDE to IDE, OS to OS and users custom configurations).
The 2 files are created when I create new java project from existing source in eclipse.

We need one .classpath and .project file for each Eclipse project. In the current trunk they are under source control. I think it isn't a big problem that we only support one IDE (namely Eclipse) because we could only use Eclipse to develop Studio. And as long as we only have relative paths in the .classpath file the OS dependency doesn't matter. Right now it works under Linux, MaxOS and Windows.

I totally agree, Stefan, as our most our projects (except the studio-dsml-parser project) are Eclipse based plugins, it makes sense to keep the .classpath and .project files under source control for these ones.

 mvn eclipse:eclipse should now create .project and .classpath when run and update also the Bundle-ClassPath within the MANIFEST.MF. All dependencies not tagged with <scope>provided</scope> will go into the .classpath and into the Bundle-ClassPath.
This works when executed within a subproject. It works also when executed from the root except the studio-jars subproject. Somehow the dependency 'studio-dsml-parser' get lost when mvn eclipse:eclipse is executed from root.
(I still need to figure out how I can test if working within eclipse works -> some RTFM will probably be of need as I've never developed eclipse plugins before... ). The idea of course must be:

• Checkout sources
• Run "mvn eclipse:eclipse"
• Start eclipse (using a fresh workspace)
• Select File->Import->General->Existing Projects into Workspace
• Choose the folder with the sources
• After some time there should be a list of projects, select all and finish

 Of course mvn eclipse:eclipse can also be run later to reflect changes in the pom.xml within .classpath and MANIFEST.MF/Bundle-ClassPath. The problem is that if a new dependency is added you'll normally also need to add it in the pom. When the .classpath is generated by pom entries you'll less forget to add it there (at least my opinion). For dependency (the ones which were in the lib directory) a new entry in the .project file is created and should do the linking to the repository (instead of copying to the lib directory)- at least my (hopefully logical) conclusions. E.g.

<linkedResources>
    <link>
      <name>commons-codec-1.3.jar</name>
      <type>1</type>
      <location>/home/felix/.m2/repository/commons-codec/commons-codec/1.3/commons-codec-1.3.jar</location>
    </link>
</linkedResources>

Added new goals to maven-studio-plugin. After a svn checkout run mvn eclipse:eclipse studio:eclipse to generate .classpath, .project and adapt Bundle-ClassPath entry of MANIFEST.MF files.
Note that the studio plugin must be installed first, see also Draft - Working (Maven).

-Dos.name="mac os x" doesn't work">-Dos.name="mac os x" doesn't work

I tried the '-Dos.name=mac os x -Dos.arch=i386' and '-Dos.name="mac os x" -Dos.arch=i386 ' but I got a build failure. I'm going to investigate on that.

This has probably to do with http://jira.codehaus.org/browse/MNG-2190. I don't know yet how to solve it.

One possible solution (IMO not a very nice way) is to 'hardcode' the profiles. This means that you always need to indicate on commandline which profile you want to use - even for a build for the current OS yourworking on (e.g. -Plinux-i386).

 I try to fix this using os.family instead of os.name as profile activator (see below).

Profiles">Profiles

I see there are two profiles for Windows, one for Windows XP, one for Windows Vista. I think the build for this two OS is the same and they use the same packages.
Is it possible to have a single profile for Windows (which will work under Windows Vista, XP, 2000, etc.) ?

There's no profile for Mac OS X PPC. Build on Mac OS X PPC and i386 (Intel Mac) is the same and uses the same packages. Is it possible to have a single profile for both architectures ?

What 'profiles' are (intended) used for studio distributions?
Shall all possibilities you can download an RCP dist for be supported and build ()?
They are varying depending on the version of RCP your looking at:
3.2.1
http://archive.eclipse.org/eclipse/downloads/drops/R-3.2.1-200609210945/index.php
3.2.2
http://archive.eclipse.org/eclipse/downloads/drops/R-3.2.2-200702121330/index.php
3.3.1.1
http://download.eclipse.org/eclipse/downloads/drops/R-3.3.1.1-200710231652/index.php
3.4M3
http://download.eclipse.org/eclipse/downloads/drops/S-3.4M3-200711012000/index.php
And - when migration to maven build process - which version(s) shall be used (ATM it's 3.2.1 based)?

Right now we support the following distributions:
* Mac OS X PPC and i386 (Intel)
* Windows (tested on XP and Vista, and it should work on Windows 2000 too)
* Linux PPC, i386 and AMD64

I think it'll help for the profile activation if we can switch from os.name to os.family http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requireOS.html. So any linux will exist under os.family=unix and any mac will be under os.family=mac. Please note that this way we're not able to distinguish e.g. between mac os and mac os x or windows xp/nt/vista. But reading above I don't think that we need to?

As workaround (I'm still fiddling around with the activation via the os.* properties) please indicate a profile for the wanted OS (always). See also table above.
The profiles on the table above seem perfect.

I think they are the most commonly used configurations and we should concentrate on these one. There no need to build a Linux (x86/Motif) version if nobody needs it. If someone uses Linux (x86/Motif) and tells us on the ML he would like a version of Studio, then we can integrate this one.

(...)

Yes, it's based on 3.2.1 at the moment. This is because we could not get a way to generate (within eclipse) the executables for Apache Directory Studio (to replace the 3.2.1 ones) with Eclipse 3.3.0. I could not export the RCP Application as a Mac OS X application correctly, the export was failing... Maybe version 3.3.1.1 fixes that, I'll have to try again.

Shall I already add the 3.3.1.1 dependencies? 

Yeah sure...

Done.

It would be very great if we could migrate both Ant+Ivy to Maven and Eclipse version 3.2.1 to Eclipse version 3.3.x (for our Eclipse dependencies).

NOTICE and MANIFEST.MF files in META-INF folder

Are they automatically generated by Maven ?

MANIFEST.MF is taken from the META-INF folder which is under svn (no automatical generation}. NOTICE I need to do some further investigations.

Allow generation of dist with multiple profiles">Allow generation of dist with multiple profiles

Rearrange the assembly of a distribution in a way, that it's possible to create distributions indication more than 1 profile, e.g. when executin mvn clean install -Plinux-amd64,windows-x86,mac-os-x-ppc I expect to have 3 packed ApacheDirectoryStudio dist file in the target/distribution folder.

Done. Multiple distributions can be build indicating multiple profiles, e.g. (from $

) mvn clean install -Dmaven.test.skip=true -Plinux-amd64,linux-i386,linux-ppc,windows-x86,mac-os-x-i386,mac-os-x-ppc,userguides builds everything and put it into target/distributions and target/userguides

plugin.properties, project.properties, feature.properties files">plugin.properties, project.properties, feature.properties files

I see there are still some "plugin.properties", "project.properties", and "feature.properties" files inside projects and generated jars. They can be deleted as they were part of the Ant+Ivy build system.

They should have been removed now.

Empty ${local-repo} folder at the root">Empty ${local-repo} folder at the root

When compiling studio, maven creates a folder called "${local-repo}", is this normal ?

No it's not normal and I also have it (sometimes) but I couldn't find a way to constantly reproduce it.

For eclipse most of the dependencies do not exist in a remote maven repository. Do you think it's possible/make sense to put them e.g. to
the http://repo1.maven.org/maven2 repository (I think this is owned by ASF)? This could avoid the need of keeping them in a 'local-repo' within the studio project.
Anyway I need to fix creation of the emtpy folders.

Now, that you prepared all the packages in their Maven repository format, why not. But I wonder if that will be ok with the repository and the Eclipse Foundation.

Introduced a (temporary) remote repository @ http://people.apache.org/~felixk/studio-eclipse-m2/instead of using the local-reopsitory. 

Versioning">Versioning

I see that all plugins versions are 1.0.2-SNAPSHOT. Each plugin can have a different version number depending on how it has been modified between two releases. Is it possible to have such a behavior ?

Yes, see commit http://directory.markmail.org/message/jldgkywkmrnszus4?q=let+every+subproject+have

Cool... Thanks!

Automatic bundle of src/main/resources/ ?">Automatic bundle of src/main/resources/ ?

I see that in the pom.xml file of the studio-connection-core project, this code is added:

<resource>
    <directory>src/main/resources</directory>
</resource>

I thought Maven automatically bundles src/main/resources when packaging the artifact. Am I wrong ?

Normally it does, but when you overwrite the

<resources>
   ...
</resources>

in the pom.xml you need to indicate all resources there you want to have. Because of the plugin.xml which is located at

/plugin.xml (not standard maven) you need to have at least

<resources>
  <resource>
    <directory>.</directory>
    <includes>
      <include>plugin.xml</include>
    </includes>
  </resource>
</resources>

what overwrites the common resources path and therefore you need to add src/main/resources again (this is at least what I noticed in other projects).

Oh, Ok. Thanks for this explanation. I was not aware of that.