[jira] Resolved: (FELIX-1207) [PATCH] Ignore files generated by mvn:eclipse

2009-10-19 Thread Guillaume Nodet (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FELIX-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1207.


   Resolution: Fixed
Fix Version/s: karaf-1.0.2
 Assignee: Guillaume Nodet

Sendingkaraf/jaas/boot
Sendingkaraf/jaas/config
Sendingkaraf/jaas/modules
Sendingkaraf/manual
Sendingkaraf/shell/admin
Sendingkaraf/shell/commands
Sendingkaraf/shell/config
Sendingkaraf/shell/console
Sendingkaraf/shell/obr
Sendingkaraf/shell/osgi
Sendingkaraf/shell/packages
Sendingkaraf/shell/ssh
Sendingkaraf/shell/wrapper
Sendingkaraf/tooling

Committed revision 826976.


> [PATCH] Ignore files generated by mvn:eclipse
> -
>
> Key: FELIX-1207
> URL: https://issues.apache.org/jira/browse/FELIX-1207
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Robert Burrell Donkin
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.2
>
> Attachments: karaf-maven-eclipse.patch
>
>
> The maven eclipse plugin is a very useful way to generate a project. 
> Unfortunately, it creates a lot of files which are not currently ignored by 
> subversion.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [fileinstall] review changes before release

2009-10-19 Thread Pierre De Rop 
please, refer to the new jira issue: FELIX-1776 



Regards;
/pierre

Guillaume Nodet wrote:

I've done some testing, but I can't really reproduce the exact behavior.
Here's what I have:

14:15:53,978 | DEBUG | lixDispatchQueue | fileinstall
| ?   ? | BundleEvent RESOLVED
14:15:54,017 | INFO  | nerated-bundles} | fileinstall
| ?   ? | {felix.fileinstall.poll
(ms) = 1000, felix.fileinstall.dir =
/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/deploy,
felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start =
true, felix.fileinstall.tmpdir =
/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/data/generated-bundles,
felix.fileinstall.filter = null}
14:15:54,017 | INFO  | FelixStartLevel  | fileinstall
| ?   ? | Starting initial scan
14:15:54,032 | INFO  | nerated-bundles} | fileinstall
| ?   ? | Started bundle:
file:/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/deploy/org.apache.felix.karaf.shell.obr-1.1.0-SNAPSHOT.jar
14:15:54,034 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent RESOLVED
14:15:54,035 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent STARTED
14:15:55,006 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent STOPPED
14:15:55,007 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent UNRESOLVED
14:15:55,007 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent UPDATED
14:15:55,022 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent RESOLVED
14:15:55,024 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent STARTED
14:15:55,024 | INFO  | nerated-bundles} | fileinstall
| ?   ? | Updated
/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/deploy/org.apache.felix.karaf.shell.obr-1.1.0-SNAPSHOT.jar
14:15:55,025 | DEBUG | lixDispatchQueue | framework
| ?   ? | FrameworkEvent PACKAGES
REFRESHED

The above log is a trimmed down version of karaf after a restart with
an update on the obr bundle located in the deploy folder between the
stop and restart.

What happens is that when the framework is restarted, the deployed
bundle is started by the framework.  When fileinstall is then started,
it will update the obr bundle (so it will be stopped and restarted).

One possible thing that may happen is some kind of interaction between
the start level service and fileinstall.  But if the start level of
the bundle is higher than the current start level, the framework
should not really start the deployed bundle when fileinstall asks to
do so until the start level has been raised.  So I don't think there
is any possible issue here.

Can you check from your side ?

On Sat, Oct 17, 2009 at 09:04, Pierre De Rop
 wrote:
  

Hello Guillaume,

I did some testing on the latest fileinstall, from the trunk.
Specifically, I tested the resolved issue from FELIX-1578 and the problem
has disappeared.

However, I noticed another (different) problem when performing the test (not
sure if I must create another jira issue, or not ?).
Here is what I did when testing:

1)   clean the fwk bundle-cache (the fwk is not running)
2)   copy a test bundle in the fileinstall's deploy directory
3)   touch -t 0101 deploy/test.jar (so, the lastModified date of
test.jar is Jan, 1st 2009)
4)   I start the fwk -> test.jar is installed
5)   I stop the fwk
6)   I recompile the test.jar bundle (I just manage to ensure that test.jar
has now a different checksum), and I modify the timestamp with "touch -t
0201 deploy/test.jar" (the timestamp is now Feb 1st, 2009)
7)   I restart the fwk (without cleaning the cache)
7.1) the test.jar bundle is properly *updated* and started (the patch
FELIX-1578 works fine)
7.2) *however, after a few milliseconds, test.jar is stopped and then
restarted.*

Don't you think that fileinstall uselessly restarts test.jar during the step
7.2 ?

/pierre

Guillaume Nodet wrote:


I've fixed a lots of jira issues this week on fileinstall, so I'd
welcome a bit more testing before preparing a release next week or
so...


  

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.







  



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[jira] Updated: (FELIX-1776) FileInstall starts already installed bundles twice

2009-10-19 Thread Pierre De Rop (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FELIX-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre De Rop updated FELIX-1776:
-

Attachment: fileinstall-patch.tgz

attached the proposed patch

> FileInstall starts already installed bundles twice
> --
>
> Key: FELIX-1776
> URL: https://issues.apache.org/jira/browse/FELIX-1776
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Reporter: Pierre De Rop
> Attachments: fileinstall-patch.tgz
>
>
> This issue is described here: 
> http://www.mail-archive.com/dev@felix.apache.org/msg13194.html
> When the fwk is started without cleaning the cache, and when some bundles are 
> already installed,
> then fileinstall starts them twice.
> Here is what I did in order to reproduce the problem
> - I first did a simple "Test" bundle with the following activator:
> public class Activator implements BundleActivator {
>   public void start(BundleContext ctx) throws Exception {
> System.out.printlnp("start/version 1.0");
>   }
>   public void stop(BundleContext ctx) throws Exception {
> System.out.printlnp("stop/version 1.0");
>   }
> - in my "bundle" directory, I have:
> org.apache.felix.shell.tui-1.5.0-SNAPSHOT.jar
> org.apache.felix.shell-1.5.0-SNAPSHOT.jar
> org.apache.felix.bundlerepository-1.5.0-SNAPSHOT.jar
> org.apache.felix.fileinstall-2.0.3-SNAPSHOT.jar
> org.apache.felix.configadmin-1.2.7-SNAPSHOT.jar
> - in the directory which fileinstall polls for updated bundles, I only have 
> my simple test.jar bundle:
> ls ./deploy
> test.jar
> - Now, I start the fwk (from the trunk) with a cleaned cache:
> rm -rf felix-cache
> java -jar bin/felix.jar
> {felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = 
> /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, 
> felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, 
> felix.fileinstall.filter = null}
> ->
> -> Installed deploy/test.jar
> start/version 1.0
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> - I stop the fwk, and recompile my test bundle
> - I restart the fwk, without cleaning the cache, and I have this
> java -jar bin/felix.jar
> Welcome to Felix
> 
> {felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = 
> /home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, 
> felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, 
> felix.fileinstall.filter = null}
> Updated /home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> start/version 1.1
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> -> A bundle with the same symbolic name (test.dm) and version (1.0) is 
> already installed.  Updating this bundle instead.
> stop/1.1
> start/1.1
> Installed deploy/test.jar
> Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
> I have attached a proposed patch to this issue, but please read it carefully 
> because I am not sure about it.
> Indeed, I suspect that the problem comes from the Scanner.run method, where 
> the "storedChecksums" is removed from the map:
> for (Iterator it = removed.iterator(); it.hasNext();)
> {
> File file = (File) it.next();
> // Make sure we'll handle a file that has been deleted
> files.addAll(removed);
> // Remove no longer used checksums
> lastChecksums.remove(file);
> storedChecksums.remove(file); -> why doing so ? The getChecksum 
> methods will returns 0
> }
> Because of the "storedChecksums.remove(file)" call, the 
> scanner.getChecksum(File f) method always returns 0.
> However, I'm not sure if this is really the bug, but because of this checksum 
> removal, DIrectoryWatcher is no longer able to retrieve the correct checksum 
> for tracked bundles.
> So, I did the following safe patches in DirectoryWatcher.java and everything 
> sounds to work fine now:
> (in fact, I always call scanner.checksum(File) instead of 
> scanner.getChecksum(File) ...)
> svn diff 
> src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java
> @@ -297,7 +297,11 @@  
>
>  // File has been modified
>
>  if (exists && artifact != null)  
>
>  {
>
> -artifact.setChecksum(scanner.getChecksum(file)); 
>
> +if (artifact.getChecksum() == scanner.checksum(file)) {  
>
> +contin

[jira] Created: (FELIX-1776) FileInstall starts already installed bundles twice

2009-10-19 Thread Pierre De Rop (JIRA) 
FileInstall starts already installed bundles twice
--

 Key: FELIX-1776
 URL: https://issues.apache.org/jira/browse/FELIX-1776
 Project: Felix
  Issue Type: Bug
  Components: File Install
Reporter: Pierre De Rop


This issue is described here: 
http://www.mail-archive.com/dev@felix.apache.org/msg13194.html

When the fwk is started without cleaning the cache, and when some bundles are 
already installed,
then fileinstall starts them twice.

Here is what I did in order to reproduce the problem

- I first did a simple "Test" bundle with the following activator:

public class Activator implements BundleActivator {
  public void start(BundleContext ctx) throws Exception {
System.out.printlnp("start/version 1.0");
  }

  public void stop(BundleContext ctx) throws Exception {
System.out.printlnp("stop/version 1.0");
  }

- in my "bundle" directory, I have:

org.apache.felix.shell.tui-1.5.0-SNAPSHOT.jar
org.apache.felix.shell-1.5.0-SNAPSHOT.jar
org.apache.felix.bundlerepository-1.5.0-SNAPSHOT.jar
org.apache.felix.fileinstall-2.0.3-SNAPSHOT.jar
org.apache.felix.configadmin-1.2.7-SNAPSHOT.jar

- in the directory which fileinstall polls for updated bundles, I only have my 
simple test.jar bundle:

ls ./deploy
test.jar

- Now, I start the fwk (from the trunk) with a cleaned cache:

rm -rf felix-cache
java -jar bin/felix.jar

{felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = 
/home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, 
felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, 
felix.fileinstall.filter = null}
->
-> Installed deploy/test.jar
start/version 1.0
Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar

- I stop the fwk, and recompile my test bundle

- I restart the fwk, without cleaning the cache, and I have this

java -jar bin/felix.jar

Welcome to Felix


{felix.fileinstall.poll (ms) = 2000, felix.fileinstall.dir = 
/home/nxuser/work/osgi/felix-trunk/main/deploy, felix.fileinstall.debug = -1, 
felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir = ./tmp, 
felix.fileinstall.filter = null}
Updated /home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
start/version 1.1
Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar
-> A bundle with the same symbolic name (test.dm) and version (1.0) is already 
installed.  Updating this bundle instead.
stop/1.1
start/1.1
Installed deploy/test.jar
Started bundle: file:/home/nxuser/work/osgi/felix-trunk/main/deploy/test.jar


I have attached a proposed patch to this issue, but please read it carefully 
because I am not sure about it.
Indeed, I suspect that the problem comes from the Scanner.run method, where the 
"storedChecksums" is removed from the map:


for (Iterator it = removed.iterator(); it.hasNext();)
{
File file = (File) it.next();
// Make sure we'll handle a file that has been deleted
files.addAll(removed);
// Remove no longer used checksums
lastChecksums.remove(file);
storedChecksums.remove(file); -> why doing so ? The getChecksum 
methods will returns 0
}

Because of the "storedChecksums.remove(file)" call, the 
scanner.getChecksum(File f) method always returns 0.
However, I'm not sure if this is really the bug, but because of this checksum 
removal, DIrectoryWatcher is no longer able to retrieve the correct checksum 
for tracked bundles.

So, I did the following safe patches in DirectoryWatcher.java and everything 
sounds to work fine now:
(in fact, I always call scanner.checksum(File) instead of 
scanner.getChecksum(File) ...)

svn diff 
src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java
@@ -297,7 +297,11 @@
 
 // File has been modified  
 
 if (exists && artifact != null)
 
 {  
 
-artifact.setChecksum(scanner.getChecksum(file));   
 
+if (artifact.getChecksum() == scanner.checksum(file)) {
 
+continue;  
 
+}  
 
+   
 
+artifact.setChecksum(scanner.checksum(file));  
 
 // If there's no listener, this is because this artifact 
has been installed before

[jira] Commented: (FELIX-1574) Some Karaf instances never reach the 'started' state

2009-10-19 Thread Guillaume Nodet (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767725#action_12767725
 ] 

Guillaume Nodet commented on FELIX-1574:


AFAIK, this issue has been fixed some time ago.  Could you double check and 
close this issue if it's ok ?

> Some Karaf instances never reach the 'started' state
> 
>
> Key: FELIX-1574
> URL: https://issues.apache.org/jira/browse/FELIX-1574
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Affects Versions: karaf-1.0.0
>Reporter: David Bosschaert
>
> Instances crested from the default karaf instance shell never show up as 
> started
> Here's how it's reproduced:
> 1. create an instance from command line
> 2. start that instance from the command lie
> 3. start default karaf instance
> (this throws up an JMX/RMI exception)
> 4. create & start another instance form within the default karaf one
> now the admin list shows the other new one as 'starting'
> both in karaf as well as from the command line
> An interesting observation is that these instances get created in 
> /bin/instances instead of /instances
> BTW: The CWD when I started karaf was /bin

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (FELIX-1263) Documentation fixes for http://felix.apache.org/site/61-extending-the-console.html

2009-10-19 Thread Guillaume Nodet (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FELIX-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet closed FELIX-1263.
--

Resolution: Fixed

I've update this page last week.

> Documentation fixes for 
> http://felix.apache.org/site/61-extending-the-console.html
> --
>
> Key: FELIX-1263
> URL: https://issues.apache.org/jira/browse/FELIX-1263
> Project: Felix
>  Issue Type: Bug
>  Components: Documentation, Karaf
> Environment: neutral
>Reporter: Hendy Irawan
>
> In docs : http://felix.apache.org/site/61-extending-the-console.html
> 1.
> mvn archetype:create \
>   -DarchetypeArtifactId=maven-archetype-quickstart \
>   -DgroupId=org.apache.servicemix.gshell.samples \
>   -DartifactId=gshell-commmands \<--- has a typo here, 
> reduce 1 'm'
>   -Dversion=1.0-SNAPSHOT
> 2. Update the dependency list for gshell.core and spring-osgi:
> 
> org.apache.felix
> org.osgi.core
> 1.2.0
> provided
>   
>   
> org.apache.servicemix.kernel.gshell
> org.apache.servicemix.kernel.gshell.core
> 1.1.0
>   
>   
> org.springframework.osgi
> spring-osgi-core
> 1.2.0
>   
> 3. "Add the Spring Milestone Repository " step should not be needed, simply 
> use dependency spring-osgi version 1.2.0 (already GA).
> 4. The  part has invalid  fragment, should be removed. 
> Moreover, I have to add additional Import-Package and Export-Package 
> manifest, so it becomes:
> 
> 
>   
> org.apache.felix
> maven-bundle-plugin
> 
> true
> 
>   
> 
> org.apache.geronimo.gshell.command,org.apache.geronimo.gshell.wisdom.command,org.apache.geronimo.gshell.wisdom.registry,org.apache.servicemix.kernel.gshell.core,*
> 
> org.apache.servicemix.gshell.sample.*
> 
> *;publish-context:=false;create-asynchronously:=false
>   
> 
>   
> 
>   
> 5. Add a note that package names may change in the future due ServiceMix 
> Kernel becoming Felix Karaf subproject including the GShell

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Releasing web console 2.0.2

2009-10-19 Thread Guillaume Nodet 
I'd like to cut a release of webconsole 2.0.2 to fix the nasty
synchronization issue which affects security (where the configured
user/passwd is sometimes ignored).
Unless there is any objection, I'll cut a release later today or tomorrow.

-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: [VOTE] Release fileinstall 2.0.2

2009-10-19 Thread Guillaume Nodet 
+1

On Mon, Oct 19, 2009 at 18:18, Guillaume Nodet  wrote:
> This release includes
>   * fileinstall 2.0.2
>
> Staging repository:
>   https://repository.apache.org/content/repositories/felix-staging-001/
>
> You can use this UNIX script to download the release and verify the 
> signatures:
>   http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
>   sh check_staged_release.sh 1 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
>
> --
> Cheers,
> Guillaume Nodet
> 
> Blog: http://gnodet.blogspot.com/
> 
> Open Source SOA
> http://fusesource.com
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: [VOTE] Release fileinstall 2.0.2

2009-10-19 Thread Guillaume Nodet 
I've created a JIRA for that (FELIX-1775) so that we don't forget it
and hopefully find a fix before next release.

On Tue, Oct 20, 2009 at 08:25, Clement Escoffier
 wrote:
> +1,
>
> The only issue I saw (pretty minor) is the (empty) 'load' folder in the
> archives. I think we got this issue before and this is due to the test
> executions. It's absolutely not a release blocker, but maybe somebody know
> the maven trick to 'exclude' this folder in the next releases.
>
> Regards,
>
> Clement
>
> On 19.10.2009, at 18:18, Guillaume Nodet wrote:
>
>> This release includes
>>  * fileinstall 2.0.2
>>
>> Staging repository:
>>  https://repository.apache.org/content/repositories/felix-staging-001/
>>
>> You can use this UNIX script to download the release and verify the
>> signatures:
>>  http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>
>> Usage:
>>  sh check_staged_release.sh 1 /tmp/felix-staging
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> 
>> Blog: http://gnodet.blogspot.com/
>> 
>> Open Source SOA
>> http://fusesource.com
>
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

[jira] Created: (FELIX-1775) fileinstall release archives contains an empty "load" folder which should be removed

2009-10-19 Thread Guillaume Nodet (JIRA) 
fileinstall release archives contains an empty "load" folder which should be 
removed


 Key: FELIX-1775
 URL: https://issues.apache.org/jira/browse/FELIX-1775
 Project: Felix
  Issue Type: Bug
  Components: File Install
Reporter: Guillaume Nodet
Priority: Minor




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release fileinstall 2.0.2

2009-10-19 Thread Clement Escoffier 

+1,

The only issue I saw (pretty minor) is the (empty) 'load' folder in  
the archives. I think we got this issue before and this is due to the  
test executions. It's absolutely not a release blocker, but maybe  
somebody know the maven trick to 'exclude' this folder in the next  
releases.


Regards,

Clement

On 19.10.2009, at 18:18, Guillaume Nodet wrote:


This release includes
  * fileinstall 2.0.2

Staging repository:
  https://repository.apache.org/content/repositories/felix- 
staging-001/


You can use this UNIX script to download the release and verify the  
signatures:

  http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
  sh check_staged_release.sh 1 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)


--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

[jira] Created: (FELIX-1774) CLONE -SCR Annotations - Support "Add" Operator in annotation values

2009-10-19 Thread andre payne (JIRA) 
CLONE -SCR Annotations - Support "Add" Operator in annotation values


 Key: FELIX-1774
 URL: https://issues.apache.org/jira/browse/FELIX-1774
 Project: Felix
  Issue Type: Bug
  Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.4.0
Reporter: andre payne
 Fix For: maven-scr-plugin-1.4.1


in scr plugin 1.4.0 it is not possible to use a annotation expression like this:
contentType = "application/json;charset=" + CharEncoding.UTF_8

the attached patch solves this problem by supporting the qdox "AnnotationAdd" 
class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FELIX-1064) New goal for the features-maven-plugin: validate a features xml file

2009-10-19 Thread Gert Vanthienen (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767479#action_12767479
 ] 

Gert Vanthienen commented on FELIX-1064:


Improving the validate goal to deal with maven repositories specified in the 
bundle url
cfr. http://svn.apache.org/viewvc?view=revision&revision=826783

> New goal for the features-maven-plugin: validate a features xml file
> 
>
> Key: FELIX-1064
> URL: https://issues.apache.org/jira/browse/FELIX-1064
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Gert Vanthienen
> Fix For: karaf-1.0.2, karaf-1.2.0
>
>
> We should add a goal to the features-maven-plugin to validate the features 
> xml file:
> * do all the bundles exist?
> * are all the imports from the bundles resolved?
> Most of the code for reading manifest and looking up the bundles is already 
> available in the features-maven-plugin' generate-features-xml Mojo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (FELIX-1772) Upgrade to felix framework 2.0.1

2009-10-19 Thread Guillaume Nodet (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FELIX-1772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1772.


   Resolution: Fixed
Fix Version/s: karaf-1.0.2
 Assignee: Guillaume Nodet

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M   karaf/pom.xml
Committed r826750


> Upgrade to felix framework 2.0.1
> 
>
> Key: FELIX-1772
> URL: https://issues.apache.org/jira/browse/FELIX-1772
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.2
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1773) Provide optional support for depoying plain wars

2009-10-19 Thread Guillaume Nodet (JIRA) 
Provide optional support for depoying plain wars


 Key: FELIX-1773
 URL: https://issues.apache.org/jira/browse/FELIX-1773
 Project: Felix
  Issue Type: New Feature
  Components: Karaf
Reporter: Guillaume Nodet


At least, we need to provide a feature and a custom deployer.
We may also want to provide multiple distributions, one containing the web 
stuff, but we should first work on the plugin to ease the creation of enhanced 
karaf distributions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (FELIX-1755) Provide a script file that would be loaded when starting a new shell (to create closures, etc...)

2009-10-19 Thread Guillaume Nodet (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FELIX-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1755.


Resolution: Fixed
  Assignee: Guillaume Nodet

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
A   karaf/assembly/src/main/distribution/text/etc/shell.init.script
M   karaf/assembly/src/main/distribution/text/etc/system.properties
M   
karaf/shell/console/src/main/java/org/apache/felix/karaf/shell/console/jline/Console.java
Committed r826748


> Provide a script file that would be loaded when starting a new shell (to 
> create closures, etc...)
> -
>
> Key: FELIX-1755
> URL: https://issues.apache.org/jira/browse/FELIX-1755
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.2
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1772) Upgrade to felix framework 2.0.1

2009-10-19 Thread Guillaume Nodet (JIRA) 
Upgrade to felix framework 2.0.1


 Key: FELIX-1772
 URL: https://issues.apache.org/jira/browse/FELIX-1772
 Project: Felix
  Issue Type: Improvement
  Components: Karaf
Reporter: Guillaume Nodet




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (FELIX-1718) karaf shell config:update command should persist / override configurations from the etc/ folder

2009-10-19 Thread Guillaume Nodet (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FELIX-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1718.


Resolution: Fixed
  Assignee: Guillaume Nodet

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M   
karaf/shell/config/src/main/java/org/apache/felix/karaf/shell/config/UpdateCommand.java
M   
karaf/shell/config/src/main/resources/OSGI-INF/blueprint/shell-config.xml
Committed r826734

The configuration is now written to the etc/ folder but this behavior can be 
changed using a -b option on the command.

> karaf shell config:update command should persist / override configurations 
> from the etc/ folder
> ---
>
> Key: FELIX-1718
> URL: https://issues.apache.org/jira/browse/FELIX-1718
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Sergey Beryozkin
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.2
>
>
> config:update command results in updates being persisted in memory only; it 
> would be great for updates be retrievable after the container has been 
> restarted
> perhaps ConfigAdmin can be told to save the updates to the original cfg file 
> but may be another option would be to save them to the ConfigAdmin bundle 
> cache so that updates can be reverted

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-1718) karaf shell config:update command should persist / override configurations from the etc/ folder

2009-10-19 Thread Guillaume Nodet (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FELIX-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated FELIX-1718:
---

Summary: karaf shell config:update command should persist / override 
configurations from the etc/ folder  (was: Karaf Shell Config Update command 
should be able to persist updates across container restarts)

Actually, the configuration is already persisted by config admin but is 
overriden on restart by the content from the etc/ folder.


> karaf shell config:update command should persist / override configurations 
> from the etc/ folder
> ---
>
> Key: FELIX-1718
> URL: https://issues.apache.org/jira/browse/FELIX-1718
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Sergey Beryozkin
> Fix For: karaf-1.0.2
>
>
> config:update command results in updates being persisted in memory only; it 
> would be great for updates be retrievable after the container has been 
> restarted
> perhaps ConfigAdmin can be told to save the updates to the original cfg file 
> but may be another option would be to save them to the ConfigAdmin bundle 
> cache so that updates can be reverted

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[VOTE] Release fileinstall 2.0.2

2009-10-19 Thread Guillaume Nodet 
This release includes
   * fileinstall 2.0.2

Staging repository:
   https://repository.apache.org/content/repositories/felix-staging-001/

You can use this UNIX script to download the release and verify the signatures:
   http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
   sh check_staged_release.sh 1 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)


-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

[jira] Updated: (FELIX-1370) Sometimes the configuration for org.apache.felix.webconsole.internal.servlet.OsgiManager is ignored

2009-10-19 Thread Guillaume Nodet (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FELIX-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet updated FELIX-1370:
---

Component/s: (was: Karaf)
 Web Console

> Sometimes the configuration for 
> org.apache.felix.webconsole.internal.servlet.OsgiManager is ignored
> ---
>
> Key: FELIX-1370
> URL: https://issues.apache.org/jira/browse/FELIX-1370
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Reporter: Tim Moloney
>Assignee: Guillaume Nodet
> Fix For: webconsole-2.0.2
>
>
> About half of the time, I can access the webconsole as expected using the 
> username/password karaf/karaf.  The other times it appears that the 
> configuration for org.apache.felix.webconsole.internal.servlet.OsgiManager is 
> ignored and I have to log in as admin/admin (the default webconsole 
> username/password).
> This can happen after a fresh start of karaf and loading the webconsole using 
> "features:install webconsole".  It also happens when reloading the webconsole 
> using "features:uninstall webconsole" and "features:install webconsole".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (FELIX-1370) Sometimes the configuration for org.apache.felix.webconsole.internal.servlet.OsgiManager is ignored

2009-10-19 Thread Guillaume Nodet (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FELIX-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1370.


   Resolution: Fixed
Fix Version/s: webconsole-2.0.2
 Assignee: Guillaume Nodet

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M   
webconsole/src/main/java/org/apache/felix/webconsole/internal/servlet/OsgiManager.java
Committed r826687


> Sometimes the configuration for 
> org.apache.felix.webconsole.internal.servlet.OsgiManager is ignored
> ---
>
> Key: FELIX-1370
> URL: https://issues.apache.org/jira/browse/FELIX-1370
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Reporter: Tim Moloney
>Assignee: Guillaume Nodet
> Fix For: webconsole-2.0.2
>
>
> About half of the time, I can access the webconsole as expected using the 
> username/password karaf/karaf.  The other times it appears that the 
> configuration for org.apache.felix.webconsole.internal.servlet.OsgiManager is 
> ignored and I have to log in as admin/admin (the default webconsole 
> username/password).
> This can happen after a fresh start of karaf and loading the webconsole using 
> "features:install webconsole".  It also happens when reloading the webconsole 
> using "features:uninstall webconsole" and "features:install webconsole".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Commented: (FELIX-1370) Sometimes the configuration for org.apache.felix.webconsole.internal.servlet.OsgiManager is ignored

2009-10-19 Thread Guillaume Nodet 
I've reproduced and track down this issue.
It comes from a synchronization problem in OsgiManager.  What happens
is that when you restart the framework, you may run into
sychronization problems if the config admin calls the updated() method
and the http service are registered at the same time.
I've just committed a fix at rev 826687, but jira is down for now, so
i'll close the issue when it comes up again.

On Mon, Oct 5, 2009 at 16:39, richard stone (JIRA)  wrote:
>
>    [ 
> https://issues.apache.org/jira/browse/FELIX-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762193#action_12762193
>  ]
>
> richard stone commented on FELIX-1370:
> --
>
> I met this problem right now. My env was:
>
> Configuration Admin 1.2.4
> File Install 2.0.0
> Web Management Console 1.2.10
> Pax Web container 0.6.0
>
>> Sometimes the configuration for 
>> org.apache.felix.webconsole.internal.servlet.OsgiManager is ignored
>> ---
>>
>>                 Key: FELIX-1370
>>                 URL: https://issues.apache.org/jira/browse/FELIX-1370
>>             Project: Felix
>>          Issue Type: Bug
>>          Components: Karaf
>>            Reporter: Tim Moloney
>>
>> About half of the time, I can access the webconsole as expected using the 
>> username/password karaf/karaf.  The other times it appears that the 
>> configuration for org.apache.felix.webconsole.internal.servlet.OsgiManager 
>> is ignored and I have to log in as admin/admin (the default webconsole 
>> username/password).
>> This can happen after a fresh start of karaf and loading the webconsole 
>> using "features:install webconsole".  It also happens when reloading the 
>> webconsole using "features:uninstall webconsole" and "features:install 
>> webconsole".
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: [fileinstall] review changes before release

2009-10-19 Thread Guillaume Nodet 
I've done some testing, but I can't really reproduce the exact behavior.
Here's what I have:

14:15:53,978 | DEBUG | lixDispatchQueue | fileinstall
| ?   ? | BundleEvent RESOLVED
14:15:54,017 | INFO  | nerated-bundles} | fileinstall
| ?   ? | {felix.fileinstall.poll
(ms) = 1000, felix.fileinstall.dir =
/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/deploy,
felix.fileinstall.debug = -1, felix.fileinstall.bundles.new.start =
true, felix.fileinstall.tmpdir =
/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/data/generated-bundles,
felix.fileinstall.filter = null}
14:15:54,017 | INFO  | FelixStartLevel  | fileinstall
| ?   ? | Starting initial scan
14:15:54,032 | INFO  | nerated-bundles} | fileinstall
| ?   ? | Started bundle:
file:/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/deploy/org.apache.felix.karaf.shell.obr-1.1.0-SNAPSHOT.jar
14:15:54,034 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent RESOLVED
14:15:54,035 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent STARTED
14:15:55,006 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent STOPPED
14:15:55,007 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent UNRESOLVED
14:15:55,007 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent UPDATED
14:15:55,022 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent RESOLVED
14:15:55,024 | DEBUG | lixDispatchQueue | obr
| ?   ? | BundleEvent STARTED
14:15:55,024 | INFO  | nerated-bundles} | fileinstall
| ?   ? | Updated
/Users/gnodet/work/felix/git/karaf/assembly/target/apache-felix-karaf-1.1.0-SNAPSHOT/deploy/org.apache.felix.karaf.shell.obr-1.1.0-SNAPSHOT.jar
14:15:55,025 | DEBUG | lixDispatchQueue | framework
| ?   ? | FrameworkEvent PACKAGES
REFRESHED

The above log is a trimmed down version of karaf after a restart with
an update on the obr bundle located in the deploy folder between the
stop and restart.

What happens is that when the framework is restarted, the deployed
bundle is started by the framework.  When fileinstall is then started,
it will update the obr bundle (so it will be stopped and restarted).

One possible thing that may happen is some kind of interaction between
the start level service and fileinstall.  But if the start level of
the bundle is higher than the current start level, the framework
should not really start the deployed bundle when fileinstall asks to
do so until the start level has been raised.  So I don't think there
is any possible issue here.

Can you check from your side ?

On Sat, Oct 17, 2009 at 09:04, Pierre De Rop
 wrote:
> Hello Guillaume,
>
> I did some testing on the latest fileinstall, from the trunk.
> Specifically, I tested the resolved issue from FELIX-1578 and the problem
> has disappeared.
>
> However, I noticed another (different) problem when performing the test (not
> sure if I must create another jira issue, or not ?).
> Here is what I did when testing:
>
> 1)   clean the fwk bundle-cache (the fwk is not running)
> 2)   copy a test bundle in the fileinstall's deploy directory
> 3)   touch -t 0101 deploy/test.jar (so, the lastModified date of
> test.jar is Jan, 1st 2009)
> 4)   I start the fwk -> test.jar is installed
> 5)   I stop the fwk
> 6)   I recompile the test.jar bundle (I just manage to ensure that test.jar
> has now a different checksum), and I modify the timestamp with "touch -t
> 0201 deploy/test.jar" (the timestamp is now Feb 1st, 2009)
> 7)   I restart the fwk (without cleaning the cache)
> 7.1) the test.jar bundle is properly *updated* and started (the patch
> FELIX-1578 works fine)
> 7.2) *however, after a few milliseconds, test.jar is stopped and then
> restarted.*
>
> Don't you think that fileinstall uselessly restarts test.jar during the step
> 7.2 ?
>
> /pierre
>
> Guillaume Nodet wrote:
>>
>> I've fixed a lots of jira issues this week on fileinstall, so I'd
>> welcome a bit more testing before preparing a release next week or
>> so...
>>
>>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

[jira] Resolved: (FELIX-1771) Feature deployer is broken on windows

2009-10-19 Thread Guillaume Nodet (JIRA) 

 [ 
https://issues.apache.org/jira/browse/FELIX-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guillaume Nodet resolved FELIX-1771.


Resolution: Fixed

Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M   
karaf/deployer/blueprint/src/main/resources/OSGI-INF/blueprint/blueprint-deployer.xml
M   
karaf/deployer/features/src/main/java/org/apache/felix/karaf/deployer/features/FeatureDeploymentListener.java
A   
karaf/deployer/features/src/main/java/org/apache/felix/karaf/deployer/features/FeatureTransformer.java
A   
karaf/deployer/features/src/main/java/org/apache/felix/karaf/deployer/features/FeatureURLHandler.java
M   
karaf/deployer/features/src/main/resources/OSGI-INF/blueprint/features-deployer.xml
M   
karaf/deployer/spring/src/main/resources/OSGI-INF/blueprint/spring-deployer.xml
Committed r826649


> Feature deployer is broken on windows
> -
>
> Key: FELIX-1771
> URL: https://issues.apache.org/jira/browse/FELIX-1771
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: karaf-1.0.2
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [fileinstall] review changes before release

2009-10-19 Thread Guillaume Nodet 
Sure, please raise a JIRA and i'll try to reprodyce and fix if needed.

On Sat, Oct 17, 2009 at 09:04, Pierre De Rop
 wrote:
> Hello Guillaume,
>
> I did some testing on the latest fileinstall, from the trunk.
> Specifically, I tested the resolved issue from FELIX-1578 and the problem
> has disappeared.
>
> However, I noticed another (different) problem when performing the test (not
> sure if I must create another jira issue, or not ?).
> Here is what I did when testing:
>
> 1)   clean the fwk bundle-cache (the fwk is not running)
> 2)   copy a test bundle in the fileinstall's deploy directory
> 3)   touch -t 0101 deploy/test.jar (so, the lastModified date of
> test.jar is Jan, 1st 2009)
> 4)   I start the fwk -> test.jar is installed
> 5)   I stop the fwk
> 6)   I recompile the test.jar bundle (I just manage to ensure that test.jar
> has now a different checksum), and I modify the timestamp with "touch -t
> 0201 deploy/test.jar" (the timestamp is now Feb 1st, 2009)
> 7)   I restart the fwk (without cleaning the cache)
> 7.1) the test.jar bundle is properly *updated* and started (the patch
> FELIX-1578 works fine)
> 7.2) *however, after a few milliseconds, test.jar is stopped and then
> restarted.*
>
> Don't you think that fileinstall uselessly restarts test.jar during the step
> 7.2 ?
>
> /pierre
>
> Guillaume Nodet wrote:
>>
>> I've fixed a lots of jira issues this week on fileinstall, so I'd
>> welcome a bit more testing before preparing a release next week or
>> so...
>>
>>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

[jira] Commented: (FELIX-1766) Refactor and enable AdminServiceMBean

2009-10-19 Thread David Bosschaert (JIRA) 

[ 
https://issues.apache.org/jira/browse/FELIX-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767302#action_12767302
 ] 

David Bosschaert commented on FELIX-1766:
-

I am starting to look into this one now...

> Refactor and enable AdminServiceMBean
> -
>
> Key: FELIX-1766
> URL: https://issues.apache.org/jira/browse/FELIX-1766
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
>Affects Versions: karaf-1.0.0
>Reporter: David Bosschaert
>
> The MBean for the AdminService is currently not registered with the MBean 
> Server. 
> Before it can be registered it needs to be refactored to be more 
> coarse-grained, like the FeaturesServiceMBean.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Karaf] Not importing the exported packages

2009-10-19 Thread Guillaume Nodet 
Yeah, I do have thoughts about this thing.
The blog entry is really misleading.  Take a look at
http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages?
but imho, it's not sufficient either.
The main point is that only when you export an api where you may have
multiple implementations, you'd want to import the packages.  For a
library / implementation, you should not do that, as it causes lots of
problems when deploying multiple versions.

On Mon, Oct 19, 2009 at 13:37, David Bosschaert
 wrote:
> Hi all,
>
> I came across the following in a number of pom.xml files in the Karaf build
> system:
>
> 
>  org.apache.felix
>  maven-bundle-plugin
>  
>    
>      ${pom.artifactId}
>      
>          ${pom.artifactId}*;version=${pom.version}
>      
>      
>          !${pom.artifactId}*,
>          ... more stuff ...
>      
>    
>  
> 
>
> So in the Import-Package section, the packages that exported by a the bundle
> are explicitly not imported. I always thought that you should be doing the
> opposite and always import what you are also exporting. See
> http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html
>
> Thoughts anyone?
>
> David
>



-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

[Karaf] Not importing the exported packages

2009-10-19 Thread David Bosschaert 
Hi all,

I came across the following in a number of pom.xml files in the Karaf build
system:


  org.apache.felix
  maven-bundle-plugin
  

  ${pom.artifactId}
  
  ${pom.artifactId}*;version=${pom.version}
  
  
  !${pom.artifactId}*,
  ... more stuff ...
  

  


So in the Import-Package section, the packages that exported by a the bundle
are explicitly not imported. I always thought that you should be doing the
opposite and always import what you are also exporting. See
http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html

Thoughts anyone?

David

[jira] Created: (FELIX-1771) Feature deployer is broken on windows

2009-10-19 Thread Guillaume Nodet (JIRA) 
Feature deployer is broken on windows
-

 Key: FELIX-1771
 URL: https://issues.apache.org/jira/browse/FELIX-1771
 Project: Felix
  Issue Type: Bug
  Components: Karaf
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
 Fix For: karaf-1.0.2




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1770) [Karaf] If features:refreshUrl reads an incorrect definition, it deletes the old version

2009-10-19 Thread Filippo Diotalevi (JIRA) 
[Karaf] If features:refreshUrl reads an incorrect  definition, it 
deletes the old version
---

 Key: FELIX-1770
 URL: https://issues.apache.org/jira/browse/FELIX-1770
 Project: Felix
  Issue Type: Bug
  Components: Karaf
Reporter: Filippo Diotalevi
Priority: Minor


Steps to reproduce:

1) create a simple feature definition like:
---

  
 http://www.abundleUrl.com


---

2) features:addUrl 
3) features:list   display the new feature correctly
4) change the feature definition making the XML invalid, f.i.
---

  
 http://www.abundleUrl.com


---
5) type features:refreshUrl and see that an error is displayed
6) type features:list ---> see that the "spring-dm-web" feature is disappeared


I would expect that the old feature is maintained if the new version of the 
feature XML definition is incorrect. WDYT?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.