cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Planning 2.2 [was: Re: [2.2] Using includes in the sitemap for components?]
Date Mon, 05 Sep 2005 08:33:19 GMT
Ralph Goers wrote:
>>How much do we know about the directory structure required by Maven? I 
>>know that OSGi R3 requires a directory structure, R4 doesn't. However, 
>>one package per bundle would make implementation much easier.
> Unfortunately, my knowledge only extends to Maven 1.  Carsten would have 
> to answer this as he has been working on the conversion to Maven 2.  It 
> doesn't look like he has had to do much so far, but I'm still worried 
> that circular dependencies between blocks are going to show up.
Currently we don't have circular dependencies, so the current structure
will work with maven as well. Now m1 and m2 do not differ that much when
it comes to the directory structure: one java source directory per
project, several resource directories (if you need), on directory for
java tests etc. So this works pretty well for our current blocks.
If we want to split blocks into api and impl for example, we have to
create two maven projects - this of course then will also reduce
problems with circular dependencies.
I don't know if we need something else for osgi, but I think this
approach (api vs impl) should work there as well.

>>I just want to avoid any "we can't release X because we're waiting for 
>>feature Y", that is something we've stumbled with all too often.
> Yes, I would like to avoid that as well.  However, I don't know that we 
> need to be using a formally released Maven 2 to know how to do this.
I think time will tell. Switching to maven is currently at a very low
rate, not many of us are working on it (which is ok of course), the same
happens to the OSGi stuff. We shouldn't delay 2.2 neither because of
waiting for m2 nor waiting for OSGi. The current version seems to work
and build system works as well.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message