Guillaume,
Attached to this mail is a modified version of
AddFeaturesToRepoMojo.java. I added two configuration parameters:
- skipNonMavenProtocols: Setting this to true (false is default)
causes the plugin to look for the first occurence of "mvn:" and start
passing the url from there. This enables url's like
"<bundle>ipojo:mvn:se.digia.connect/test-route-template/${project.version}</bundle>".
- skipUrlParameters: Setting this to true (false is default) causes
the plugin to truncate the url if a "#" or a "?" is encountered. This
enables url's like:
"<bundle>war:mvn:se.digia.connect/gui-war/${project.version}/war?Webapp-Context=connect_gui</bundle>"
I haven't contributed to Apache before so you might want to check the
code extra carefully. Note that I haven't modified
ValidateFeaturesMojo.java. I understand that it implements the
validate-features goal. Does it need to be changed too? I haven't used
it so I wouldn't know.
Anyway, the attached version solves the problems I've had so far.
/Bengt
2010/5/6 Bengt Rodehav <[email protected]>:
> I'll take a look at it...
>
> 2010/5/6 Guillaume Nodet <[email protected]>:
>> Mmh, I think I misunderstood what you were trying to achieve.
>> It's because the plugin can be used to actually generate the feature
>> descriptor.
>> If you have an existing feature repository, the plugin can be used to put
>> all the jars
>> in the system folder. And if this fail for other kind of url handlers, it
>> should just do its best and not throw an error.
>> Wanna try to modify the plugin to better support your ipojo and war url
>> handlers ?
>>
>> On Thu, May 6, 2010 at 16:28, Bengt Rodehav <[email protected]> wrote:
>>
>>> Guillaume,
>>>
>>> Think I found the thread you were mentioning. Now I need to learn OBR
>>> as well :-)
>>>
>>> Will using OBR via Karaf features solve the problem I'm trying to
>>> solve? What I want to achieve is to create a local repository (under
>>> my Karaf installation) that includes everything needed without having
>>> to search for it in an external maven repository. I want a self
>>> sustained application. Will OBR solve this?
>>>
>>> /Bengt
>>>
>>> 2010/5/6 Bengt Rodehav <[email protected]>:
>>> > See comments below...
>>> >
>>> > 2010/5/6 Guillaume Nodet <[email protected]>:
>>> >> On Thu, May 6, 2010 at 16:02, Bengt Rodehav <[email protected]> wrote:
>>> >>
>>> >>> Regarding the non" mvn:" protocols, I guess I'll either have to stop
>>> >>> using them as part of features or somehow exclude them fromthe
>>> >>> features-maven-plugin and handle them manually. It's a shame though...
>>> >>> Wouldn't it be a reasonable enhancement to the plugin to be able to
>>> >>> skip leading protocols as long as" mvn:" is present further down the
>>> >>> url?
>>> >>>
>>> >>
>>> >> Well, if we do the enhancement i talked about in another thread, which
>>> is to
>>> >> let
>>> >> OBR kick in and resolve any missing dependency, then the plugin would
>>> not
>>> >> be really helpfull anymore, would it ?
>>> >>
>>> >>
>>> >>>>
>>> >>>> I've totally missed this thread. Will check it out. Do you mean that
>>> the alternate solution (OBR...) you mention will render the
>>> features-maven-plugin unnecessary?
>>> >>>>
>>> >>>
>>> >>> Regarding maven 3, I think it can only be a matter of timing. Sooner
>>> >>> or later it should/must be supported. I think maven 3 compatibility
>>> >>> should also be added to the "todo list" (JIRA I guess).
>>> >>>
>>> >>>
>>> >> Agreed, but if we can't support both at the same time, i'd rather wait
>>> until
>>> >> 3.0 is released.
>>> >>
>>> >>>> I totally understand that. However, I haven't seen that situation
>>> before since maven 3 is designed to be totally backwards compatible. Most of
>>> the time the problems arise when the plugins use some
>>> unsupported/undocumented feature.
>>> >>>>
>>> >>> /Bengt
>>> >>>
>>> >>>
>>> >>> 2010/5/6 Guillaume Nodet <[email protected]>:
>>> >>> > I'm not aware of any effort related to maven 3 yet.
>>> >>> >
>>> >>> > As for the war and ipojo protocols, i don't think it would work well.
>>> >>> The
>>> >>> > features plugin try to generate a list of bundles using the mvn
>>> protocol
>>> >>> > only iirc. And if you use something else, it won't be able to
>>> understand
>>> >>> > and find the required dependencies.
>>> >>> >
>>> >>> > I fear you may run into more problems trying to use the plugin than
>>> >>> > maintaining the feature manually.
>>> >>> >
>>> >>> > On Thu, May 6, 2010 at 14:38, Bengt Rodehav <[email protected]>
>>> wrote:
>>> >>> >
>>> >>> >> I also have another problem with the plugin. I don't seem to be able
>>> >>> >> to run it using maven 3 beta. I get the following error:
>>> >>> >>
>>> >>> >> [ERROR] Failed to execute goal
>>> >>> >> org.apache.felix.karaf.tooling:features-maven-plu
>>> >>> >> gin:1.4.0:add-features-to-repo (add-features-to-repo) on project
>>> >>> assembly:
>>> >>> >> Error
>>> >>> >> populating repository: unknown protocol: null -> [Help 1]
>>> >>> >>
>>> >>> >> Note that I get this error even if I remove all references to
>>> "ipojo:"
>>> >>> >> and "war:". It seems to be a completely different problem. The
>>> plugin
>>> >>> >> works using maven 2.2.1 but we are in the process of migrating to
>>> >>> >> maven 3 and try to make sure that all our pom's work with the beta
>>> >>> >> version. Do you know if anyone have tried the plugin using maven 3?
>>> Is
>>> >>> >> anyone looking into maven 3 support?
>>> >>> >>
>>> >>> >> /Bengt
>>> >>> >>
>>> >>> >>
>>> >>> >> 2010/5/6 Bengt Rodehav <[email protected]>:
>>> >>> >> > Guillaume,
>>> >>> >> >
>>> >>> >> > I think I probably misunderstood how to use the plugin. I wasn't
>>> aware
>>> >>> >> > that all dependencies must be added to the maven project. I was
>>> hoping
>>> >>> >> > that they could be resolved anyway since they are listed in the
>>> >>> >> > features file. When I add all the dependencies, they will be
>>> installed
>>> >>> >> > in my local repo and is accessible to the plugin.
>>> >>> >> >
>>> >>> >> > I've now got almost everything to work expect for the url's that
>>> are
>>> >>> >> > not "mvn:". I also use "ipojo:" and "war:" in my features file, e
>>> g:
>>> >>> >> >
>>> >>> >> >
>>> >>> >>
>>> >>>
>>> <bundle>war:mvn:se.digia.connect/gui-war/${project.version}/war?Webapp-Context=connect_gui</bundle>
>>> >>> >> >
>>> >>> >>
>>> >>>
>>> <bundle>ipojo:mvn:se.digia.connect/test-route-template/${project.version}</bundle>
>>> >>> >> >
>>> >>> >> > How can I get the features-maven-plugin to work with those? At
>>> this
>>> >>> >> > point I'm not actually installing anything in Karaf, which means
>>> that
>>> >>> >> > the protocol in front of "mvn:" ("ipojo:" and "war:") should
>>> actually
>>> >>> >> > be skipped. Is there a workaround for this?
>>> >>> >> >
>>> >>> >> > /Bengt
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > 2010/5/5 Guillaume Nodet <[email protected]>:
>>> >>> >> >> Not sure to fully understand, but if those are dependencies of
>>> your
>>> >>> >> maven
>>> >>> >> >> project, they should be in your local repo, shouldn't they ?
>>> >>> >> >>
>>> >>> >> >> On Wed, May 5, 2010 at 23:02, Bengt Rodehav <[email protected]>
>>> >>> wrote:
>>> >>> >> >>
>>> >>> >> >>> It seems like the features-maven-plugin is exactly what I'm
>>> looking
>>> >>> >> >>> for. However I do run into one problem. I'm using a repository
>>> >>> manager
>>> >>> >> >>> (Nexus) but the features-maven-plugin seems to only look in the
>>> >>> locak
>>> >>> >> >>> repository (which doesn't contain everything). I get the
>>> following
>>> >>> >> >>> error message:
>>> >>> >> >>>
>>> >>> >> >>> [INFO] [features:add-features-to-repo {execution:
>>> >>> >> add-features-to-repo}]
>>> >>> >> >>> Base repo: file://C:/dev/Maven/repository
>>> >>> >> >>> Copy:
>>> commons-pool/commons-pool/1.5.4/commons-pool-1.5.4.jar
>>> >>> >> >>> Copy:
>>> >>> >> >>>
>>> >>> org/apache/felix/karaf/shell/org.apache.felix.karaf.shell.ssh/1.4.0/o
>>> >>> >> >>> rg.apache.felix.karaf.shell.ssh-1.4.0.jar
>>> >>> >> >>> Copy:
>>> >>> >> >>>
>>> >>> org/springframework/osgi/spring-osgi-annotation/1.2.0/spring-osgi-ann
>>> >>> >> >>> otation-1.2.0.jar
>>> >>> >> >>> Copy:
>>> org/ops4j/pax/web/pax-web-api/0.7.2/pax-web-api-0.7.2.jar
>>> >>> >> >>> [INFO]
>>> >>> >> >>>
>>> >>> >>
>>> ------------------------------------------------------------------------
>>> >>> >> >>> [ERROR] BUILD ERROR
>>> >>> >> >>> [INFO]
>>> >>> >> >>>
>>> >>> >>
>>> ------------------------------------------------------------------------
>>> >>> >> >>> [INFO] Error populating repository
>>> >>> >> >>>
>>> >>> >> >>> Can I configure the plugin to use Nexus instead? It's a bit
>>> strange
>>> >>> >> >>> because first everything is being downloaded to Nexus (due to
>>> the
>>> >>> >> >>> dependencies I've added), but then when the plugin kicks in and
>>> the
>>> >>> >> >>> repository is about to be created, only the local repo is being
>>> >>> >> >>> searched.
>>> >>> >> >>>
>>> >>> >> >>> Any ideas?
>>> >>> >> >>>
>>> >>> >> >>> /Bengt
>>> >>> >> >>>
>>> >>> >> >>>
>>> >>> >> >>> 2010/5/5 Bengt Rodehav <[email protected]>:
>>> >>> >> >>> > Thanks a lot Guillaume - I will definitely take a look at the
>>> >>> plugin
>>> >>> >> >>> > you mentioned.
>>> >>> >> >>> >
>>> >>> >> >>> > /Bengt
>>> >>> >> >>> >
>>> >>> >> >>> > 2010/5/5 Guillaume Nodet <[email protected]>:
>>> >>> >> >>> >> We actually have a maven plugin that helps in doing that.
>>> >>> >> >>> >> Take a look at how we package ServiceMix NMR or the full
>>> >>> ServiceMix
>>> >>> >> >>> >> distribution.
>>> >>> >> >>> >> It's based on Karaf, but includes some changes and additional
>>> >>> >> bundles
>>> >>> >> >>> >> configured
>>> >>> >> >>> >> using features. It sounds exactly like what you want.
>>> >>> >> >>> >>
>>> >>> >> http://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/assembly/
>>> >>> >> >>> >>
>>> >>> >> >>> >> The plugin could be enhanced to make this task easier though,
>>> but
>>> >>> >> it's
>>> >>> >> >>> still
>>> >>> >> >>> >> a good
>>> >>> >> >>> >> starting point. The final packaging and other changes are
>>> done
>>> >>> >> using
>>> >>> >> >>> the
>>> >>> >> >>> >> maven
>>> >>> >> >>> >> assembly plugin. Any help / suggestion / patch would be
>>> >>> welcomed !
>>> >>> >> >>> >>
>>> >>> >> >>> >> As for maven, two things:
>>> >>> >> >>> >> * first, if a bundle can be located in the system folder, it
>>> >>> won't
>>> >>> >> try
>>> >>> >> >>> to
>>> >>> >> >>> >> find it in any
>>> >>> >> >>> >> other maven repository, even for a snapshot
>>> >>> >> >>> >> * second, the list of repositories where the maven url
>>> handler
>>> >>> can
>>> >>> >> >>> >> download the
>>> >>> >> >>> >> artifacts from can be configured in
>>> >>> etc/org.ops4j.pax.url.mvn.cfg
>>> >>> >> >>> >> I agree i would not let artifacts be downloaded from the
>>> internet
>>> >>> >> >>> either. A
>>> >>> >> >>> >> nice configuration
>>> >>> >> >>> >> would be to point to a nexus repository manager and the work
>>> >>> there.
>>> >>> >> >>> >>
>>> >>> >> >>> >>
>>> >>> >> >>> >> On Wed, May 5, 2010 at 11:18, Bengt Rodehav <
>>> [email protected]>
>>> >>> >> wrote:
>>> >>> >> >>> >>
>>> >>> >> >>> >>> I'm building an integration platform using Camel deployed in
>>> >>> Karaf.
>>> >>> >> >>> >>> The platform will be used for different kinds of
>>> applications
>>> >>> >> (mainly
>>> >>> >> >>> >>> integration oriented of course). I'm not entirely sure how I
>>> >>> best
>>> >>> >> >>> >>> construct an installation program for these applications.
>>> >>> Basically
>>> >>> >> I
>>> >>> >> >>> >>> need to:
>>> >>> >> >>> >>>
>>> >>> >> >>> >>> a) Install Karaf. This is as easy as unpacking a zip file -
>>> very
>>> >>> >> >>> >>> convenient.
>>> >>> >> >>> >>> b) Configure Karaf. I will change some of the configuration
>>> >>> files
>>> >>> >> and
>>> >>> >> >>> >>> add some. This is not hard.
>>> >>> >> >>> >>> c) Install the bundles needed for my application. This is
>>> where
>>> >>> I
>>> >>> >> need
>>> >>> >> >>> >>> some advice.
>>> >>> >> >>> >>>
>>> >>> >> >>> >>> My bundles are installed in two ways: via startup.properties
>>> and
>>> >>> >> via
>>> >>> >> >>> >>> features defined in org.apache.felix.karaf.features.cfg. The
>>> >>> >> bundles
>>> >>> >> >>> >>> in startup.properties refer to its location in the folder
>>> >>> "system"
>>> >>> >> >>> >>> under the Karaf installation. I will probably define an
>>> >>> additional
>>> >>> >> >>> >>> folder where I will put bundles that I add to
>>> >>> startup.properties.
>>> >>> >> This
>>> >>> >> >>> >>> is to clearly distinguish between the standard Karaf
>>> >>> installation
>>> >>> >> >>> >>> (which I want to be able to upgrade easily) and my
>>> application
>>> >>> >> >>> >>> specific bundles. Don't know how I do this but I imagine it
>>> is
>>> >>> >> >>> >>> configurable somehow.
>>> >>> >> >>> >>>
>>> >>> >> >>> >>> However, most of my required bundles are installed as Karaf
>>> >>> >> features
>>> >>> >> >>> >>> via maven (the url's begin with mvn:). In a development
>>> >>> environment
>>> >>> >> >>> >>> this is very convenient. In a production environment I do
>>> not
>>> >>> want
>>> >>> >> my
>>> >>> >> >>> >>> application to go out on the Internet looking for bundles. I
>>> >>> want
>>> >>> >> it
>>> >>> >> >>> >>> to be totally self sustained. In other words, I want my
>>> >>> >> installation
>>> >>> >> >>> >>> to contain (in a subfolder to the Karaf installation) all
>>> the
>>> >>> >> needed
>>> >>> >> >>> >>> jars/bundles. My problem is how do I generate a folder
>>> >>> containing
>>> >>> >> all
>>> >>> >> >>> >>> my required bundles from a list of features (with the "mvn:"
>>> >>> url)?
>>> >>> >> >>> >>> Ideally I would list the features I want and then
>>> automatically
>>> >>> >> >>> >>> generate a folder containing all the referred bundles. I
>>> would
>>> >>> then
>>> >>> >> >>> >>> include this folder in my installation.
>>> >>> >> >>> >>>
>>> >>> >> >>> >>> Has anyone solved this problem (going from development to
>>> >>> >> production
>>> >>> >> >>> >>> using Karaf)? What is best practice?
>>> >>> >> >>> >>>
>>> >>> >> >>> >>> /Bengt
>>> >>> >> >>> >>>
>>> >>> >> >>> >>>
>>> >>> >>
>>> ---------------------------------------------------------------------
>>> >>> >> >>> >>> To unsubscribe, e-mail: [email protected]
>>> >>> >> >>> >>> For additional commands, e-mail:
>>> [email protected]
>>> >>> >> >>> >>>
>>> >>> >> >>> >>>
>>> >>> >> >>> >>
>>> >>> >> >>> >>
>>> >>> >> >>> >> --
>>> >>> >> >>> >> Cheers,
>>> >>> >> >>> >> Guillaume Nodet
>>> >>> >> >>> >> ------------------------
>>> >>> >> >>> >> Blog: http://gnodet.blogspot.com/
>>> >>> >> >>> >> ------------------------
>>> >>> >> >>> >> Open Source SOA
>>> >>> >> >>> >> http://fusesource.com
>>> >>> >> >>> >>
>>> >>> >> >>> >
>>> >>> >> >>>
>>> >>> >> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> >> >>> To unsubscribe, e-mail: [email protected]
>>> >>> >> >>> For additional commands, e-mail: [email protected]
>>> >>> >> >>>
>>> >>> >> >>>
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >> --
>>> >>> >> >> Cheers,
>>> >>> >> >> Guillaume Nodet
>>> >>> >> >> ------------------------
>>> >>> >> >> Blog: http://gnodet.blogspot.com/
>>> >>> >> >> ------------------------
>>> >>> >> >> Open Source SOA
>>> >>> >> >> http://fusesource.com
>>> >>> >> >>
>>> >>> >> >
>>> >>> >>
>>> >>> >>
>>> ---------------------------------------------------------------------
>>> >>> >> To unsubscribe, e-mail: [email protected]
>>> >>> >> For additional commands, e-mail: [email protected]
>>> >>> >>
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > Cheers,
>>> >>> > Guillaume Nodet
>>> >>> > ------------------------
>>> >>> > Blog: http://gnodet.blogspot.com/
>>> >>> > ------------------------
>>> >>> > Open Source SOA
>>> >>> > http://fusesource.com
>>> >>> >
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: [email protected]
>>> >>> For additional commands, e-mail: [email protected]
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> Cheers,
>>> >> Guillaume Nodet
>>> >> ------------------------
>>> >> Blog: http://gnodet.blogspot.com/
>>> >> ------------------------
>>> >> Open Source SOA
>>> >> http://fusesource.com
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
