Re: Replacing Proprietary Build System With Maven
2007/9/28, Paul Duffin [EMAIL PROTECTED]: Damien, The majority of my OSGi bundles don't yet provide a service (although they will eventually), I am just porting them from a non OSGi environment in which we typically used reflection to load an implementation of a factory (defined in the API). That means that they typically pack the API and SP together. No problem, it works fine for only one SP. Just to clarify, the API artifact is a normal JAR that contains the API classes yep The SP artifact is an OSGi bundle that contains both the API and the SP classes. It uses the Embed-Dependency instruction from the felix bundle plugin to include the API (selected using package). The scopeprovided/scope will hide the dependency between the bundle and the seperate API artifact. yep I presume that for testing the SC you have a dependency on the SP/API bundle artifact. How do you test the SC, inside an OSGi container or within unit tests ? If the latter how do you do it, do you mock up an OSGi container, break encapsulation and create the service directly, mock up the service ? Both - Automaticaly with unit tests and many mock implementation of API. We use Declarative Services as much as possible not to be coupled with OSGi framework API. That's easier to test - Inside OSGi container, by our testers, with real SP or other mock SP when it's hard to test the real implementation of SP Do you do also have a runtime dependency between SC and SP/API ? I know you don't need one as the SC can use any relevant service. No dependency between SC and SP at all SC depends only on API, it shouldn't not be aware about any SP How do you assemble your application ? With an assembly, which as a submodule of parent pom. The assembly describes the bundles it needs through dependencies : - SC + SP (includes API) - or SC + API + SP Damien Lecan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Replacing Proprietary Build System With Maven
Damien, Thanks very much for all your help. That is very similar to what I want to do. The use of scopeprovided/scope is probably the bit I was missing but I just need to check that it will work as I think it does. The majority of my OSGi bundles don't yet provide a service (although they will eventually), I am just porting them from a non OSGi environment in which we typically used reflection to load an implementation of a factory (defined in the API). That means that they typically pack the API and SP together. Just to clarify, the API artifact is a normal JAR that contains the API classes. The SP artifact is an OSGi bundle that contains both the API and the SP classes. It uses the Embed-Dependency instruction from the felix bundle plugin to include the API (selected using package). The scopeprovided/scope will hide the dependency between the bundle and the seperate API artifact. I presume that for testing the SC you have a dependency on the SP/API bundle artifact. How do you test the SC, inside an OSGi container or within unit tests ? If the latter how do you do it, do you mock up an OSGi container, break encapsulation and create the service directly, mock up the service ? Do you do also have a runtime dependency between SC and SP/API ? I know you don't need one as the SC can use any relevant service. How do you assemble your application ? Damien Lecan wrote: Could you give me an example of how you separate your API and implementation. Do you use separate poms, or within the same pom ? If within the same pom how do you check that only the API is used by other poms ? If in separate poms how do you build the bundle ? There are 2 things in your questions : - how am I deploying my OSGi applications - how am I building my OSGi bundles The second question depends on the 1st one. With OSGi, you can choose where you want to deploy java classes. I can reduce an OSGi application to 3 components : - service consumers (SC) - service descriptions (API) - service producers (SP) Dependencies : SC - API - SP Many packaging solutions can found : all together or each component in its own bundle. Ok, packaging SC + API together is a bad idea, but packaging API + SP can be done. This last solution is a problem only when you can have several SP for the same API. So, basicaly, I have : Parent pom +- SC (depends on API with scope provided) +-API +-SP (depends on API, can embed API if API scope is compile) If you want 3 bundles, don't embed API in SP If you want 2 bundles, embed API in SP (just a pom configuration) Is it what you want ? Damien Lecan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Replacing Proprietary Build System With Maven
Could you give me an example of how you separate your API and implementation. Do you use separate poms, or within the same pom ? If within the same pom how do you check that only the API is used by other poms ? If in separate poms how do you build the bundle ? There are 2 things in your questions : - how am I deploying my OSGi applications - how am I building my OSGi bundles The second question depends on the 1st one. With OSGi, you can choose where you want to deploy java classes. I can reduce an OSGi application to 3 components : - service consumers (SC) - service descriptions (API) - service producers (SP) Dependencies : SC - API - SP Many packaging solutions can found : all together or each component in its own bundle. Ok, packaging SC + API together is a bad idea, but packaging API + SP can be done. This last solution is a problem only when you can have several SP for the same API. So, basicaly, I have : Parent pom +- SC (depends on API with scope provided) +-API +-SP (depends on API, can embed API if API scope is compile) If you want 3 bundles, don't embed API in SP If you want 2 bundles, embed API in SP (just a pom configuration) Is it what you want ? Damien Lecan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Replacing Proprietary Build System With Maven
B API (B-I) depends on artifact A1. B implementation (B-P) depends on the B API (obviously) and transitively on artifact A1. C API (C-I) does not depend on anything. But C implementation (C-P) depends on artifact A2 as well as APIs for B (B-I) and C (C-I) and transitively on artifact A1. Running of the C implementation tests also has a dependency on B-P but compiling of the tests does not. I can easily create a JAR for B and C (I wrote a little plugin that aggregates the classes / resources from children into the parent and then use normal plugins to package it up). The problem is sorting out the dependencies. In the above example the aggregated JAR for B should be dependent on A1 and the aggregated JAR for C should be dependent on A2 and the aggregated JAR for B. Unfortunately, I cannot see how I can modify the dependencies on the fly in order to produce that result. What I would like to do is create an assembly from the aggregated JARs and have that assembly automatically contain the transitive dependencies, e.g. in the above example I would like an assembly with B, C, A1 and A2 but not B-I, B-P, C-I or C-P. If I cannot sort out the dependencies then I lose one big advantage of Maven over out build which is transitive dependency support. The above approach will give me compile time protection against using implementation classes directly and OSGi will give me runtime protection. But it is not perfect because if someone compiles against the aggregated JAR then they could still use the implementation classes even though it would fail at runtime. If the above is not possible then I was wondering whether there was any tool out there that would detect when classes were using 'implementation classes', e.g. by marking API packages with a Java 1.5 annotation and then doing some form of byte code analysis to detect whether a class is using non API classes from other artifacts? If I resummarize, what you want is that building the whole project creates a bundle containing B, C and their transitive dependencies, but not the submodules of B and C. I am pretty sure assembly+dependency could do the trick. Give me a little bit time (one or 2 days) and I will send you a skeleton project doing this (or I will confess miserably my incompetence :)). Or maybe you have that skeleton, a stripped/anonymized version of your project to start with ? Or someone else on the list already has the answer... Best regards, --- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Replacing Proprietary Build System With Maven
Thanks for the reply and excellent clarification. Instead of OSGi bundle just think JAR. I have the structure that you suggested except that I did not use an assembly because I could not see how to create a JAR that only contained the contents of I and P and not all of their dependencies. Not sure to understand yours needs, but did you look at the maven-bundle-plugin from Felix community ? http://cwiki.apache.org/FELIX/maven-bundle-plugin-bnd.html It has been designed to control OSGi packaging (include or not dependencies, generate and validate OSGi Manifest properties, ...) in a maven system. I'm widly using it to build OSGi applications (up to 150 bundles), with separated API, implementations and consumer services ... Damien Lecan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Replacing Proprietary Build System With Maven
Could this be done with the exclude tag in dependency? You would exclude B-I and B-P. -chris -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Insitu Sent: Thursday, September 27, 2007 10:56 AM To: users@maven.apache.org Subject: Re: Replacing Proprietary Build System With Maven B API (B-I) depends on artifact A1. B implementation (B-P) depends on the B API (obviously) and transitively on artifact A1. C API (C-I) does not depend on anything. But C implementation (C-P) depends on artifact A2 as well as APIs for B (B-I) and C (C-I) and transitively on artifact A1. Running of the C implementation tests also has a dependency on B-P but compiling of the tests does not. I can easily create a JAR for B and C (I wrote a little plugin that aggregates the classes / resources from children into the parent and then use normal plugins to package it up). The problem is sorting out the dependencies. In the above example the aggregated JAR for B should be dependent on A1 and the aggregated JAR for C should be dependent on A2 and the aggregated JAR for B. Unfortunately, I cannot see how I can modify the dependencies on the fly in order to produce that result. What I would like to do is create an assembly from the aggregated JARs and have that assembly automatically contain the transitive dependencies, e.g. in the above example I would like an assembly with B, C, A1 and A2 but not B-I, B-P, C-I or C-P. If I cannot sort out the dependencies then I lose one big advantage of Maven over out build which is transitive dependency support. The above approach will give me compile time protection against using implementation classes directly and OSGi will give me runtime protection. But it is not perfect because if someone compiles against the aggregated JAR then they could still use the implementation classes even though it would fail at runtime. If the above is not possible then I was wondering whether there was any tool out there that would detect when classes were using 'implementation classes', e.g. by marking API packages with a Java 1.5 annotation and then doing some form of byte code analysis to detect whether a class is using non API classes from other artifacts? If I resummarize, what you want is that building the whole project creates a bundle containing B, C and their transitive dependencies, but not the submodules of B and C. I am pretty sure assembly+dependency could do the trick. Give me a little bit time (one or 2 days) and I will send you a skeleton project doing this (or I will confess miserably my incompetence :)). Or maybe you have that skeleton, a stripped/anonymized version of your project to start with ? Or someone else on the list already has the answer... Best regards, --- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the Information) is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates (ICAP) or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Replacing Proprietary Build System With Maven
All, I am looking at replacing our proprietary build system with Maven and need some help working out how to do this. The main problem that I have is that in a subsystem (broadly our equivalent of a Maven pom) we have separate API and implementation source trees. Other subsystems that depend on this can only use the API to compile against but can use the implementation to run against. We typically create OSGi bundles from these subsystems and they are configured so that only the API is visible from outside the bundle. Maven does not support that use case and so I have to decide how best to represent this structure. The easiest way is just to combine the API and implementation, however I do not really want to do this because we lose what we consider valuable protection against misuse of private classes. I don't think that I can make Maven support this use case directly within a single pom for a couple of reasons. Firstly, the dependency management is in the core of Maven and is not controlled by a plugin, and secondly while multiple source directories are supported the compiler and jar plugins only appear to support a single directory for all the classes. I have been looking at having separate poms for API and implementation and bundle. I can build the bundle (just think JAR if you don't know what that is) by aggregating the classes/resources from the API and implementation into one directory and then using standard plugins to create it. The problem I have with this is that while building I want to have dependencies on the API poms (as the Java compiler does not know about OSGi bundle exports) but when installing and running I want to have dependencies on the bundle. Does anyone else use this sort of structure, if so how do you manage this in Maven ? Is there anyway to do what I want ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Replacing Proprietary Build System With Maven
All, I am looking at replacing our proprietary build system with Maven and need some help working out how to do this. The main problem that I have is that in a subsystem (broadly our equivalent of a Maven pom) we have separate API and implementation source trees. Other subsystems that depend on this can only use the API to compile against but can use the implementation to run against. We typically create OSGi bundles from these subsystems and they are configured so that only the API is visible from outside the bundle. Maven does not support that use case and so I have to decide how best to represent this structure. The easiest way is just to combine the API and implementation, however I do not really want to do this because we lose what we consider valuable protection against misuse of private classes. I don't think that I can make Maven support this use case directly within a single pom for a couple of reasons. Firstly, the dependency management is in the core of Maven and is not controlled by a plugin, and secondly while multiple source directories are supported the compiler and jar plugins only appear to support a single directory for all the classes. I have been looking at having separate poms for API and implementation and bundle. I can build the bundle (just think JAR if you don't know what that is) by aggregating the classes/resources from the API and implementation into one directory and then using standard plugins to create it. The problem I have with this is that while building I want to have dependencies on the API poms (as the Java compiler does not know about OSGi bundle exports) but when installing and running I want to have dependencies on the bundle. Does anyone else use this sort of structure, if so how do you manage this in Maven ? Is there anyway to do what I want ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Replacing Proprietary Build System With Maven
Paul Duffin [EMAIL PROTECTED] writes: I have been looking at having separate poms for API and implementation and bundle. I can build the bundle (just think JAR if you don't know what that is) by aggregating the classes/resources from the API and implementation into one directory and then using standard plugins to create it. The problem I have with this is that while building I want to have dependencies on the API poms (as the Java compiler does not know about OSGi bundle exports) but when installing and running I want to have dependencies on the bundle. Does anyone else use this sort of structure, if so how do you manage this in Maven ? Is there anyway to do what I want ? Hello, I am not sure I fully understand your problem, and I am not familiar with OSGi bundles, so let me rephrase it: - you have a component C that is broken down into an interface I and an implementation P. You only need I at compile time but need P at runtime. - from a maven perspective, this would mean that you would have astructure like that -- C +-- pom.xml | +-- I +-- pom.xml +-- src +-- P +-- pom.xml +-- src +-- src/main/assembly ... Then I would configure C to build: - I as a standard artifact deployed in a public repo: Other projects would then be allowed to depend on it - P as a standard artifact but deployed in a private repo not available outside the team producing it - C as a pom and with an OSGi bundle (what I call assembly above) deployed and available publicly. Then client components/programs could depend on I for compiling and on C's bundle for running, using a profile. HTH -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
