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 (https://scm.ops4j.org/repos/ops4j/laboratory/users/<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
