Just updated to the latest rev and tried to rebuild the commons-jxpath
projects but got the message:
Error installing artifact: File
/home/jconlon/projects/svns/felix/trunk/commons/commons-jxpath/target/classes
does not exist
Thought it strange so I tried to build the trunk but got a:
I see that functionality has been added to the maven-bundle-plugin for
bundleAll and for generating manifests. How and why would I use the
'manifest' goal in the latest maven-bundle-plugin?
Can anyone give a typical use case and show an example of how to use it?
thanks,
John
Hi Tim,
Glad to see you got it. We should take this out of this local project
pom all together, just like you did. Would you please open a jira on this?
Maven 2.0.5 releases tomorrow? Would be great if our multi-project bug
was fixed in it, but I doubt it as Carlos Sanchez only
Here are a couple suggested of lines of thought. (Caveat these lines of
thought may lead to naught.)
1. Check out the spelling of the two artifactids in the error message.
The two don't match.
I know I have an artifactIdmaven-resources-plugin/artifactId in my
local repo,
I know that the
Stuart McCulloch wrote:
I saw something similar on a colleague's machine (WinXP, using Maven
inside cygwin) - he was unable to build Spring-OSGi even after
removing repository, clean settings.xml, etc. while the same checkout
built fine on my machine (Linux)
These repos can be set in several
Hi Carlos,
There is a subtle maven bug that you should be aware of since you are
working with the plugin.
See:
http://issues.apache.org/jira/browse/FELIX-198
It has bitten us here at felix on several occasions and because of it we
have been forced to use an Ant frontend. :-(
Sure wish it
be happy assist your investigation.
cheers,
John
Carlos Sanchez wrote:
I commented in MNG-1682 I wasn't able to reproduce with the sample
code there
On 2/7/07, John E. Conlon [EMAIL PROTECTED] wrote:
Hi Carlos,
There is a subtle maven bug that you should be aware of since you are
working
Hi Carlos,
So you will label a bundles exports with the version of the jar and
label the bundles import versions with the versions of the dep jars?
John
Carlos Sanchez wrote:
A very important step that is not there yet is the version in the
import-packages, it's very different to depend on
as package's versions though.
John
On 2/1/07, John E. Conlon [EMAIL PROTECTED] wrote:
Hi Carlos,
So you will label a bundles exports with the version of the jar and
label the bundles import versions with the versions of the dep jars?
John
Carlos Sanchez wrote:
A very important step
Richard S. Hall wrote:
John E. Conlon wrote:
Encountering maven bug
http://jira.codehaus.org/browse/MNG-1682 when building the trunk.
This is a subtle bug that often goes
undetected.
To see it you will have to check the console output from the build.
Look at the last line of each build
Carlos Sanchez wrote:
On 1/31/07, Richard S. Hall [EMAIL PROTECTED] wrote:
Chris Custine wrote:
You know, something just occured to me... if the maven repository
starts
getting populated with quite a few jars/bundles, wouldn't it be nice
to have
an OBR sitting on top of it serving up the
Clement Escoffier wrote:
The goal of the original two pom files was to put iPOJO last. I
believe as long as iPOJO is last, then we can avoid the bug. Could
you test that in your workspace? If you can arrange
pom-old-plugin.xml with iPOJO last and avoid the problem, then create
an issue an
.incubator-SNAPSHOT)
[ 3] [Active ] [2] slf4j-api (1.3.0.SNAPSHOT)
[ 4] [Active ] [2] slf4j-nop (1.3.0.SNAPSHOT)
[ 5] [Resolved ] [2] slf4j-osgi-test (1.3.0.SNAPSHOT)
- John
John E. Conlon wrote:
Hi Chris and Richard,
Thanks for the update. Will await your commit
Encountering maven bug
http://jira.codehaus.org/browse/MNG-1682
when building the trunk. This is a subtle bug that often goes
undetected.
To see it you will have to check the console output from the build.
Look at the last line of each build to verify that a proper file
extension was used to
Hi Richard,
The slf4j logging framework is now being offered as OSGi bundles, but
the caveat is that slf4j is using 'Split Packages' and uses
Require-Bundles. Tried the latest build to test these bundles but can't
see all classes in the split packages. I know you were working on
Required-Bundle
chatted with Richard yesterday and he was about
finished so it shouldn't be too much longer.
Chris
On 1/30/07, John E. Conlon [EMAIL PROTECTED] wrote:
Hi Richard,
The slf4j logging framework is now being offered as OSGi bundles, but
the caveat is that slf4j is using 'Split Packages' and uses
Ran across a case where a project bundle was using a Bundle-Classpath
entry with the /target/classes/ value in it's manifest even though it
had no such path in the bundle. As expected Bnd flagged this as an
error.
Over at the spring-osgi maillist someone mentioned this practice as a
way to get
+1
John
On Wed, 2006-12-20 at 12:35 -0500, Richard S. Hall wrote:
The holidays are close, but our work never stops... :-)
We have recently released the 0.8.0-incubator release of Apache Felix.
As such, the PPMC thinks it is time to re-affirm our belief that we are
ready to graduate
On Thu, 2006-12-14 at 12:09 -0500, Richard S. Hall wrote:
John E. Conlon wrote:
Have been working with the new Framework Logging functionality and have
a few related questions regarding it.
1. Have noticed that the Framework Logger ignores the configuration
property felix.log.level
On Tue, 2006-12-05 at 15:49 +0100, Peter Kriens wrote:
I am not a maven expert so maybe there are better ways to do it.
I never understood provided to mean include? If that is the
definition I can automatically include them. Can someone point me to
the relevant literature?
Provided means
Please take a look at the attached pom.xml to this Jira and see if the
format and functionality meets with the groups approval.
If so I intend to issue several more Jira's and attach more commons
wrapping pom.xmls.
thanks,
John
On Fri, 2006-12-01 at 07:43 -0800, John Conlon (JIRA) wrote:
I'd like to put in a plug for the new plugin;-)
One notable functionality versus the old plugin, is that it helps to
reduce the manual entry of exports and thus it reduces pom brittleness
and complexity. (Refactoring of package names will not be as prone to
breaking a bundle.)
The other benefit
On Sat, 2006-11-04 at 07:28 -0500, Richard S. Hall wrote:
If you have some specific libraries you with to volunteer to bundle-
ize,
I can add your name and the libraries to the wiki page for now until
we
decide what our process will be.
Would like to bundleize the following three:
+1
Richard S. Hall wrote:
In order to make progress on a public Felix release, I propose that we
use a simple zip-file release approach as opposed to an
installer-based approach. Please vote on your preference.
[ ] +1 Agree to a zip-file approach for Felix release.
[ ] 0 I don't
On Thu, 2006-11-02 at 17:17 -0500, Richard S. Hall wrote:
Ok, I committed the new Maven Bundle Plugin. I created some docs for the
new plugin here:
http://cwiki.apache.org/FELIX/bundle-plugin-for-maven-bnd.html
I think the plugin is in pretty good shape now. In my opinion, we should
projects
with different packaging.
Regards,
Clement
John E. Conlon a écrit :
Hi Clement,
Saw your email to the maven list:
http://www.mail-archive.com/users@maven.apache.org/msg52547.html
regarding resources being copied to the repository with bad extensions.
Apparently maven
On Fri, 2006-09-08 at 11:40 +0800, Niclas Hedhman wrote:
On Thursday 07 September 2006 23:45, John E. Conlon wrote:
If we:
+ left scope to do the first and second functions above (just like
standard maven projects expect it to do)
+ added a inlinedArtifact element to the dependency
Hi,
On Thu, 2006-09-07 at 08:28 +0200, Felix Meschberger wrote:
On 9/7/06, Niclas Hedhman [EMAIL PROTECTED] wrote:
It essentially mean that we can't leverage the scope for determining
whether
it should be inserted into the Bundle or expected to come from elsewhere.
As far as I
Attempting to migrate a packagingjar/packaging project to
packagingosgi-bundle/packaging using the OSGi plugin, but stumbled
upon a problem with maven transitive dependencies.
The packagingjar/packaging project I am migrating has a set of pom
dependencies already defined as:
dependencies
Does the felix eventAdmin implementation conform to the R4 spec in
regard to registering the 'event.topics' as an array of strings?
113.11.4.5
The value of the property is an array of strings that describe the
topics in which the handler is interested.
Previously I have always registered
Sorry for the typo - That's the event.topics properties...
On Mon, 2006-07-31 at 17:24 -0500, John E. Conlon wrote:
Does the felix eventAdmin implementation conform to the R4 spec in
regard to registering the 'event.topics' as an array of strings?
113.11.4.5
The value of the property
On Mon, 2006-07-10 at 19:52 -0400, Enrique Rodriguez wrote:
Marcel Offermans wrote:
From memory, the service binder is currently the only one still using
kXML 1.x (which has this problematic license). Several other bundles
have already been migrated to kXML 2.x (which has a different
Apologies to all for the inconvenience, I sent this to the wrong list.
John
On Wed, 2006-07-05 at 18:17 -0500, John E. Conlon wrote:
Have been testing ADS in an OSGi environment working with the latest
code in trunks.
When connecting to the server I have noticed the
http
Have been testing ADS in an OSGi environment working with the latest
code in trunks.
When connecting to the server I have noticed the
http://issues.apache.org/jira/browse/DIRSERVER-658
Class cast problem, so I connect with a baseDN to get around that
problem. But when I disconnect I get a
On Tue, 2006-06-13 at 03:45 -0400, Richard S. Hall wrote:
John E. Conlon wrote:
Did not see a real need for Static property but how will this
change effect the ConfigurationProperty versus the DynamicProperty?
Guess I spoke too soon on the Static property not being needed - see
below.
We
On Fri, 2006-06-09 at 05:40 -0400, Richard S. Hall wrote:
Clement Escoffier wrote:
and thank you for the feedback.
Definitely, thanks for taking the time to play with this. It is nice to
get feedback from outsiders, since they tend to find issues that we do
not, since we are too close to
On Tue, 2006-06-06 at 16:08 +0100, Rob Walker wrote:
So, until then there is no way to hide these errors. Perhaps there
is another approach too. One thing that we could do (in addition to
eventually using the log service) is to have a property that allows us
to disable diagnostic
method=stopping/
/component
/iPOJO
Am I setting up the metadata correctly?
cheers,
John
- richard
John E. Conlon wrote:
Have been using ServiceBinder to wrap components while experimenting
with the Configuration Admin service implementation that is in the
ApacheDS sandbox
)
at org.apache.felix.framework.StartLevelImpl.run
(StartLevelImpl.java:179)
at java.lang.Thread.run(Thread.java:595)
Clement or Richard any clues?
John
On Tue, 2006-06-06 at 14:57 -0500, John E. Conlon wrote:
On Tue, 2006-06-06 at 09:03 -0400, Richard S. Hall wrote:
Also, if you are willing to play with more
Have been using ServiceBinder to wrap components while experimenting
with the Configuration Admin service implementation that is in the
ApacheDS sandbox. ServiceBinder is cool but I am having problems
integrating its behavior with that of Configuration Admin.
When the configurations change in a
When Richard tightened the classloading restrictions he added more
verbose logging. Must admit some of the messages are just noise and I
ignore them.
It would be nice to modulate logging to eliminate some or all of the
'noisy' ones.
Here are three variations of 'error' messages that I ignore:
Good idea, less is good. +1.
Niclas, have you seen the problem where the plugin now during the felix
build creates a bad org.osgi.core-0.8.0-SNAPSHOT.jar bundle, by
assigning the BundleActivator itself as the implemenation in the
manifest? (Bundle-Activator: org.osgi.framework.BundleActivator)
-
On Wed, 2006-04-12 at 05:30 -0400, Richard S. Hall wrote:
[EMAIL PROTECTED] wrote:
Perhaps there are other possible diagnostics that could help developers
when they encounter a class loading error.
- richard
Sounds like a very good idea to me.
I also think the suggested
On Tue, 2006-04-11 at 02:42 -0400, Richard S. Hall wrote:
John E. Conlon wrote:
On Mon, 2006-04-10 at 06:21 -0400, Richard S. Hall wrote:
Or are you referring to a situation where you are running
into the bug I mentioned where your bundle does not directly use these
classes but you
On Fri, 2006-03-10 at 09:48 -0500, Noel J. Bergman wrote:
Rob Walker wrote:
Noel J. Bergman wrote:
Can someone make the picture more clear about
differences/similarities between Enterprise
Service Bus (ESB) and OSGi?
What are the similarities and differences between sculpture
On Sun, 2006-01-29 at 02:58, Peter Neubauer wrote:
On Saturday 28 January 2006 19:14, John E. Conlon wrote:
public void setConfiguration(Configuration config)
throws ConfigurationException{){
}
}
Is the setConfiguration method signature correct in the above example
Hi Peter,
On Mon, 2006-01-30 at 13:00, Peter Neubauer wrote:
On Monday 30 January 2006 16:49, John E. Conlon wrote:
Adding the configuration dependencies are a big plus. But have you
considered making the signature more generic?
Mmmh the question is what you want to do with this. We were
Good idea Niclas!
kind regards,
John
On Mon, 2006-01-30 at 19:24, Niclas Hedhman wrote:
On Tuesday 31 January 2006 07:13, John E. Conlon wrote:
Your right, one can always get the dictionary from the Configuration and
the Configuration does provide some utility methods for getting typed
Good 5 Minute overview. Thanks Peter.
One question it mentions
For each dependency:
* Instance fields are set, through reflection, if they exist.
But what if there are multiple dependencies with the same interface -
like the example?
thanks,
John
On Fri, 2006-01-27 at 07:42, Peter
On Fri, 2006-01-27 at 18:53, Marcel Offermans wrote:
But what if there are multiple dependencies with the same interface -
like the example?
Good question. Since there obviously only is one instance field, it will
be set to the highest ranking service implementation. So the field will
Peter,
It is my intention to donate a Provisioning Implementation in addition
to a M2 plugin for creating the zips to felix.
Peter, you mentioned you have a tool for creating Provisioning Zip
files. My M2 plugin seems to be producing valid zips that function for
my implementation, but I would
be added/updated/removed,
and more uncoordinated. However, if the whole configuration just needs
to be wiped out and reset by a central authority, then I agree it is
probably possible to do so using the Initial Provisioning Service.
- richard
John E. Conlon wrote:
IMHO I think the Initial
On Fri, 2006-01-20 at 17:51, Trustin Lee wrote:
Hi all OSGi gurus,
It is great to see you Peter. Your PPT slides helped me a lot when I learn
the basics of OSGi. :)
2006/1/21, Peter Kriens [EMAIL PROTECTED]:
The Initial Provisioning specification is NOT the management agent. It
can
really need this to continue to
test out the tools. I will probably create a test bundle without the
crippled OBRPlugin and move on for now.
cheers,
John
On Tue, 2006-01-10 at 11:18, Richard S. Hall wrote:
John E. Conlon wrote:
Will be deploying a GUI application within felix and would like
On Tue, 2006-01-10 at 10:48, Richard S. Hall wrote:
Enrico Migliore wrote:
The back-end should be a separate project.
I think that the Felix project could definitely include a management
subproject.
Wouldn't this imply already having a Provisioning Service? Are there
any plans,
Will be deploying a GUI application within felix and would like to
administer felix and it's bundles with a gui that I call from within the
application.
What is the current think for how this should be done in felix? Will it
be similar (identical?) to the oscar's shellgui, tablelayout and
The new ImmutablePicoContainerProxyFactory on the PicoContainer trunk now works
fine
when called by DefaultPicoContainer from within an OSGi container.
thanks Jörg,
John
On Wed, 2005-12-28 at 15:23, Jörg Schaible wrote:
John E. Conlon wrote:
Hi Mauro,
Tried
Has anyone used the PicoContainer IOC library successfully with felix?
I've encountered the following exception in felix 0.7.0 when testing a
OSGi bundle that utilizes the PicoContainer IOC library
INFO : 22 : BundleEvent.STARTED
INFO : 24 : BundleEvent.STARTED
1
this helps a bit! :)
Greetings, Marcel
John E. Conlon wrote:
Has anyone used the PicoContainer IOC library successfully with felix?
I've encountered the following exception in felix 0.7.0 when testing a
OSGi bundle that utilizes the PicoContainer IOC library
INFO
Hello Enrique,
Just starting to experiment with the M2, OSGi, and Felix and just
checked out the latest code.
Please update the maven-osgi-plugin-howto.txt to reflect the corrected
POM elements you noted in your email. (Small nit that may save someone
effort in the future.)
thanks,
John
60 matches
Mail list logo
