Hi Stephan,

I thinks I mentioned on a previous email on this topic, but I don't understand 
(and maybe I'm missing some of the OSGI requirements here) why we can't just go 
back to the structure as it was before, basically with only:

- chemistry-opencmis-server-bindings // war and producing attached lib 
chemistry-opencmis-server-bindings-classes.jar as per [1] 
- chemistry-opencmis-server-inmemory // war and producing attached lib 
chemistry-opencmis-server-inmemory-classes.jar as per [1] 

Then the OSGI bundles could depend on the JAR specifically by using the 
appropriate classifier, e.g.:

<dependency> 
   <groupId>org.apache.chemistry</groupId>
   <artifactId>chemistry-opencmis-server-bindings</artifactId>
   <packaging>jar</packaging>
   <classifier>classes</classifier>
</dependency>
 
In this way we can reduce the number of projects and avoid "build only" 
apparent separation of war / lib projects.

WDYT?

Thanks,
Gab

[1] http://maven.apache.org/plugins/maven-war-plugin/faq.html#attached
- 
On Sep 26, 2011, at 1:25 PM, Klevenz, Stephan wrote:

> Hi all,
> 
> I had a closer look into the issues with release 0.5.0 and would like to 
> propose a solution to get it fixed.
> 
> There is one major mistake causing trouble with distribution. Current server 
> project structure is
> 
> chemistry-opencmis-server-bindings // lib
> chemistry-opencmis-server-bindings-war // war
> chemistry-opencmis-server-inmemory // lib
> chemistry-opencmis-server-inmemory-war // war
> 
> This is wrong because of it results in a name change of already existing web 
> application artifacts.
> 
> If we change like this (more or less a re-name of maven modules) then the web 
> application artifacts will be named like before.
> 
> chemistry-opencmis-server-bindings-lib // lib
> chemistry-opencmis-server-bindings // war
> chemistry-opencmis-server-inmemory-lib // lib
> chemistry-opencmis-server-inmemory // war
> 
> The major difference is that classes included previously in web application 
> modules getting their own library artifacts. This is required for OSGi 
> consumption. This libraries are then also consumed by the web applications.
> 
> A *-classes.jar build result within the web application module become 
> obsolete. Classes
> 
> Let me know what do you think. If we get an agreement on this, then I will 
> create an Jira issue and fix it. After that I think we have to create a 
> patched release 0.5.1.
> 
> Sorry for that mistake, but I have completely overseen this.
> 
> Regards,
> Stephan
> 
> 


Reply via email to