Re: bundleplugin update
Hi, +1 for release. Thanks to you and Carlos. Regards Felix Am Freitag, den 21.12.2007, 00:19 +0800 schrieb Stuart McCulloch: Hi folks, Carlos has released the maven-dependency-tree and maven-osgi shared components (thanks Carlos!) which means there are no more external snapshot dependencies blocking release of the bundleplugin. So we just need to sort out the following releases: org.osgi.service.obr -- maven-obr-plugin -- bundleplugin wrt. open issues: the only one that might delay a release is FELIX-437, but it's a minor issue. To fix it properly it requires a patch to bndlib (so we'd have to wait for Peter to create a new release and get it uploaded to the central repo) - alternatively, we could put a temporary fix in the bundleplugin, but that would be a bit of a kludge... so I'm tempted to fix it after the next release (Karl?) there have been a lot of fixes and new functionality added since the 1.0.0release - and with the latest commons initiative, it would be nice to be able to point people to a release rather than a snapshot ;) WDYT?
Re: [jira] Created: (FELIX-441) Bundle#loadClass logs a FrameworkEvent.ERROR each time a class can not be found
Hi, Thanks Guillaume and Richard for fixing this ! I had similar issues in the JSP support for Apache Sling, where we tried to load classes from bundles and were ready to handle ClassNotFoundException but certainly not a Framework.ERROR. Regards Felix Am Donnerstag, den 20.12.2007, 08:28 -0800 schrieb Guillaume Nodet (JIRA): Bundle#loadClass logs a FrameworkEvent.ERROR each time a class can not be found --- Key: FELIX-441 URL: https://issues.apache.org/jira/browse/FELIX-441 Project: Felix Issue Type: Bug Components: Framework Affects Versions: 1.0.0 Reporter: Guillaume Nodet The specs defines the behavior: If this bundle's state is INSTALLED, this method must attempt to resolve this bundle before attempting to load the class. If this bundle cannot be resolved, a Framework event of type Frame- workEvent.ERROR is fired containing a BundleException with details of the reason this bundle could not be resolved. This method must then throw a ClassNotFoundException. but this behavior is not the one that is implemented.
Re: Felix integration inside Eclipse pages = page
Hi Clement, Hope you don't mind but may be interesting to know that at ops4j we developed an Eclipse plugin called Pax Cursor (based on Pax Runner) that makes deploying of bundles into Felix (both versions till now and the ones to come) quite trivial: http://wiki.ops4j.org/confluence/x/0QBN Alin On Dec 21, 2007 10:48 AM, Clement Escoffier [EMAIL PROTECTED] wrote: Hi all, I wrote two pages about the Felix integration inside Eclipse. The first one was written one year ago, and was clearly not up to date. It explained how to install the Felix trunk inside Eclipse. After Felix was released, I write a second page explaining how to integration the Felix release. So to avoid this duplicated page, I merge them this morning, and delete the oldest one. Clement -- Clement Escoffier Grenoble University +33 (0) 4 76 51 40 24 http://clement.plop-plop.net
Re: Felix integration inside Eclipse pages = page
Did you try 0.1.1 or 0.2.0 SNAPHSOT: http://wiki.ops4j.org/confluence/x/FgJN Alin On Dec 21, 2007 3:13 PM, Clement Escoffier [EMAIL PROTECTED] wrote: Hi, I just try it, it is very cool ! I add it on the wiki page. Clement -Message d'origine- De: Alin Dreghiciu [mailto:[EMAIL PROTECTED] Envoyé: vendredi 21 décembre 2007 10:49 À: dev@felix.apache.org Objet: Re: Felix integration inside Eclipse pages = page Hi Clement, Hope you don't mind but may be interesting to know that at ops4j we developed an Eclipse plugin called Pax Cursor (based on Pax Runner) that makes deploying of bundles into Felix (both versions till now and the ones to come) quite trivial: http://wiki.ops4j.org/confluence/x/0QBN Alin On Dec 21, 2007 10:48 AM, Clement Escoffier [EMAIL PROTECTED] wrote: Hi all, I wrote two pages about the Felix integration inside Eclipse. The first one was written one year ago, and was clearly not up to date. It explained how to install the Felix trunk inside Eclipse. After Felix was released, I write a second page explaining how to integration the Felix release. So to avoid this duplicated page, I merge them this morning, and delete the oldest one. Clement -- Clement Escoffier Grenoble University +33 (0) 4 76 51 40 24 http://clement.plop-plop.net
Re: Coding Standards [was [Quick vote] Coding Standard for Import Statements]
Carsten Ziegeler wrote: I changed the subject for this general discussions, more comments below. Marcel Offermans wrote: If you don't mind, I do have a comment about this quick vote. Sure, I don't mind :) - quiet the opposite :) Let me start by stating that I think that coding standards are important. In fact, I was one of the people who pushed for them and came up with the draft for the first version of the document. However, I think the real discussion we should have is about formatting source code. Do we want to somehow make sure all code is formatted exactly the same? Does this mean we need to standardize on a single IDE or a separate formatting tool? I would like to propose the integration of maven-checkstyle-plugin in order main POM so that we can keep an eye on non-complaint sources. Furthermore, we can store the checkstyle and formatter configuration in our SVN repository, as many projects do. Also by exploiting a common public location (the SVN repository in this case) containing a set of configuration file (both for checksyle and code formatting) we can auto-configure IDEs by an ad-hoc tuned POM. What do you think?
