Ok, I've managed to create a "features.xml" and install it with
"features:addUrl file:/c:/path/to/my-features.xml"
So, to reiterate, deploying a module into SMX is really as hard as:
a) Edit "org.ops4j.pax.url.mvn.cfg" to add your local repository
b) Create your maven project for building your bundle(s)
c) Create a "features.xml" and define a feature, listing all necessary
dependencies (I wonder how to determine these).
And repeat (work cycle)
1) mvn install
2) features:uninstall/install your-defined-feature-from(c)
If while coding you need a dependency, you must update (c).
This is really the "proper" way?
On 10/3/2010 7:03 μμ, Alexandros Karypidis wrote:
Hello Eoghan,
Thank you very much for your help. I added my local repository as you
suggested and indeed it led to having SMX pick up my modified version
of the cxf-osgi bundle during deployment of "examples-cxf-osgi".
There's still one thing bugging me however: while the above allows me
to do that for a bundle called "cxf-osgi", what happens if I want to
create my own sample project, with another name. Currently, this
method is based on the fact that a proper "feature" is defined in the
"default features.xml" file and overrides the search order of search
repositories so that a "synonymous local bundle" is used.
Ultimately, I suppose I have to degine my own features.xml somehow so
that I could do things like:
<feature name="my-name" version="0.0.1">
<feature version="4.2.0-fuse-01-00">cxf-osgi</feature>
<bundle>mvn:my.example.project/other-bundle-name/0.0.1</bundle>
</feature>
Where would I be able to configure such "features"?
On 10/3/2010 1:08 μμ, Eoghan Glynn wrote:
Yes, you're correct ... a pre-built bundle is picked up by default
from the
$SMX_HOME/system directory, which you can confirm as follows:
ka...@root> log:set TRACE
ka...@root> features:install examples-cxf-osgi
Then look in $SMX_HOME/data/log/karaf.log and you should see a line
like:
10:36:29,361 | TRACE | l Console Thread |
Connection |
.pax.url.mvn.internal.Connection 157 | Downloading [Version
[4.2.0-fuse-01-00] from URL
[file:/work/kits/apache-servicemix-4.2.0-fuse-01-00/system/org/apache/servicemix/examples/cxf-osgi/4.2.0-fuse-01-00/cxf-osgi-4.2.0-fuse-01-00.jar]]
Now this is all controlled by the PAX mvn URL config file
(etc/org.ops4j.pax.url.mvn.cfg) which you can easily change, by
modifying
the following line:
org.ops4j.pax.url.mvn.defaultRepositories=file:${karaf.home}/${karaf.default.reposito...@snapshots
replacing it with something like:
org.ops4j.pax.url.mvn.defaultRepositories=file:///home/alex/.m2/repository,
file:${karaf.home}/${karaf.default.reposito...@snapshots
Then blow away your data directory and repeat the process above, and you
should see the bundle from your local maven repo being pulled in.
Cheers,
Eoghan
On 9 March 2010 23:26, Alexandros Karypidis<[email protected]> wrote:
From what I understand "examples-cxf-osgi" simply deploys a
_pre-built_
example from a maven repository. I want to deploy my own compilation
of the
example, so that I am able to play around, modifying it.
I did locate the cxf-osgi feature inside
http://repo.fusesource.com/maven2/org/apache/servicemix/apache-servicemix/4.2.0-fuse-01-00/apache-servicemix-4.2.0-fuse-01-00-features.xmland
it does pull the pre-compiled example via maven; the relevant fragment
is:
...
<feature name="examples-cxf-osgi" version="4.2.0-fuse-01-00">
<feature version="4.2.0-fuse-01-00">cxf-osgi</feature>
<bundle>mvn:org.apache.servicemix.examples/cxf-osgi/4.2.0-fuse-01-00</bundle>
</feature>
...
On 9/3/2010 11:37 μμ, Eoghan Glynn wrote:
To be fair, the demo README.txt instructs you to deploy via:
features:install examples-cxf-osgi
Now the definition of this feature encodes a dependency on the
cxf-osgi
feature:
<feature name="examples-cxf-osgi" version="4.2.0-fuse-01-00">
<feature version="4.2.0-fuse-01-00">cxf-osgi</feature>
<bundle>mvn:org.apache.servicemix.examples/cxf-osgi/4.2.0-fuse-01-00</bundle>
</feature>
Which is why the instructions don't explicitly state that you must
install
the cxf-osgi feature, the assumption being that this would have been
pulled
in when you installed the examples-cxf-osgi feature as instructed.
Cheers,
Eoghan
On 9 March 2010 19:34, Alexandros Karypidis<[email protected]>
wrote:
Hello,
I'm looking at SMX4.2 (from fusesource actually) and trying to
play with
the examples. I must say, I'm finding the process of deploying
something
into SMX to be a real pain. I've tried both the OSGi packaging
approach
and
had limited success with it. This seems very unusual (deploying
something
shouldn't be that hard), so I'm thinking that I'm missing something.
Here's
my experience with each and I'm hoping someone will step in to
enlighten
a
new user:
Started with "examples/cxf-osgi":
=============================================
1) compiled with: "mvn install"
2) deploy with: "copy target\cxf-osgi-4.2.0-fuse-01-00.jar
c:\fuse42\deploy"
3) NO JOY;
Looking at the CXF servlet (http://localhost:8181/cxf) I see the
service
but is endpoint address ("/HelloWorld") is wrong. I can't access
the WSDL
contract, nor invoke it. So I start looking into things:
4) Hours of pain and trial and error
5) At the Karaf console: "features:install cxf-osgi"
6) JOY!
Suddenly, everything works; apparently the "cxf-osgi feature" was
needed
in
order for the example to work. The feature is declared in "
http://repo.fusesource.com/maven2/org/apache/servicemix/apache-servicemix/4.2.0-fuse-01-00/apache-servicemix-4.2.0-fuse-01-00-features.xml
".
What's strange is that you MUST install it _AFTER_ deploying the
bundle.
If
you start up the ESB, do a "features:install cxf-osgi" and then
copy your
jar into the "deploy" folder, things DO NOT work (it's as if you
just did
the first 3 steps).
So, in order to play with the example, every time I make a change
I must
copy the jar to the deploy folder and re-install the "cxf-osgi"
feature
from
the console. The work development cycle is thus:
1) edit the code
2) "mvn install"
3) copy my.jar c:\fuse42\deploy
4) @karaf: "features:uninstall cxf-osgi"
5) @karaf: "features:install cxf-osgi"
6) check your code to see how it behaves
There must be a better way...