date:20090713


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

Richard S. Hall commented on FELIX-1124:


Sorry for being confusing and/or confused. I know the exception is being thrown 
from there, my point is that the framework is not responsible for printing the 
verbose message. So now it seems clear the LogService impl is printing the 
information. So, in your original description you ask to let the client decide 
how verbose to be, so isn't this an issue of the LogService impl being too 
verbose, not the framework?

If we don't include the exception, then no logger would be able to get the 
information even if they wanted it.

> ResourceNotFoundException too verbose
> -
>
> Key: FELIX-1124
> URL: https://issues.apache.org/jira/browse/FELIX-1124
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.6.1, felix-1.8.0, felix-1.8.1
>Reporter: Thomas Diesler
>
> ModuleImpl logs stack traces for every resource that cannot be found. Often 
> resources are optional or may be located at different locations. 
> public URL getResourceByDelegation(String name)
> {
> try
> {
> return (URL) findClassOrResourceByDelegation(name, false);
> }
> catch (ClassNotFoundException ex)
> {
> // This should never be thrown because we are loading resources.
> }
> catch (ResourceNotFoundException ex)
> {
> m_logger.log(
> Logger.LOG_DEBUG,
> ex.getMessage(),
> ex);
> }
> return null;
> }
> Please consider a log message without stack trace and leave it to the client 
> to be more verbose when appropriate. 
> To log no message at all and simply return null would also be consistent with 
> http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)

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

[jira] Commented: (FELIX-1124) ResourceNotFoundException too verbose

2009-07-13 Thread Thomas Diesler (JIRA)


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

Thomas Diesler commented on FELIX-1124:
---

I see what you are saying, on the other hand can a LogService really choose not 
to log Exceptions in level debug even if a client explicitly asks the 
LogService to do so? 

IMHO, the client of the LogService should decide whether the Exception stack 
trace is relevant (i.e. should go to the log file) or not. The LogService 
cannot make this decision based on the level alone.

Yes, indeed I pass in a Felix logger when I construct the framework. All 
messages (from the LogService as well as from the Framework itself) get routed 
to the configured Log4J file. 

https://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/felix/trunk/src/main/java/org/jboss/osgi/felix/framework/FelixLogger.java




> ResourceNotFoundException too verbose
> -
>
> Key: FELIX-1124
> URL: https://issues.apache.org/jira/browse/FELIX-1124
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.6.1, felix-1.8.0, felix-1.8.1
>Reporter: Thomas Diesler
>
> ModuleImpl logs stack traces for every resource that cannot be found. Often 
> resources are optional or may be located at different locations. 
> public URL getResourceByDelegation(String name)
> {
> try
> {
> return (URL) findClassOrResourceByDelegation(name, false);
> }
> catch (ClassNotFoundException ex)
> {
> // This should never be thrown because we are loading resources.
> }
> catch (ResourceNotFoundException ex)
> {
> m_logger.log(
> Logger.LOG_DEBUG,
> ex.getMessage(),
> ex);
> }
> return null;
> }
> Please consider a log message without stack trace and leave it to the client 
> to be more verbose when appropriate. 
> To log no message at all and simply return null would also be consistent with 
> http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)

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

[jira] Created: (FELIX-1322) Tidy up tabs vs spaces in sigil source files

Tidy up tabs vs spaces in sigil source files


 Key: FELIX-1322
 URL: https://issues.apache.org/jira/browse/FELIX-1322
 Project: Felix
  Issue Type: Task
  Components: Sigil
Reporter: David Savage
Priority: Trivial




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

[jira] Created: (FELIX-1323) Use sigil to build sigil

Use sigil to build sigil


 Key: FELIX-1323
 URL: https://issues.apache.org/jira/browse/FELIX-1323
 Project: Felix
  Issue Type: New Feature
  Components: Sigil
Reporter: David Savage


Currently sigil is built using a PDE server build. However this is difficult to 
manage as it requires you to download binary dependencies locally.

Sigil on the other hand has the ability to download dependencies as maven or 
ivy do. Would be useful to eat our own dog food in this respect.

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

[jira] Issue Comment Edited: (FELIX-1124) ResourceNotFoundException too verbose


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

Richard S. Hall edited comment on FELIX-1124 at 7/13/09 6:40 AM:
-

Ok, I removed the exception from the logged information.

My original confusion was that I thought you were saying that Felix was 
printing the information, but it doesn't since Felix' default logger doesn't 
print stack traces for debug logs.

I am still not convinced that this isn't a lack of configurability in the log 
service impl, but I removed the exception since it probably doesn't provide 
much value any way.

Also, make sure your logger doesn't make calls back into Felix, since we 
witnessed deadlocking, which is why we disabled that by default.

Please close this issue if you are satisfied. Thanks.

  was (Author: rickhall):
Ok, I removed the exception from the logged information.

My original confusion was that I thought you were saying that Felix was 
printing the information, but it doesn't since Felix' default logger doesn't 
print stack traces for debug logs.

I am still not convinced that this isn't a lack of configurability in the log 
service impl, but I removed the exception since it probably doesn't provide 
much value any way.

Also, make sure your logger doesn't make calls back into Felix, since we 
witnessed deadlocking, which is why we disabled that by default.
  
> ResourceNotFoundException too verbose
> -
>
> Key: FELIX-1124
> URL: https://issues.apache.org/jira/browse/FELIX-1124
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.6.1, felix-1.8.0, felix-1.8.1
>Reporter: Thomas Diesler
>Assignee: Richard S. Hall
> Fix For: felix-2.0.0
>
>
> ModuleImpl logs stack traces for every resource that cannot be found. Often 
> resources are optional or may be located at different locations. 
> public URL getResourceByDelegation(String name)
> {
> try
> {
> return (URL) findClassOrResourceByDelegation(name, false);
> }
> catch (ClassNotFoundException ex)
> {
> // This should never be thrown because we are loading resources.
> }
> catch (ResourceNotFoundException ex)
> {
> m_logger.log(
> Logger.LOG_DEBUG,
> ex.getMessage(),
> ex);
> }
> return null;
> }
> Please consider a log message without stack trace and leave it to the client 
> to be more verbose when appropriate. 
> To log no message at all and simply return null would also be consistent with 
> http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)

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

[jira] Resolved: (FELIX-1124) ResourceNotFoundException too verbose


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

Richard S. Hall resolved FELIX-1124.


   Resolution: Fixed
Fix Version/s: felix-2.0.0
 Assignee: Richard S. Hall

Ok, I removed the exception from the logged information.

My original confusion was that I thought you were saying that Felix was 
printing the information, but it doesn't since Felix' default logger doesn't 
print stack traces for debug logs.

I am still not convinced that this isn't a lack of configurability in the log 
service impl, but I removed the exception since it probably doesn't provide 
much value any way.

Also, make sure your logger doesn't make calls back into Felix, since we 
witnessed deadlocking, which is why we disabled that by default.

> ResourceNotFoundException too verbose
> -
>
> Key: FELIX-1124
> URL: https://issues.apache.org/jira/browse/FELIX-1124
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.6.1, felix-1.8.0, felix-1.8.1
>Reporter: Thomas Diesler
>Assignee: Richard S. Hall
> Fix For: felix-2.0.0
>
>
> ModuleImpl logs stack traces for every resource that cannot be found. Often 
> resources are optional or may be located at different locations. 
> public URL getResourceByDelegation(String name)
> {
> try
> {
> return (URL) findClassOrResourceByDelegation(name, false);
> }
> catch (ClassNotFoundException ex)
> {
> // This should never be thrown because we are loading resources.
> }
> catch (ResourceNotFoundException ex)
> {
> m_logger.log(
> Logger.LOG_DEBUG,
> ex.getMessage(),
> ex);
> }
> return null;
> }
> Please consider a log message without stack trace and leave it to the client 
> to be more verbose when appropriate. 
> To log no message at all and simply return null would also be consistent with 
> http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html#getResource(java.lang.String)

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

[jira] Created: (FELIX-1324) Add support for runtime debug/launch of felix via eclipse

Add support for runtime debug/launch of felix via eclipse
-

 Key: FELIX-1324
 URL: https://issues.apache.org/jira/browse/FELIX-1324
 Project: Felix
  Issue Type: New Feature
  Components: Sigil
Reporter: David Savage


Sigil previously had the ability to launch and debug a Newton OSGi container. 
This has been removed in the port to apache as it brought in dependencies on a 
product that was not compatible with the apache licence.

Should be possible to rebuild this using existing felix tools

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

Re: Karaf - Gogo - Help !

2009-07-13 Thread Hiram Chirino

I don't think the help command is supported yet..

But on related note... to the gogo developers: I would have expected a
command not found error when you type in a command that's not found.  This
seems to work fine if you pass an argument to a command.  It this a
'feature' or a bug?

Regards,
Hiram

On Mon, Jul 13, 2009 at 4:45 AM, Charles Moulliard wrote:

> Hi,
>
> I have done a build of Apache Felix Karaf this morning in order to test it
> but unfortunately Gogo does not seem to like Windows :
>
> Here is a snapshot of command used :
>
> ka...@root> ka...@root> help
> help
> ka...@root> ka...@root> ?
> ?
> ka...@root> ka...@root> help
> help
> ka...@root> ka...@root>
>
> We can't have access to help !
> Where can I found the list of commands that we can use with Gogo (compare
> to
> gshell) ?
>
> Regards,
>
> Charles Moulliard
> Senior Enterprise Architect
> Apache Camel Committer
>
> *
> blog : http://cmoulliard.blogspot.com
>

-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://fusesource.com/

[jira] Commented: (FELIX-1324) Add support for runtime debug/launch of felix via eclipse


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

Richard S. Hall commented on FELIX-1324:


What does this mean exactly? Is this something the standard launching and 
embedding API helps or is it something else?

> Add support for runtime debug/launch of felix via eclipse
> -
>
> Key: FELIX-1324
> URL: https://issues.apache.org/jira/browse/FELIX-1324
> Project: Felix
>  Issue Type: New Feature
>  Components: Sigil
>Reporter: David Savage
>
> Sigil previously had the ability to launch and debug a Newton OSGi container. 
> This has been removed in the port to apache as it brought in dependencies on 
> a product that was not compatible with the apache licence.
> Should be possible to rebuild this using existing felix tools

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

New "inspect" command (Was: Re: Release of Apache Felix Shell 1.4.0?)

2009-07-13 Thread Richard S. Hall

Yes, I think it should be released. However, I am still grappling with 
the one open issue below...I probably should have brought it up on the 
list for input, but I got busy.


I had realized we had commands for inspecting the various types of 
capabilities/requirements present in the OSGi framework (e.g., exports, 
imports, services, etc.). I thought it made sense to create one command 
that does it all in a consistent fashion, so I created the "inspect" 
command. It works like this:


   * inspect (package|bundle|fragment|service) (require|provide)  ...

So, if I wanted to check the exported packages of bundle 5 I could type:

   * inspect package provide 5

Or use shorthand like:

   * inspect p p 5

These verbs make pretty good sense for packages and services, but they 
sort of break for require-bundle dependencies. Consider this:


   * inspect bundle provide 5

This would print every bundle that requires 5, for example, and I am not 
sure the verb is intuitive here. For fragments it is potentially worse, 
since fragments are not symmetric (i.e., you cannot both provide a 
fragment and require a fragment)...although if some asks what fragments 
a fragment requires, the answer is just an empty set, so it is still 
do-able.


Part of me thinks I need better verbs than (provide/require), but I 
couldn't really think of any. Another completely different approach is 
to simply have "inspect" dump all capabilities/requirements no matter 
the type (e.g., "inspect 5").


I think it makes sense to combine the various commands into one to avoid 
a proliferation of reflection commands, but I think my current approach 
needs some tweaking.


Any [simple] ideas?

-> richard


On 7/12/09 6:21 PM, Filippo Diotalevi wrote:

Hi,
   even if there's a lot going on in the OSGi-shell-space, I think many
of us are still using the good-old Felix Shell.
Currently in the trunk there are a number of unreleased fixes/improvement:

https://issues.apache.org/jira/browse/FELIX/fixforversion/12313936

FELIX-1181   FIXED   Add support for activation policy in shell "start" 
command   
FELIX-1145   FIXED   Modify help shell command to avoid issues with long
command descriptions
FELIX-1052   FIXED   Add log shell command  
FELIX-1019   FIXED   New shell commands "requirers" and "exports" do not
handle invalid bundle case properly
FELIX-1058   FIXED   [PATCH] Add a "find" command to the shell

while an improvement is still open:
FELIX-1151   UNRESOLVED  Improve naming and consistency of shell
commands for inspecting dependencies


What do you think of releasing Shell 1.4.0?

Re: Karaf - Gogo - Help !

2009-07-13 Thread Charles Moulliard

I think so even if it is mentioned in the header that this is the case :

D:\Dvlpt\Java\workspace-ganymede\x3s\server\apache-felix-karaf-1.2.0-SNAPSHOT\bin>karaf
__ __  
   / //_/ __ _/ __/
  / ,<  / __ `/ ___/ __ `/ /_
 / /| |/ /_/ / /  / /_/ / __/
/_/ |_|\__,_/_/   \__,_/_/

  Apache Felix Karaf (1.2.0-SNAPSHOT)

Type 'help' for more information.

ka...@root> bundles
00 ACT org.eclipse.osgi-3.5.0.v20090520
01 ACT org.apache.felix.configadmin-1.0.4
02 ACT org.apache.felix.prefs-1.0.2
03 ACT blueprint-bundle-1.0.0.SNAPSHOT
04 ACT org.ops4j.pax.logging.pax-logging-service-1.3.1.SNAPSHOT
05 ACT org.ops4j.pax.logging.pax-logging-api-1.3.1.SNAPSHOT
06 ACT org.ops4j.pax.url.wrap-0.3.3
07 ACT org.ops4j.pax.url.mvn-0.3.3
08 ACT org.apache.felix.karaf.gshell.packages-1.2.0.SNAPSHOT
09 ACT org.apache.felix.karaf.deployer.spring-1.2.0.SNAPSHOT
10 ACT org.apache.mina.core-2.0.0.M6
11 ACT org.apache.felix.karaf.deployer.blueprint-1.2.0.SNAPSHOT
12 ACT org.apache.felix.karaf.gshell.osgi-1.2.0.SNAPSHOT
13 ACT org.apache.felix.karaf.management-1.2.0.SNAPSHOT
14 ACT org.apache.felix.karaf.gshell.console-1.2.0.SNAPSHOT
15 ACT org.apache.felix.karaf.gshell.config-1.2.0.SNAPSHOT
16 ACT org.apache.felix.karaf.gshell.admin-1.2.0.SNAPSHOT
17 ACT org.apache.felix.karaf.jaas.config-1.2.0.SNAPSHOT
18 ACT org.osgi.impl.bundle.jmx-4.2.0.200907080519
19 ACT org.apache.felix.karaf.gshell.features-1.2.0.SNAPSHOT
20 ACT org.apache.felix.karaf.gshell.ssh-1.2.0.SNAPSHOT
21 ACT org.apache.felix.karaf.deployer.features-1.2.0.SNAPSHOT
22 ACT org.apache.felix.karaf.gshell.commands-1.2.0.SNAPSHOT
23 ACT sshd-core-1.0.0.SNAPSHOT
24 ACT org.apache.felix.karaf.gshell.log-1.2.0.SNAPSHOT
25 ACT org.apache.felix.karaf.jaas.modules-1.2.0.SNAPSHOT
26 ACT org.apache.felix.gogo.runtime-0.9.0.SNAPSHOT
27 ACT org.apache.felix.karaf.deployer.filemonitor-1.2.0.SNAPSHOT

ka...@root> ka...@root> log
log
ka...@root> ka...@root> ?
?
ka...@root> ka...@root> help
help
ka...@root> ka...@root> set INFO
ka...@root> ka...@root> packages
packages
ka...@root> ka...@root> imports 1
OSGi System Bundle (0): org.osgi.framework; version="1.5.0"
OPS4J Pax Logging - API (5): org.osgi.service.log; version="1.3.0"
ka...@root> ka...@root>

Another issue is that the name of the command does not appear on the shell.
So, by example, when you type the word : packages or log, the console is
refreshed but you have no idea where you are in the tree of the commands

And the last but not the least is that question are double :

ka...@root> ka...@root> update 27
You are about to access system bundle 27.  Do you want to continue (yes/no):
You are about to access system bundle 27.  Do you want to continue (yes/no):

Regards,

Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer

*
blog : http://cmoulliard.blogspot.com


On Mon, Jul 13, 2009 at 4:27 PM, Hiram Chirino  wrote:

> I don't think the help command is supported yet..
>
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found.  This
> seems to work fine if you pass an argument to a command.  It this a
> 'feature' or a bug?
>
> Regards,
> Hiram
>
>
> On Mon, Jul 13, 2009 at 4:45 AM, Charles Moulliard  >wrote:
>
> > Hi,
> >
> > I have done a build of Apache Felix Karaf this morning in order to test
> it
> > but unfortunately Gogo does not seem to like Windows :
> >
> > Here is a snapshot of command used :
> >
> > ka...@root> ka...@root> help
> > help
> > ka...@root> ka...@root> ?
> > ?
> > ka...@root> ka...@root> help
> > help
> > ka...@root> ka...@root>
> >
> > We can't have access to help !
> > Where can I found the list of commands that we can use with Gogo (compare
> > to
> > gshell) ?
> >
> > Regards,
> >
> > Charles Moulliard
> > Senior Enterprise Architect
> > Apache Camel Committer
> >
> > *
> > blog : http://cmoulliard.blogspot.com
> >
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://fusesource.com/
>

[jira] Updated: (FELIX-1320) Authentication failed connecting via ssh on Windows

2009-07-13 Thread Juan Jose Vazquez Delgado (JIRA)


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

Juan Jose Vazquez Delgado updated FELIX-1320:
-

Fix Version/s: karaf-1.0.0
Affects Version/s: (was: karaf-1.0.0)

> Authentication failed connecting via ssh on Windows
> ---
>
> Key: FELIX-1320
> URL: https://issues.apache.org/jira/browse/FELIX-1320
> Project: Felix
>  Issue Type: Bug
>  Components: Karaf
> Environment: Java version: 1.5.0_14
> Default locale: es_ES, platform encoding: Cp1252
> OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" 
>Reporter: Juan Jose Vazquez Delgado
> Fix For: karaf-1.0.0
>
>
> As discussed in [1], an authentication error happens connecting to karaf via 
> ssh on windows. This has been tested using both PuTTY and OpenSSH.
> [1] http://markmail.org/thread/iordmruvniqfc3v4

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

[karaf] itest excluded from build

2009-07-13 Thread Eoghan Glynn

Hi Folks,

I'm wondering why the pax.exam-based AbstractIntegrationTest isn't
built at the moment, as the itests module is excluded from the
top-level pom[1].

Also, in order to re-use this AbstractIntegrationTest else-where (for
example to take a dependency on it from the SMX codebase), it would
probably need to be moved to a separate module (as opposed to sharing
a module with some concrete tests).

Is there an issue with the AbstractIntegrationTest that causing the
module to be skipped, or is it just an issue with the concrete
CoreTest or FeaturesTest in the same module?

Cheers,
Eoghan

[1] http://svn.apache.org/repos/asf/felix/trunk/karaf/pom.xml

[jira] Created: (FELIX-1325) gogo doesn't report a command not found error unless an argument is supplied

gogo doesn't report a command not found error unless an argument is supplied

 Key: FELIX-1325
 URL: https://issues.apache.org/jira/browse/FELIX-1325
 Project: Felix
  Issue Type: Improvement
  Components: Gogo
Reporter: Derek Baum
Assignee: Derek Baum
Priority: Minor

2009/7/13 Hiram Chirino  wrote:
But on related note... to the gogo developers: I would have expected a
command not found error when you type in a command that's not found.  This
seems to work fine if you pass an argument to a command.  It this a 
'feature' or a bug?

This is a 'feature', in that an undefined command silently returns itself, 
rather than an error.

This is so that:

> x = hello

works; otherwise the assignment would fail, with a command not found error.

Note: that

> x = hello world

will actually evaluate the 'hello' command with 'world' as an argument.

> x = "hello world"

tries to evaulate the 'hello world' command, which probably doesn't exist, so 
it falls back to returning the value, rather than unknown command.

I think this can be simply resolved by avoiding re-evaluating an assignment 
with a single argument.

This will mean that

> x = hello

works as it does currently, but that

> hello

will fail with 'unknown command', rather than simply return itself.

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

[jira] Commented: (FELIX-1325) gogo doesn't report a command not found error unless an argument is supplied


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

Derek Baum commented on FELIX-1325:
---

Here's the patch to resolve as described:

svn diff src/main/java/org/apache/felix/gogo/runtime/shell/Closure.java
Index: src/main/java/org/apache/felix/gogo/runtime/shell/Closure.java
===
--- src/main/java/org/apache/felix/gogo/runtime/shell/Closure.java  
(revision 793625)
+++ src/main/java/org/apache/felix/gogo/runtime/shell/Closure.java  
(working copy)
@@ -166,6 +166,10 @@
 {
 return session.variables.remove(scmd);
 }
+else if (values.size() == 2)
+{
+return assignment(scmd, values.get(1));
+}
 else
 {
 Object value = execute(values.get(1), values.subList(2, 
values.size()));

> gogo doesn't report a command not found error unless an argument is supplied
> 
>
> Key: FELIX-1325
> URL: https://issues.apache.org/jira/browse/FELIX-1325
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
>
> 2009/7/13 Hiram Chirino  wrote:
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found.  This
> seems to work fine if you pass an argument to a command.  It this a 
> 'feature' or a bug?
> This is a 'feature', in that an undefined command silently returns itself, 
> rather than an error.
> This is so that:
> > x = hello
> works; otherwise the assignment would fail, with a command not found error.
> Note: that
> > x = hello world
> will actually evaluate the 'hello' command with 'world' as an argument.
> > x = "hello world"
> tries to evaulate the 'hello world' command, which probably doesn't exist, so 
> it falls back to returning the value, rather than unknown command.
> I think this can be simply resolved by avoiding re-evaluating an assignment 
> with a single argument.
> This will mean that
> > x = hello
> works as it does currently, but that
> > hello
> will fail with 'unknown command', rather than simply return itself.

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

[jira] Commented: (FELIX-1324) Add support for runtime debug/launch of felix via eclipse


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

David Savage commented on FELIX-1324:
-

Not so much, it's more about being able to launch and debug felix from eclipse. 
Basically eclipse has the notion of Launch Configurations of which you can 
supply our own factories. The factory does the job of abstracting the launch 
away from just java static void main and allows you to configure more domain 
specific stuff. A general purpose OSGi launch configuration would likely launch 
felix (or other OSGi frameworks) via the rfc 132 launch api?

At runtime we used to have the ability (via newton) to install bundles directly 
from the IDE including setting up source for things like debug break points 
etc. In our newton integration this involved poking the OSGi container via a 
JMX interface. It might be interesting to try to combine this with some of ssh 
connection via gogo or potentially via the jmx integration in karaf?

Not sure haven't thought about this second part completely - happy to discuss 
options etc.

> Add support for runtime debug/launch of felix via eclipse
> -
>
> Key: FELIX-1324
> URL: https://issues.apache.org/jira/browse/FELIX-1324
> Project: Felix
>  Issue Type: New Feature
>  Components: Sigil
>Reporter: David Savage
>
> Sigil previously had the ability to launch and debug a Newton OSGi container. 
> This has been removed in the port to apache as it brought in dependencies on 
> a product that was not compatible with the apache licence.
> Should be possible to rebuild this using existing felix tools

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

[jira] Issue Comment Edited: (FELIX-1324) Add support for runtime debug/launch of felix via eclipse


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

David Savage edited comment on FELIX-1324 at 7/13/09 10:08 AM:
---

Not so much, it's more about being able to launch and debug OSGi applications 
from eclipse. Basically eclipse has the notion of Launch Configurations of 
which you can supply our own factories. The factory does the job of abstracting 
the launch away from just java static void main and allows you to configure 
more domain specific stuff. A general purpose OSGi launch configuration would 
likely launch felix (or other OSGi frameworks) via the rfc 132 launch api?

At runtime we used to have the ability (via newton) to install bundles directly 
from the IDE including setting up source for things like debug break points 
etc. In our newton integration this involved poking the OSGi container via a 
JMX interface. It might be interesting to try to combine this with some of ssh 
connection via gogo or potentially via the jmx integration in karaf?

Not sure haven't thought about this second part completely - happy to discuss 
options etc.

  was (Author: davemssavage):
Not so much, it's more about being able to launch and debug felix from 
eclipse. Basically eclipse has the notion of Launch Configurations of which you 
can supply our own factories. The factory does the job of abstracting the 
launch away from just java static void main and allows you to configure more 
domain specific stuff. A general purpose OSGi launch configuration would likely 
launch felix (or other OSGi frameworks) via the rfc 132 launch api?

At runtime we used to have the ability (via newton) to install bundles directly 
from the IDE including setting up source for things like debug break points 
etc. In our newton integration this involved poking the OSGi container via a 
JMX interface. It might be interesting to try to combine this with some of ssh 
connection via gogo or potentially via the jmx integration in karaf?

Not sure haven't thought about this second part completely - happy to discuss 
options etc.
  
> Add support for runtime debug/launch of felix via eclipse
> -
>
> Key: FELIX-1324
> URL: https://issues.apache.org/jira/browse/FELIX-1324
> Project: Felix
>  Issue Type: New Feature
>  Components: Sigil
>Reporter: David Savage
>
> Sigil previously had the ability to launch and debug a Newton OSGi container. 
> This has been removed in the port to apache as it brought in dependencies on 
> a product that was not compatible with the apache licence.
> Should be possible to rebuild this using existing felix tools

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

[jira] Created: (FELIX-1326) Refactor package names in code to org.apache.felix.sigil

Refactor package names in code to org.apache.felix.sigil


 Key: FELIX-1326
 URL: https://issues.apache.org/jira/browse/FELIX-1326
 Project: Felix
  Issue Type: Task
  Components: Sigil
Reporter: David Savage
Priority: Critical


currently package names are org.cauldron.*

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

Re: Karaf - Gogo - Help !

2009-07-13 Thread Derek Baum

2009/7/13 Hiram Chirino 

> I don't think the help command is supported yet..
>
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found.  This
> seems to work fine if you pass an argument to a command.  It this a
> 'feature' or a bug?


It's a 'feature', but it can be fixed.
See https://issues.apache.org/jira/browse/FELIX-1325


Derek




>
>
> Regards,
> Hiram
>
>
> On Mon, Jul 13, 2009 at 4:45 AM, Charles Moulliard  >wrote:
>
> > Hi,
> >
> > I have done a build of Apache Felix Karaf this morning in order to test
> it
> > but unfortunately Gogo does not seem to like Windows :
> >
> > Here is a snapshot of command used :
> >
> > ka...@root> ka...@root> help
> > help
> > ka...@root> ka...@root> ?
> > ?
> > ka...@root> ka...@root> help
> > help
> > ka...@root> ka...@root>
> >
> > We can't have access to help !
> > Where can I found the list of commands that we can use with Gogo (compare
> > to
> > gshell) ?
> >
> > Regards,
> >
> > Charles Moulliard
> > Senior Enterprise Architect
> > Apache Camel Committer
> >
> > *
> > blog : http://cmoulliard.blogspot.com
> >
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://fusesource.com/
>

[jira] Created: (FELIX-1327) Refactor package names in plugin and plugin extensions to org.apache.felix namespace

Refactor package names in plugin and plugin extensions to org.apache.felix 
namespace


 Key: FELIX-1327
 URL: https://issues.apache.org/jira/browse/FELIX-1327
 Project: Felix
  Issue Type: Task
  Components: Sigil
Reporter: David Savage
Priority: Critical




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

[jira] Created: (FELIX-1328) Import quick fix processor does not propose fixes when missing class is a parent of current class

Import quick fix processor does not propose fixes when missing class is a 
parent of current class
-

 Key: FELIX-1328
 URL: https://issues.apache.org/jira/browse/FELIX-1328
 Project: Felix
  Issue Type: Bug
  Components: Sigil
Reporter: David Savage


example:

class MyServlet extends HttpServlet {
  void broken() {
getContentType();
  }
}

getContentType is defined in Servlet in package javax.servlet

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

[jira] Created: (FELIX-1329) Import quick fix processor does not import related API classes for abstract methods

Import quick fix processor does not import related API classes for abstract 
methods
---

 Key: FELIX-1329
 URL: https://issues.apache.org/jira/browse/FELIX-1329
 Project: Felix
  Issue Type: Bug
  Components: Sigil
Reporter: David Savage
Priority: Minor


package bar;

interface Bar {
}

package foo;

import bar.Bar;

interface Foo {
  void foo(Bar bar)
}

package impl;

import foo.Foo;

class FooImpl implements Foo {
  
}

should propose adding import for bar.Bar 

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

[jira] Commented: (FELIX-1324) Add support for runtime debug/launch of felix via eclipse


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

Richard S. Hall commented on FELIX-1324:


Well, it seems the factory for the launch configuration can now use the 
standard launching and embedding API to be reasonably generic for most 
frameworks. I am not sure what else is needed, but it seems like using standard 
API is the way to go if possible.

> Add support for runtime debug/launch of felix via eclipse
> -
>
> Key: FELIX-1324
> URL: https://issues.apache.org/jira/browse/FELIX-1324
> Project: Felix
>  Issue Type: New Feature
>  Components: Sigil
>Reporter: David Savage
>
> Sigil previously had the ability to launch and debug a Newton OSGi container. 
> This has been removed in the port to apache as it brought in dependencies on 
> a product that was not compatible with the apache licence.
> Should be possible to rebuild this using existing felix tools

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

[jira] Created: (FELIX-1330) Sigil eclipse integration needs to handle multi bundle projects

Sigil eclipse integration needs to handle multi bundle projects
---

 Key: FELIX-1330
 URL: https://issues.apache.org/jira/browse/FELIX-1330
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage


The server side sigil build is able to build multi bundle projects. However the 
eclipse IDE integration currently has no way to visualised this.

Several options are possible to close this discontinuity:

1) Don't support multi bundle projects
2) Support multiple .sigil files (as per bnd) and represent each in IDE 
as a separate rich UI view
3) Merge one multi bundle sigil.properties view into even richer UI view.

Possibly others?

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

[jira] Created: (FELIX-1331) Support for junit testing in IDE integration

Support for junit testing in IDE integration


 Key: FELIX-1331
 URL: https://issues.apache.org/jira/browse/FELIX-1331
 Project: Felix
  Issue Type: New Feature
  Components: Sigil
Reporter: David Savage


Possibly related to FELIX-1324 which would allow us to bring up a container in 
a specific configuration and run unit test with reports fed back to IDE

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

[jira] Created: (FELIX-1332) Sigil new Project wizard should be smarter when importing existing sources

Sigil new Project wizard should be smarter when importing existing sources
--

 Key: FELIX-1332
 URL: https://issues.apache.org/jira/browse/FELIX-1332
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage
Priority: Minor


Given an existing set of java classes in a folder sigil project wizard should 
make sensible guesses as two structure.

If folders exist that contain .java files these should be added to the source 
path
If jars are found each should be added to the classpath

Provide an optional page to set the exports for the project, should include 
option to: export none, export * from project, export * from jar classpath

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

[jira] Created: (FELIX-1333) Port documentation from http://sigil.codecauldron.org to felix confluence

Port documentation from http://sigil.codecauldron.org to felix confluence
-

 Key: FELIX-1333
 URL: https://issues.apache.org/jira/browse/FELIX-1333
 Project: Felix
  Issue Type: Task
  Components: Sigil
Reporter: David Savage




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

[jira] Created: (FELIX-1334) Adding jars to bundle classpath should offer jars that are not already on the project classpath

Adding jars to bundle classpath should offer jars that are not already on the 
project classpath
---

 Key: FELIX-1334
 URL: https://issues.apache.org/jira/browse/FELIX-1334
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage
Priority: Minor


Currently the eclipse rich ui element for managing bundles only prompts to add 
libraries to BUNDLE-CLASSPATH which have already been added to the eclipse 
classpath. Should be able to support reverse model where we find any jar from 
projects (or repositories?) and add these to local BUNDLE-CLASSPATH, which then 
implies adding them to eclipse classpath.

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

[jira] Created: (FELIX-1335) Provide support for .qualifier style extensions for bundle versions to ensure unique builds

Provide support for .qualifier style extensions for bundle versions to ensure 
unique builds
---

 Key: FELIX-1335
 URL: https://issues.apache.org/jira/browse/FELIX-1335
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage


For example user could specify bundle as version 1.0.0.qualifier a build time 
rule would convert the ".qualifier" expression via a template such as 
"%yyMMDD_hhmm% mechanism to 1.0.0.20090713_1838

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

[jira] Created: (FELIX-1336) Provide icons to represent OSGi elements in IDE

Provide icons to represent OSGi elements in IDE
---

 Key: FELIX-1336
 URL: https://issues.apache.org/jira/browse/FELIX-1336
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage
Priority: Minor


Need 32x32 icons to represent:

* sigil (potential to lift from sigil.codecauldron.org or design new icon)
* osgi runtime
* felix
* bundle
* package
* package export
* package import
* require-bundle
* refresh bundle (action)
* missing required bundle (error)
* missing package export (error)
* missing package import (error)

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

[jira] Created: (FELIX-1337) sigil.properties file is structurally different if saved from ui

sigil.properties file is structurally different if saved from ui


 Key: FELIX-1337
 URL: https://issues.apache.org/jira/browse/FELIX-1337
 Project: Felix
  Issue Type: Bug
  Components: Sigil
Reporter: David Savage
Priority: Minor


Name property appears in sigil.properties if UI changes bundle-symbolicname

The name is supressed when it is the same as the bundle-id in -bundles however, 
when the UI changes the bundle name, the -bundles element is unchanged, so a 
new name element is added.

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

[jira] Created: (FELIX-1338) Provide mechanism to import sigil projects that do not have corresponding eclipse .project and .classpath entries - i.e. those created on command line outside of eclipse

Provide mechanism to import sigil projects that do not have corresponding 
eclipse .project and .classpath entries - i.e. those created on command line 
outside of eclipse
-

 Key: FELIX-1338
 URL: https://issues.apache.org/jira/browse/FELIX-1338
 Project: Felix
  Issue Type: New Feature
  Components: Sigil
Reporter: David Savage


Creating "new sigil project" will overwrite the existing sigil.properties 
files. Import existing fails as there are no .eclipse and .classpath entries.

Potential to create a sigil eclipse:eclipse type function like maven? Also 
possibility to integrate with eclipse import wizards?

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

[jira] Created: (FELIX-1339) Create query tools to inspect a bundle in a repository and find which bundles may import or require it

Create query tools to inspect a bundle in a repository and find which bundles 
may import or require it
--

 Key: FELIX-1339
 URL: https://issues.apache.org/jira/browse/FELIX-1339
 Project: Felix
  Issue Type: New Feature
  Components: Sigil
Reporter: David Savage
Priority: Minor


The repository view could be improved in many ways via extensible tools to 
manipulate the bundles found in it. This is just one option.

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

[jira] Commented: (FELIX-1325) gogo doesn't report a command not found error unless an argument is supplied

2009-07-13 Thread Hiram Chirino (JIRA)


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

Hiram Chirino commented on FELIX-1325:
--

That raises more questions for me.

For me the sane way for a shell to handle assignment statements would have been 
something like this.

> x=Hello World
> x="Hello World"

Either of the above are equivalent.  And no Hello is not executed as command.  
If you do want to evaluate a command, it would be something like:

> x=

I would have preferred, using `Hello World` over , but it seems 
you guys prefer the latter because it is easier to parse recursive constructs.

Make sense?



> gogo doesn't report a command not found error unless an argument is supplied
> 
>
> Key: FELIX-1325
> URL: https://issues.apache.org/jira/browse/FELIX-1325
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
>
> 2009/7/13 Hiram Chirino  wrote:
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found.  This
> seems to work fine if you pass an argument to a command.  It this a 
> 'feature' or a bug?
> This is a 'feature', in that an undefined command silently returns itself, 
> rather than an error.
> This is so that:
> > x = hello
> works; otherwise the assignment would fail, with a command not found error.
> Note: that
> > x = hello world
> will actually evaluate the 'hello' command with 'world' as an argument.
> > x = "hello world"
> tries to evaulate the 'hello world' command, which probably doesn't exist, so 
> it falls back to returning the value, rather than unknown command.
> I think this can be simply resolved by avoiding re-evaluating an assignment 
> with a single argument.
> This will mean that
> > x = hello
> works as it does currently, but that
> > hello
> will fail with 'unknown command', rather than simply return itself.

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

[jira] Created: (FELIX-1340) Support source code linking to IDE in OBR repositories

Support source code linking to IDE in OBR repositories
--

 Key: FELIX-1340
 URL: https://issues.apache.org/jira/browse/FELIX-1340
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage


OBR meta data can point to location of source jars, we should pass this 
information through to IDE so that it could download the source file along side 
the binary should the developer require access to the source during the 
development lifecycle

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

[jira] Created: (FELIX-1341) Adding packages to a project should optionally automatically add exports to bundle

Adding packages to a project should optionally automatically add exports to 
bundle
--

 Key: FELIX-1341
 URL: https://issues.apache.org/jira/browse/FELIX-1341
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage
Priority: Trivial


Potential to set this up as an IDE preference? Marked as trivial as could also 
represent this as export org.example.foo.* in sigil.properties.

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

Re: Deploy snapshots from Bamboo

2009-07-13 Thread Gert Vanthienen

L.S.,

Ok, so let me try to ask this question the other way around then... Is
there a way I could get access to the Bamboo server so I could setup
CI builds for Karaf and get the credentials for deploying snapshots in
place?

Regards,

Gert Vanthienen

Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



2009/7/10 Gert Vanthienen :
> L.S.,
>
> In order to be able to deploy snapshots from our Bamboo CI server, I
> opened a JIRA for INFRA a while ago to get repository.apache.org set
> up for that.   The issue has now been resolved and I have received the
> credentials to be used.
> I'm not sure who's taking care of configuring the Bamboo build server,
> but if you let me know I'll forward that information to him/her.
>
> Regards,
>
> Gert Vanthienen
> 
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>

[jira] Created: (FELIX-1343) Dependency transitive="true"|"false" must be configurable

Dependency transitive="true"|"false" must be configurable
-

 Key: FELIX-1343
 URL: https://issues.apache.org/jira/browse/FELIX-1343
 Project: Felix
  Issue Type: Sub-task
  Components: Sigil
Reporter: David Savage


Currently all sigil injected dependencies have transitive="true".

However, it should be possible to configure this as part of the dependency 
configuration config.

For example, a "compile" configuration may only need transitive="false" 
dependencies, but a runtime configuration may need transitive="true" 
dependencies.

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

[jira] Created: (FELIX-1342) Injected Ivy dependency configurations must be configurable

Injected Ivy dependency configurations must be configurable
---

 Key: FELIX-1342
 URL: https://issues.apache.org/jira/browse/FELIX-1342
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage


Currently, Ivy dependencies injected by Sigil, have a hard-coded rule, 
resulting in dependencies like this:

 


The rule below drops configurations with no artifacts, and then add the 
configuration X->X(default) for all other configurations, except default.
This needs to be configurable via parameters to SigilParser in ivysettings.xml.


int nDeps = 0;
boolean foundDefault = false;

for (String conf : md.getConfigurationsNames()) {
if (conf.equals("default")) {
foundDefault = true;
} else if (md.getArtifacts(conf).length == 0) {
dd.addDependencyConfiguration(conf, conf + "(default)");
nDeps++;
}
}

if (nDeps > 0) {
if (foundDefault)
dd.addDependencyConfiguration("default", "default");
} else {
dd.addDependencyConfiguration("*", "*"); // all
// configurations
}


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

[jira] Created: (FELIX-1344) Failed to revert to non-sigil project

Failed to revert to non-sigil project
-

 Key: FELIX-1344
 URL: https://issues.apache.org/jira/browse/FELIX-1344
 Project: Felix
  Issue Type: Bug
  Components: Sigil
Reporter: David Savage
Priority: Minor


Description ported from sigil jira:

I accidentally committed the chainlink example as a partial sigil project.

So, I reverted the .project and .classpath files and did a refresh in Eclipse.

However, I still got the error "Cannot resolve import 
org.cauldron.newton.examples.chainlink.interfaces version=1.0.0"

This seems to be left over from when it was a sigil project. I tried opening 
sigil.properties, but this failed (as expected) saying the project was not a 
sigil project.

So I uninstalled sigil, and restarted Eclipse and then the error disappeared. 

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

Re: Deploy snapshots from Bamboo

2009-07-13 Thread Stuart McCulloch

2009/7/14 Gert Vanthienen 

> L.S.,
>
> Ok, so let me try to ask this question the other way around then... Is
> there a way I could get access to the Bamboo server so I could setup
> CI builds for Karaf and get the credentials for deploying snapshots in
> place?
>

if you sign up at http://opensource.bamboo.atlassian.com then I can give you
access,
alternatively send me the relevant details and I can update the build plans
accordingly

Regards,
>
> Gert Vanthienen
> 
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
> 2009/7/10 Gert Vanthienen :
> > L.S.,
> >
> > In order to be able to deploy snapshots from our Bamboo CI server, I
> > opened a JIRA for INFRA a while ago to get repository.apache.org set
> > up for that.   The issue has now been resolved and I have received the
> > credentials to be used.
> > I'm not sure who's taking care of configuring the Bamboo build server,
> > but if you let me know I'll forward that information to him/her.
> >
> > Regards,
> >
> > Gert Vanthienen
> > 
> > Open Source SOA: http://fusesource.com
> > Blog: http://gertvanthienen.blogspot.com/
> >
>

-- 
Cheers, Stuart

[jira] Created: (FELIX-1345) Bundle synchronization (i.e. download) should prompt a RepositoryChangeEvent to update sigil search

Bundle synchronization (i.e. download) should prompt a RepositoryChangeEvent to 
update sigil search
---

 Key: FELIX-1345
 URL: https://issues.apache.org/jira/browse/FELIX-1345
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage
Priority: Minor


This is dependent on current integration of sigil search which indexes files 
available on file system.

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

[jira] Created: (FELIX-1346) Automatically add imports/exports if refactoring to split a package from on bundle into a separate bundle

Automatically add imports/exports if refactoring to split a package from on 
bundle into a separate bundle
-

 Key: FELIX-1346
 URL: https://issues.apache.org/jira/browse/FELIX-1346
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage




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

[jira] Created: (FELIX-1347) Bld generates imports for packages that would normally be satisfied by bundle fragment host

Bld generates imports for packages that would normally be satisfied by bundle 
fragment host
---

 Key: FELIX-1347
 URL: https://issues.apache.org/jira/browse/FELIX-1347
 Project: Felix
  Issue Type: Bug
  Components: Sigil
Reporter: David Savage


Work around is to use

option;addMissingImports: false
header;-failok: true

In sigil.properties file for fragment bundle

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

[jira] Created: (FELIX-1348) Support for undo in sigil project editor

Support for undo in sigil project editor


 Key: FELIX-1348
 URL: https://issues.apache.org/jira/browse/FELIX-1348
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage




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

[jira] Created: (FELIX-1350) Allow sigil to be used just to create jars - i.e. like bndwrap - does not need ivy resolution just generate the jar from already built classes

Allow sigil to be used just to create jars - i.e. like bndwrap - does not need 
ivy resolution just generate the jar from already built classes
--

 Key: FELIX-1350
 URL: https://issues.apache.org/jira/browse/FELIX-1350
 Project: Felix
  Issue Type: New Feature
  Components: Sigil
Reporter: David Savage
Priority: Trivial




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

[jira] Created: (FELIX-1349) Importing projects into workspace should trigger a reset of the project classpath

Importing projects into workspace should trigger a reset of the project 
classpath
-

 Key: FELIX-1349
 URL: https://issues.apache.org/jira/browse/FELIX-1349
 Project: Felix
  Issue Type: Bug
  Components: Sigil
Reporter: David Savage


Importing new projects may satisfy otherwise unsatisfied project dependencies. 
This will be resoved on eclipse restart but this is not very friendly for the 
developer

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

[jira] Created: (FELIX-1351) sigil.properties does not allow the specification of singleton bundles

sigil.properties does not allow the specification of singleton bundles
--

 Key: FELIX-1351
 URL: https://issues.apache.org/jira/browse/FELIX-1351
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage
Priority: Minor




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

[jira] Created: (FELIX-1352) Copy pasting a fully qualified path into dependency dialog does not enable ok button (have to delete char and readd)

Copy pasting a fully qualified path into dependency dialog does not enable ok 
button (have to delete char and readd)


 Key: FELIX-1352
 URL: https://issues.apache.org/jira/browse/FELIX-1352
 Project: Felix
  Issue Type: Bug
  Components: Sigil
Reporter: David Savage
Priority: Minor




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

[jira] Created: (FELIX-1353) Base jvm added to eclipse classpath on OSGi Bundle-Environment header

Base jvm added to eclipse classpath on OSGi Bundle-Environment header
-

 Key: FELIX-1353
 URL: https://issues.apache.org/jira/browse/FELIX-1353
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage
Priority: Minor




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

[jira] Created: (FELIX-1354) Project editor title does not update if bundle symbolic name is updated

Project editor title does not update if bundle symbolic name is updated
---

 Key: FELIX-1354
 URL: https://issues.apache.org/jira/browse/FELIX-1354
 Project: Felix
  Issue Type: Bug
  Components: Sigil
Reporter: David Savage
Priority: Trivial




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

Re: Deploy snapshots from Bamboo

2009-07-13 Thread Gert Vanthienen

Stuart,

My Bamboo user id is gertv, I'll gladly help out setting things up
(now or for future Felix projects).
I'm also sending you the credentials, as you probably know your way
around in Bamboo already to get this thing working.

Thanks,

Gert Vanthienen

Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



2009/7/13 Stuart McCulloch :
> 2009/7/14 Gert Vanthienen 
>
>> L.S.,
>>
>> Ok, so let me try to ask this question the other way around then... Is
>> there a way I could get access to the Bamboo server so I could setup
>> CI builds for Karaf and get the credentials for deploying snapshots in
>> place?
>>
>
> if you sign up at http://opensource.bamboo.atlassian.com then I can give you
> access,
> alternatively send me the relevant details and I can update the build plans
> accordingly
>
> Regards,
>>
>> Gert Vanthienen
>> 
>> Open Source SOA: http://fusesource.com
>> Blog: http://gertvanthienen.blogspot.com/
>>
>> 2009/7/10 Gert Vanthienen :
>> > L.S.,
>> >
>> > In order to be able to deploy snapshots from our Bamboo CI server, I
>> > opened a JIRA for INFRA a while ago to get repository.apache.org set
>> > up for that.   The issue has now been resolved and I have received the
>> > credentials to be used.
>> > I'm not sure who's taking care of configuring the Bamboo build server,
>> > but if you let me know I'll forward that information to him/her.
>> >
>> > Regards,
>> >
>> > Gert Vanthienen
>> > 
>> > Open Source SOA: http://fusesource.com
>> > Blog: http://gertvanthienen.blogspot.com/
>> >
>>
>
> --
> Cheers, Stuart
>

Re: Deploy snapshots from Bamboo

2009-07-13 Thread Stuart McCulloch

2009/7/14 Gert Vanthienen 

> Stuart,
>
> My Bamboo user id is gertv, I'll gladly help out setting things up
> (now or for future Felix projects).


OK you should now be able to setup Karaf builds


> I'm also sending you the credentials, as you probably know your way
> around in Bamboo already to get this thing working.
>

not sure about that, but I'll give it a go ;)


> Thanks,
>
> Gert Vanthienen
> 
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> 2009/7/13 Stuart McCulloch :
> > 2009/7/14 Gert Vanthienen 
> >
> >> L.S.,
> >>
> >> Ok, so let me try to ask this question the other way around then... Is
> >> there a way I could get access to the Bamboo server so I could setup
> >> CI builds for Karaf and get the credentials for deploying snapshots in
> >> place?
> >>
> >
> > if you sign up at http://opensource.bamboo.atlassian.com then I can give
> you
> > access,
> > alternatively send me the relevant details and I can update the build
> plans
> > accordingly
> >
> > Regards,
> >>
> >> Gert Vanthienen
> >> 
> >> Open Source SOA: http://fusesource.com
> >> Blog: http://gertvanthienen.blogspot.com/
> >>
> >> 2009/7/10 Gert Vanthienen :
> >> > L.S.,
> >> >
> >> > In order to be able to deploy snapshots from our Bamboo CI server, I
> >> > opened a JIRA for INFRA a while ago to get repository.apache.org set
> >> > up for that.   The issue has now been resolved and I have received the
> >> > credentials to be used.
> >> > I'm not sure who's taking care of configuring the Bamboo build server,
> >> > but if you let me know I'll forward that information to him/her.
> >> >
> >> > Regards,
> >> >
> >> > Gert Vanthienen
> >> > 
> >> > Open Source SOA: http://fusesource.com
> >> > Blog: http://gertvanthienen.blogspot.com/
> >> >
> >>
> >
> > --
> > Cheers, Stuart
> >
>



-- 
Cheers, Stuart

[jira] Created: (FELIX-1356) Piping output from multiple statements on single line should behave similar to how Unix shells handle redirection.

2009-07-13 Thread Hiram Chirino (JIRA)

Piping output from multiple statements on single line should behave similar to 
how Unix shells handle redirection.
--

 Key: FELIX-1356
 URL: https://issues.apache.org/jira/browse/FELIX-1356
 Project: Felix
  Issue Type: Improvement
Reporter: Hiram Chirino


Use compare the command and result of these unix shell statements:

$ echo hello ; echo hello | echo world
hello
world

With the gogo equivalent:

$ echo hello ; echo hello | echo world
world


Seems like in the gogo case the pipe is applied to both statements while in the 
unix case, the pipe is only applied to the statement the pipe is defined in.


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

[jira] Created: (FELIX-1355) Provide common mechanism to configure repositories between server side build and eclipse integration

Provide common mechanism to configure repositories between server side build 
and eclipse integration


 Key: FELIX-1355
 URL: https://issues.apache.org/jira/browse/FELIX-1355
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage


Sigil provides an API to configure resolvers to locate OSGi dependencies 
however the ivy build and eclipse build look in different places to find out 
which resolvers are enabled for a particular project.

* The ivy build uses a properties file format that can be shared by nested sub 
projects
* The eclipse build uses eclipse preferences to configure workspace specific 
configuration

This involves duplication of effort on the part of developers using sigil. 

The shared properties file format is generally preferred as it enables checkin 
to version control mechanisms such as cvs, svn, git, etc also it reduces 
duplication of information at leaf nodes. 

The problem for the eclipse side of things is that eclipse has no notion of 
nested projects so if you were to import projects from different top level 
projects it is not intuitive to the developer which settings they are editting 
and whether edits will effect other projects.

-- 
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-1325) gogo doesn't report a command not found error unless an argument is supplied

2009-07-13 Thread Derek Baum

I would also be happy with

> x = hello world
> x = "hello world"

being equivalent.

Gogo is based on RFC132, <
http://www.osgi.org/download/osgi-4.2-early-draft.pdf>
which defines the syntax of the TSL Language, so we need to be careful about
making apparently trivial changes that conflict with the RFC, as Gogo would
not then be compatible with other RFC132 implementations.

However, RFC132 is only a draft and I'm sure that constructive comments will
be welcomed.
I have already raised some at osgi.org: <
https://www.osgi.org/bugzilla/buglist.cgi?bug_status=__open__>

The use of backquotes for command execution was considered in the RFC, but
rejected because they can't easily be nested. However, bash and all modern
shells now support $(...) as an alternative to backquotes, and this
construct can be nested.

RFC132 already uses parenthesis () to create a literal LDAP expression. I'm
not sure that this is very useful, as a converter could be registered to
convert a string to an LDAP expression when required. This would then make
parenthesis available to be used as $(). I have mentioned this in
https://www.osgi.org/bugzilla/show_bug.cgi?id=50

Derek

2009/7/13 Hiram Chirino (JIRA) 

>
>[
> https://issues.apache.org/jira/browse/FELIX-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730430#action_12730430]
>
> Hiram Chirino commented on FELIX-1325:
> --
>
> That raises more questions for me.
>
> For me the sane way for a shell to handle assignment statements would have
> been something like this.
>
> > x=Hello World
> > x="Hello World"
>
> Either of the above are equivalent.  And no Hello is not executed as
> command.  If you do want to evaluate a command, it would be something like:
>
> > x=
>
> I would have preferred, using `Hello World` over , but it
> seems you guys prefer the latter because it is easier to parse recursive
> constructs.
>
> Make sense?
>
>
>
> > gogo doesn't report a command not found error unless an argument is
> supplied
> >
> 
> >
> > Key: FELIX-1325
> > URL: https://issues.apache.org/jira/browse/FELIX-1325
> > Project: Felix
> >  Issue Type: Improvement
> >  Components: Gogo
> >Reporter: Derek Baum
> >Assignee: Derek Baum
> >Priority: Minor
> >
> > 2009/7/13 Hiram Chirino  wrote:
> > But on related note... to the gogo developers: I would have expected
> a
> > command not found error when you type in a command that's not found.
>  This
> > seems to work fine if you pass an argument to a command.  It this a
> 'feature' or a bug?
> > This is a 'feature', in that an undefined command silently returns
> itself, rather than an error.
> > This is so that:
> > > x = hello
> > works; otherwise the assignment would fail, with a command not found
> error.
> > Note: that
> > > x = hello world
> > will actually evaluate the 'hello' command with 'world' as an argument.
> > > x = "hello world"
> > tries to evaulate the 'hello world' command, which probably doesn't
> exist, so it falls back to returning the value, rather than unknown command.
> > I think this can be simply resolved by avoiding re-evaluating an
> assignment with a single argument.
> > This will mean that
> > > x = hello
> > works as it does currently, but that
> > > hello
> > will fail with 'unknown command', rather than simply return itself.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

[jira] Assigned: (FELIX-1333) Port documentation from http://sigil.codecauldron.org to felix confluence


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

David Savage reassigned FELIX-1333:
---

Assignee: David Savage

> Port documentation from http://sigil.codecauldron.org to felix confluence
> -
>
> Key: FELIX-1333
> URL: https://issues.apache.org/jira/browse/FELIX-1333
> Project: Felix
>  Issue Type: Task
>  Components: Sigil
>Reporter: David Savage
>Assignee: David Savage
>


-- 
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-1325) gogo doesn't report a command not found error unless an argument is supplied

2009-07-13 Thread Richard S. Hall

On 7/13/09 4:06 PM, Derek Baum wrote:

I would also be happy with

x = hello world
x = "hello world"

being equivalent.

Gogo is based on RFC132,<
http://www.osgi.org/download/osgi-4.2-early-draft.pdf>
which defines the syntax of the TSL Language, so we need to be careful about
making apparently trivial changes that conflict with the RFC, as Gogo would
not then be compatible with other RFC132 implementations.

I think this is an important point to keep in mind. The point of Gogo is
to try to standardize on a shell for OSGi frameworks, so if you want to
run completely wild, you will likely need to create your own
shell...which is fine.

However, RFC132 is only a draft and I'm sure that constructive comments will
be welcomed.
I have already raised some at osgi.org:<
https://www.osgi.org/bugzilla/buglist.cgi?bug_status=__open__>

And this is another important point to keep in mind too. The whole point
of doing this in the open is to feed reasonable comments into the RFC
before it becomes a spec.

We have a balancing act to perform.

-> richard

The use of backquotes for command execution was considered in the RFC, but
rejected because they can't easily be nested. However, bash and all modern
shells now support $(...) as an alternative to backquotes, and this
construct can be nested.

RFC132 already uses parenthesis () to create a literal LDAP expression. I'm
not sure that this is very useful, as a converter could be registered to
convert a string to an LDAP expression when required. This would then make
parenthesis available to be used as $(). I have mentioned this in
https://www.osgi.org/bugzilla/show_bug.cgi?id=50

Derek

2009/7/13 Hiram Chirino (JIRA)

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

Hiram Chirino commented on FELIX-1325:
--

That raises more questions for me.

For me the sane way for a shell to handle assignment statements would have
been something like this.

x=Hello World
x="Hello World"

Either of the above are equivalent. And no Hello is not executed as
command. If you do want to evaluate a command, it would be something like:

I would have preferred, using `Hello World` over, but it
seems you guys prefer the latter because it is easier to parse recursive
constructs.

Make sense?

gogo doesn't report a command not found error unless an argument is

supplied

Key: FELIX-1325
URL: https://issues.apache.org/jira/browse/FELIX-1325
Project: Felix
Issue Type: Improvement
Components: Gogo
Reporter: Derek Baum
Assignee: Derek Baum
Priority: Minor

2009/7/13 Hiram Chirino wrote:
But on related note... to the gogo developers: I would have expected

command not found error when you type in a command that's not found.

This

seems to work fine if you pass an argument to a command. It this a

'feature' or a bug?

This is a 'feature', in that an undefined command silently returns

itself, rather than an error.

This is so that:

x = hello

works; otherwise the assignment would fail, with a command not found

error.

Note: that

x = hello world

will actually evaluate the 'hello' command with 'world' as an argument.

x = "hello world"

tries to evaulate the 'hello world' command, which probably doesn't

exist, so it falls back to returning the value, rather than unknown command.

I think this can be simply resolved by avoiding re-evaluating an

assignment with a single argument.

This will mean that

x = hello

works as it does currently, but that

hello

will fail with 'unknown command', rather than simply return itself.

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

[jira] Commented: (FELIX-1015) Hardcoded HTML Header/Footer in AbstractWebConsolePlugin

2009-07-13 Thread Marcin Wilkos (JIRA)


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

Marcin Wilkos commented on FELIX-1015:
--

It looks ok for me. Let's put it into svn.

> Hardcoded HTML Header/Footer in AbstractWebConsolePlugin
> 
>
> Key: FELIX-1015
> URL: https://issues.apache.org/jira/browse/FELIX-1015
> Project: Felix
>  Issue Type: Sub-task
>  Components: Web Console
>Affects Versions: webconsole-1.2.8
>Reporter: Thomas Diesler
>Assignee: Felix Meschberger
> Attachments: branding.patch, branding2.patch, 
> FELIX-1015-fmeschbe.patch
>
>
> Instead of 
> private static final String HEADER = " encoding=\"UTF-8\" ?>"
> + " \"xhtml1-transitional.dtd\">"
> + "http://www.w3.org/1999/xhtml\";>"
> + ""
> + ""
> + ""
> + "{0} - {2}"
> + " language=\"JavaScript\">"
> + " language=\"JavaScript\">"
> + " language=\"JavaScript\">"
> + ""
> + ""
> + "appRoot = \"{5}\";"
> + "pluginRoot = appRoot + \"/{6}\";"
> + ""
> + " type=\"text/css\">"
> + ""
> + ""
> + ""
> + ""
> + ""
> + "{0}{2}"
> + ""
> + ""
> + " src=\"{5}/res/imgs/logo.png\" width=\"165\" height=\"63\" border=\"0\">"
> + "" + "";
> we propose 
> protected String getHeader()
> {
>String HEADER = ""
> + " \"xhtml1-transitional.dtd\">"
> + "http://www.w3.org/1999/xhtml\";>"
> + ""
> + ""
> + ""
> + "{0} - {2}"
> + " language=\"JavaScript\">"
> + " language=\"JavaScript\">"
> + " language=\"JavaScript\">"
> + ""
> + ""
> + "appRoot = \"{5}\";"
> + "pluginRoot = appRoot + \"/{6}\";"
> + ""
> + " type=\"text/css\">"
> + ""
> + ""
> + ""
> + ""
> + ""
> + "{0}{2}"
> + ""
> + ""
> + " src=\"{5}/res/imgs/logo.png\" width=\"165\" height=\"63\" border=\"0\">"
> + "" + "";
>return HEADER;
> }
> -
> protected PrintWriter startResponse( HttpServletRequest request, 
> HttpServletResponse response ) throws IOException
> {
> ...
> String header = MessageFormat.format( getHeader(), new Object[]
> }
> protected void endResponse( HttpServletRequest request, PrintWriter pw )
> {
> pw.println( "" );
> pw.println( "" );
> }

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

[jira] Commented: (FELIX-1356) Piping output from multiple statements on single line should behave similar to how Unix shells handle redirection.


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

Derek Baum commented on FELIX-1356:
---

> Seems like in the gogo case the pipe is applied to both statements while in 
> the unix case, the pipe is only applied to the statement the pipe is defined 
> in.

yes, this is as defined in RFC132:

program ::= statements ( '|' statements ) *
statements ::= statement ( ';' statement ) *

so the pipe is defined as connecting groups of statements, separated by ;

However, we could suggest it is redefined to be more Unix like (fewer surprises 
for those who know Unix).
We could then use parenthesis () to group statement, just as you would in bash:

> (echo hello ; echo hello) | echo world

This would require not using parenthesis to create literal LDAP expressions, as 
they do at present, as I mentioned in the comment 
onhttps://issues.apache.org/jira/browse/FELIX-1325

Derek

> Piping output from multiple statements on single line should behave similar 
> to how Unix shells handle redirection.
> --
>
> Key: FELIX-1356
> URL: https://issues.apache.org/jira/browse/FELIX-1356
> Project: Felix
>  Issue Type: Improvement
>Reporter: Hiram Chirino
>
> Use compare the command and result of these unix shell statements:
> $ echo hello ; echo hello | echo world
> hello
> world
> With the gogo equivalent:
> $ echo hello ; echo hello | echo world
> world
> Seems like in the gogo case the pipe is applied to both statements while in 
> the unix case, the pipe is only applied to the statement the pipe is defined 
> in.

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

[jira] Commented: (FELIX-1325) gogo doesn't report a command not found error unless an argument is supplied

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

Derek Baum commented on FELIX-1325:
---

[reply to dev list added as issue comment]

I would also be happy with

> x = hello world
> x = "hello world"

being equivalent.

Gogo is based on RFC132, 
which defines the syntax of the TSL Language, so we need to be careful about 
making apparently trivial changes that conflict with the RFC, as Gogo would not 
then be compatible with other RFC132 implementations.

However, RFC132 is only a draft and I'm sure that constructive comments will be 
welcomed.
I have already raised some at osgi.org: 

The use of backquotes for command execution was considered in the RFC, but 
rejected because they can't easily be nested. However, bash and all modern 
shells now support $(...) as an alternative to backquotes, and this construct 
can be nested.

RFC132 already uses parenthesis () to create a literal LDAP expression. I'm not 
sure that this is very useful, as a converter could be registered to convert a 
string to an LDAP expression when required. This would then make parenthesis 
available to be used as $(). I have mentioned this in 
https://www.osgi.org/bugzilla/show_bug.cgi?id=50

> gogo doesn't report a command not found error unless an argument is supplied
> 
>
> Key: FELIX-1325
> URL: https://issues.apache.org/jira/browse/FELIX-1325
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
>
> 2009/7/13 Hiram Chirino  wrote:
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found.  This
> seems to work fine if you pass an argument to a command.  It this a 
> 'feature' or a bug?
> This is a 'feature', in that an undefined command silently returns itself, 
> rather than an error.
> This is so that:
> > x = hello
> works; otherwise the assignment would fail, with a command not found error.
> Note: that
> > x = hello world
> will actually evaluate the 'hello' command with 'world' as an argument.
> > x = "hello world"
> tries to evaulate the 'hello world' command, which probably doesn't exist, so 
> it falls back to returning the value, rather than unknown command.
> I think this can be simply resolved by avoiding re-evaluating an assignment 
> with a single argument.
> This will mean that
> > x = hello
> works as it does currently, but that
> > hello
> will fail with 'unknown command', rather than simply return itself.

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

[jira] Created: (FELIX-1357) Simplify sigil directory structure - get rid of redundant information from directory names

Simplify sigil directory structure - get rid of redundant information from 
directory names
--

 Key: FELIX-1357
 URL: https://issues.apache.org/jira/browse/FELIX-1357
 Project: Felix
  Issue Type: Improvement
  Components: Sigil
Reporter: David Savage
Priority: Minor




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

[jira] Commented: (FELIX-1325) gogo doesn't report a command not found error unless an argument is supplied

2009-07-13 Thread Hiram Chirino (JIRA)


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

Hiram Chirino commented on FELIX-1325:
--

Awesome.. from you comments and the issues you've opened up against the RFC, it 
seems we are in agreement that the osgi shell should be familiar to unix shell 
dudes.
How often do they review the RFC feedback and accept/reject proposals?

> gogo doesn't report a command not found error unless an argument is supplied
> 
>
> Key: FELIX-1325
> URL: https://issues.apache.org/jira/browse/FELIX-1325
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
>
> 2009/7/13 Hiram Chirino  wrote:
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found.  This
> seems to work fine if you pass an argument to a command.  It this a 
> 'feature' or a bug?
> This is a 'feature', in that an undefined command silently returns itself, 
> rather than an error.
> This is so that:
> > x = hello
> works; otherwise the assignment would fail, with a command not found error.
> Note: that
> > x = hello world
> will actually evaluate the 'hello' command with 'world' as an argument.
> > x = "hello world"
> tries to evaulate the 'hello world' command, which probably doesn't exist, so 
> it falls back to returning the value, rather than unknown command.
> I think this can be simply resolved by avoiding re-evaluating an assignment 
> with a single argument.
> This will mean that
> > x = hello
> works as it does currently, but that
> > hello
> will fail with 'unknown command', rather than simply return itself.

-- 
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-1325) gogo doesn't report a command not found error unless an argument is supplied

2009-07-13 Thread Richard S. Hall

On 7/13/09 4:51 PM, Hiram Chirino (JIRA) wrote:

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

Hiram Chirino commented on FELIX-1325:
--

Awesome.. from you comments and the issues you've opened up against the RFC, it
seems we are in agreement that the osgi shell should be familiar to unix shell
dudes.
How often do they review the RFC feedback and accept/reject proposals?

It doesn't really operate smoothly like this, unfortunately. Right now,
the finalization of the R4.2 specs are consuming most of the cycles of
OSGi Alliance members and I don't think the shell is necessarily
targeted for this release. So, we might not hear too much right now, but
I will try to bug people.

-> richard

gogo doesn't report a command not found error unless an argument is supplied

Key: FELIX-1325
URL: https://issues.apache.org/jira/browse/FELIX-1325
Project: Felix
Issue Type: Improvement
Components: Gogo
Reporter: Derek Baum
Assignee: Derek Baum
Priority: Minor

2009/7/13 Hiram Chirino wrote:
But on related note... to the gogo developers: I would have expected a
command not found error when you type in a command that's not found. This
seems to work fine if you pass an argument to a command. It this a
'feature' or a bug?
This is a 'feature', in that an undefined command silently returns itself,
rather than an error.
This is so that:

x = hello

works; otherwise the assignment would fail, with a command not found error.
Note: that

x = hello world

will actually evaluate the 'hello' command with 'world' as an argument.

x = "hello world"

tries to evaulate the 'hello world' command, which probably doesn't exist, so
it falls back to returning the value, rather than unknown command.
I think this can be simply resolved by avoiding re-evaluating an assignment
with a single argument.
This will mean that

x = hello

works as it does currently, but that

hello

will fail with 'unknown command', rather than simply return itself.

[jira] Created: (FELIX-1358) Create gogo cli for sigil junit integration

Create gogo cli for sigil junit integration
---

 Key: FELIX-1358
 URL: https://issues.apache.org/jira/browse/FELIX-1358
 Project: Felix
  Issue Type: New Feature
  Components: Sigil
Reporter: David Savage
Priority: Minor




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

[jira] Closed: (FELIX-1333) Port documentation from http://sigil.codecauldron.org to felix confluence


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

David Savage closed FELIX-1333.
---

Resolution: Fixed

Ported relevant eclipse, ivy, junit and repository documentation from 
codecauldron.org

> Port documentation from http://sigil.codecauldron.org to felix confluence
> -
>
> Key: FELIX-1333
> URL: https://issues.apache.org/jira/browse/FELIX-1333
> Project: Felix
>  Issue Type: Task
>  Components: Sigil
>Reporter: David Savage
>Assignee: David Savage
>


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

[jira] Updated: (FELIX-1325) gogo doesn't report a command not found error unless an argument is supplied


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

Derek Baum updated FELIX-1325:
--

Attachment: FELIX-1325.patch

I attach the full patch including update to tests for this change.
I will not commit it for a few days to allow time for comments from the dev 
list.

Many of the tests made extreme use of command evaluation defaulting to the 
value if not found.
For example:

assertEquals("a b", c.execute("echo ${c}  b | capture"));

here the ${c} forces c to be evaluated as a command, which now fails with 
command not found

assertEquals("3", c.execute("[a=2 =<3>] get b").toString());

here the  and <3> would now fail as b and 3 are not defined as commands

assertEquals("a", c.execute("e = { echo $0 } ; "));

here e a b produces a, but the <> cause a to be evaluated again, which fails as 
it is not defined as a command.

> gogo doesn't report a command not found error unless an argument is supplied
> 
>
> Key: FELIX-1325
> URL: https://issues.apache.org/jira/browse/FELIX-1325
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
> Attachments: FELIX-1325.patch
>
>
> 2009/7/13 Hiram Chirino  wrote:
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found.  This
> seems to work fine if you pass an argument to a command.  It this a 
> 'feature' or a bug?
> This is a 'feature', in that an undefined command silently returns itself, 
> rather than an error.
> This is so that:
> > x = hello
> works; otherwise the assignment would fail, with a command not found error.
> Note: that
> > x = hello world
> will actually evaluate the 'hello' command with 'world' as an argument.
> > x = "hello world"
> tries to evaulate the 'hello world' command, which probably doesn't exist, so 
> it falls back to returning the value, rather than unknown command.
> I think this can be simply resolved by avoiding re-evaluating an assignment 
> with a single argument.
> This will mean that
> > x = hello
> works as it does currently, but that
> > hello
> will fail with 'unknown command', rather than simply return itself.

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

[jira] Updated: (FELIX-1325) gogo doesn't report a command not found error unless an argument is supplied


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

Derek Baum updated FELIX-1325:
--

Attachment: (was: FELIX-1325.patch)

> gogo doesn't report a command not found error unless an argument is supplied
> 
>
> Key: FELIX-1325
> URL: https://issues.apache.org/jira/browse/FELIX-1325
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo
>Reporter: Derek Baum
>Assignee: Derek Baum
>Priority: Minor
>
> 2009/7/13 Hiram Chirino  wrote:
> But on related note... to the gogo developers: I would have expected a
> command not found error when you type in a command that's not found.  This
> seems to work fine if you pass an argument to a command.  It this a 
> 'feature' or a bug?
> This is a 'feature', in that an undefined command silently returns itself, 
> rather than an error.
> This is so that:
> > x = hello
> works; otherwise the assignment would fail, with a command not found error.
> Note: that
> > x = hello world
> will actually evaluate the 'hello' command with 'world' as an argument.
> > x = "hello world"
> tries to evaulate the 'hello world' command, which probably doesn't exist, so 
> it falls back to returning the value, rather than unknown command.
> I think this can be simply resolved by avoiding re-evaluating an assignment 
> with a single argument.
> This will mean that
> > x = hello
> works as it does currently, but that
> > hello
> will fail with 'unknown command', rather than simply return itself.

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

[jira] Updated: (FELIX-1325) gogo doesn't report a command not found error unless an argument is supplied