Hi Stuart, Thanks you for your response.
I have been looking at the code, I'd like to post some modifications. Hopefully I can do that soon. Skipping down to the bundle start ordering, this is really cosmetic in that I like to start the confman and props loader first. This keeps the log hemorrhage to a minimum. My logging config has WARN as the default and my packages are set to DEBUG. When everything is at the same start level under framework control, I get an enormous amount of DEBUG logging until Pax Logging gets its configuration updated. As to the Pax versions being used, I checked and I am current on everything. Also, I have un-commented out the dependency on the provision pom. Skipping down to the dependencyManagement guidance, I have tried that. Same problem. "mvn pax:provision" works just fine, "mvn eclipse:clean pax:eclipse" also works just fine. However the Pax Cursor plugin in Eclipse can not resolve the versions from my provision pom.xml. I tried adding my top level pom to the cursor configuration, but that didn't help. Finally, I have tried a couple of times to add myself to the repository. https://scm.ops4j.org/repos/ops4j/laboratory/users/dgrove I get asked for the user ID and password, but I just get authentication errors. I looked at: http://wiki.ops4j.org/display/ops4j/Source+Control+System darned if I can get it to let me create folder ... Any thoughts? Thanks again, Doug On Mon, 2009-02-23 at 14:42 +0800, Stuart McCulloch wrote: > 2009/2/18 Douglas C. Grove <[email protected]> > Good afternoon everyone, > > Hi Doug, > > I'm doing OSGi development with Spring-DM and the PAX > tooling. First > let me give a big "Thank You" to the PAX team. The tooling > does make my > life a lot easier. > > I have some thoughts on the tooling, hopefully I will not > embarrass > myself too much... > > So I use the PAX construct, runner and cursor Eclipse plug > in. I have > the standard provision, compiled bundle settings, wrapped jar > settings > and my bundles. > > I tried the PAX profiles in my top level pom file, these > deploy Spring > DM and logging and confman just fine. As noted recently on > the mailing > list, these don't let you set versions, so you get what you > get. This > is a problem for me as I do need to set the versions. > > feel free to raise a Pax-Runner feature request on JIRA to support > profile versions, > of course with OPS4J you can always fix the code yourself if you > happen to need it > before anyone else gets round to looking at the issue :) > > Also, when I run my "mvn pax:eclipse" the bundles from the > profiles are not added to my > classpath in Eclipse. Am I missing something here? > > that's correct, because the profiles are runtime settings to > Pax-Runner - in order to > add them to the classpath we'd need a way to query Pax-Runner to find > out which > Maven artifacts are in each profile (that may be possible, but I'm not > 100% sure) > > otherwise you'll need to use pax-import-bundle to bring the various > bundles into > the project - when you use pax:eclipse these imported bundles will be > unpacked > and have basic Eclipse project files added to them > > So I add them with a scope of "provided", but this seems to be > unnecessary. > > well to support this we'd probably end up adding them too (just > automatically) > > > I finally gave up on the profiles and now list the bundles > that I want in my provision > pom.xml. > > correct, that's where the imported bundles are typically listed - you > can also list > imported bundles in any of the "leaf" bundle projects, if you don't > want them to > appear on the global imported classpath (more on this later...) > > This has the added benefit of having more control of the > bundle loading > order as the bundles are loaded in the order listed in the > provision > pom.xml. This was also noted recently on the mailing list > that there > does not appear to be a way to set the start order in a maven > pom.xml > file. You can do it from cursor in Eclipse, but not from the > pom.xml. > > yes - the Maven schema doesn't support adding any sort of startlevel > metadata > to the dependency list (only certain elements and attributes are > allowed) which > means the only ordering we can apply is the ordering in the pom - > however, this > still means they'll run in the same startlevel so any ordering is > actually up to the > framework (ie. they don't have to respect the declared order in a > given level) > > > So, fine, now I have my dependencies in the provision pom > file. > Unfortunately, dependencies scoped as test don't seem to > contribute to > the classpath. > > which version of the maven-pax-plugin are you using, and are these > test scoped > dependencies in the bundle pom or the provisioning pom? The > "provision" pom > bundles are only added to a bundle's classpath when you remove the > comments > from the following pom dependency in the generated bundle pom: > > <dependencies> > <!-- > | uncomment to add all imported (non-local) bundles to your > compilation classpath > <dependency> > <type>pom</type> > <groupId>${parent.groupId}</groupId> > <artifactId>provision</artifactId> > <optional>true</optional> > </dependency> > --> > </dependencies> > > this is because of how Maven POM inheritance works - the default > project > inheritance (*not* directory hiearchy) used in Pax-Construct is as > follows: > > <root> ___ poms ___ compiled ___ compiled bundle A > | | |________ compiled bundle B > | | > | |______ wrappers ___ junit wrapper > | |________ asm wrapper > | > |_____________________________ provision > > note that in Maven inheritance is separate from aggregation, ie. you > can have > compiled bundles grouped into all sorts of directories but their > parent POM will > be the "compiled" POM (FYI, this avoids all sorts of inherited plugin > nastiness) > > so you can see that compiled bundles will pick up dependencies in > either the > <root>, "poms", or "compiled" POM but *not* the "provision" POM - this > was > done by design to keep the deployment setup separate from the > compilation > classpath (there are several use cases where mixing the two causes > issues, > and unfortunately in Maven it's impossible to remove inherited > dependencies) > > therefore a POM dependency was added to the generated bundle projects > (commented out by default). Uncommenting this entry would add the > global > "provision" classpath to the bundle's compilation classpath. > > > I had to put my test scoped dependencies in the compiled > bundle settings pom.xml? This works, the bundles show up on > the > classpath, but I would prefer to only have build settings in > that pom > file. > > see above diagram > > I would also like to have dependencies in my projects pom > files deployed > automatically. As an example, I have web service client > bundles in my > communications project as dependencies. These are not > deployed unless > they are listed in the provision pom.xml. > > any non-optional non-test bundle in the project should get deployed - > at least > if you're using the latest release of the maven-pax-plugin (1.4) and > have run > "mvn pax:provision -U" to make sure you've picked up the latest > Pax-Runner. > > if you're still unable to deploy (unless you put them in the provision > pom) then > please raise an issue along with an example project that we can build > + test > > or take a look at the provision mojo code, as it's fairly > straightforward: > > > https://scm.ops4j.org/repos/ops4j/projects/pax/construct/maven-pax-plugin/src/main/java/org/ops4j/pax/construct/lifecycle/ProvisionMojo.java > > > Similarly, I have a web UI project that needs servlet api > 2.4. The servlet dependency must also be listed in the > provision pom.xml. So when I run "mvn pax:eclipse" > non-web based projects end up with servlet api in their > classpath. I > figure that I must just be doing something fundamentally > wrong. > > how come non-web based projects are picking up dependencies from > the "provision" pom? I thought you were having trouble seeing these at > all - it sounds like you've added the dependency elsewhere in the pom > hierarchy (like the "compiled" pom) which means all compiled bundles > will pick it up - ironically this is exactly the reason why the > provision pom > is kept from the main global compilation classpath > > > I have dependencies in multiple pom.xml files. As noted > above, these > are in provision, compiled bundle settings and my project > poms. In > order to manage version dependencies for Felix, Spring-DM and > many other > things, I have properties for versions defined in my top level > pom file. > > the recommended Maven way to manage dependency versions is with a > <dependencyManagement> section in one of the top-level project poms, > you can then omit the dependency versions from any pom that inherits > it. > > for an example look at the "poms" pom, which has the OSGi dependency > versions - you'll notice that the generated poms for compiled bundles > do > not need to give versions for these dependencies > > > However, in Eclipse and Cursor, I need to include the > provision pom so > that all of the needed bundles will get deployed. > Unfortunately, the > versions that are defined in my top level pom file are not > found, so > using ${pax.logging.ver} in the provision pom gives an error > at > deployment time. This forces me to duplicate the properties > in the top > level pom in provision pom. This is a bit ugly. > > again, much better to use <dependencyManagement> see the Maven > book over at http://www.sonatype.com/book/ for more best practices > > also note that you can have multiple "provision" poms if you really > want > to split dependencies between web and non-web bundles - the mojo > code looks for pom packaging projects with artifactId of "provision" - > so you could have a "web/provision/pom.xml", etc. > > however, you may need to manually massage the poms to do this because > this is an advanced Maven structure that isn't covered by the current > pom > manipulation tools in Pax-Construct... > > you might also want to commit an example project under the OPS4J lab > area (<name>) so that > people can take a look and recommend best practices / improvements > > HTH > > > Apologies for the long post, any insight or guidance would be > deeply > appreciated, > > Doug > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > > -- > Cheers, Stuart > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
