2009/2/24 Douglas C. Grove <[email protected]> > 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. >
excellent, that's the spirit behind OPS4J :) > 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. > ok if it works everywhere else except Pax-Cursor then it sounds like we need to fix this in Pax-Cursor, so it can handle this sort of layout (in case other Maven users want to use dependencyManagement) 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? > Niclas is looking into it, hopefully you'll have commit access soon > 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 > -- Cheers, Stuart
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
