On 25 February 2011 10:38, zoe slattery <[email protected]> wrote: > On 24/02/2011 18:49, Marcin Kuthan wrote: >> >> Hi >> >> If you need different version for API part it should be set up as >> separate project. >> In the API module you probably don't need inherit from myproject-parent. >> >> aggregate >> \_myproject-api >> \_myproject-impl >> \_myproject-subsystem1 >> \_myproject-subsystem2 >> \_myproject-parent >> >> You can release myproject-api and myproject-impl in the independent >> way. myproject-api and myproject-impl modules don't inherit from >> aggregate (rather from corporate pom). > > Hi - thanks. Although I chose myproject-api and myproject-impl as an > example, we have many more bundles and the situation is (in general) not as > clean as just having one -impl depending on one -api, by the way the project > is Apache Aries - see dev@aries for more than you would ever want to read on > the subject:-)
Wow, I found information about Aries in my feed reader a few days ago. Interesting concept. But proposed model should work also for projects with complex structure. You can find general idea in "Maven Reference": http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-multi-vs-inherit Inheritance should not be overused, exactly like in OOP :-) > > I think what you are saying is that the only release process that we can > apply completely generally across all modules and sub-modules is one in > which each bundle (sub-module) is released independently. This seems to be > the conclusion that Felix and Sling have come to. Yep, release cycle should be reflected in the project structure. Please remember that when you release one bundle, all dependencies to other bundles must be already released. Thanks, Marcin --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
