from:"Toni Menzel"

DPs with Bundles having parametrized SymbolicNames throw Exception
--

 Key: FELIX-1305
 URL: https://issues.apache.org/jira/browse/FELIX-1305
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Reporter: Toni Menzel


For example: 
Bundle-SymbolicName=foo;singleton=true never matches installed bundle headers 
unless parameters are stripped. (Patch)


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

[jira] Updated: (FELIX-1305) DPs with Bundles having parametrized SymbolicNames throw Exception


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

Toni Menzel updated FELIX-1305:
---

Attachment: felix-deploymentadmin-symbolicname.patch

 DPs with Bundles having parametrized SymbolicNames throw Exception
 --

 Key: FELIX-1305
 URL: https://issues.apache.org/jira/browse/FELIX-1305
 Project: Felix
  Issue Type: Bug
  Components: Deployment Admin
Reporter: Toni Menzel
 Attachments: felix-deploymentadmin-symbolicname.patch


 For example: 
 Bundle-SymbolicName=foo;singleton=true never matches installed bundle headers 
 unless parameters are stripped. (Patch)

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

[jira] Created: (FELIX-1306) getDataFile handling in DeploymentSessionImpl sometimes does not work

getDataFile handling in DeploymentSessionImpl sometimes does not work
-

 Key: FELIX-1306
 URL: https://issues.apache.org/jira/browse/FELIX-1306
 Project: Felix
  Issue Type: Improvement
  Components: Deployment Admin
Reporter: Toni Menzel
 Attachments: felix-deploymentadmim-deploymentsession-datafile.patch

This is not really a bug but can be improved. Getting BundleContext from Bundle 
instance via reflection currently does not catch all bundle implementations.
To be safe, a second lookup with getMethods(..) is done.

Also this component (amongst others) can really need some documentation. Some 
(for class under patch) has been added (like reference to corresponding specs 
because osgi-API is not really dead clear at that point).

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

[jira] Updated: (FELIX-1306) getDataFile handling in DeploymentSessionImpl sometimes does not work


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

Toni Menzel updated FELIX-1306:
---

Attachment: felix-deploymentadmim-deploymentsession-datafile.patch

includes an extended hunt for getBundleContext methods via reflection and 
some more docs.

 getDataFile handling in DeploymentSessionImpl sometimes does not work
 -

 Key: FELIX-1306
 URL: https://issues.apache.org/jira/browse/FELIX-1306
 Project: Felix
  Issue Type: Improvement
  Components: Deployment Admin
Reporter: Toni Menzel
 Attachments: felix-deploymentadmim-deploymentsession-datafile.patch


 This is not really a bug but can be improved. Getting BundleContext from 
 Bundle instance via reflection currently does not catch all bundle 
 implementations.
 To be safe, a second lookup with getMethods(..) is done.
 Also this component (amongst others) can really need some documentation. Some 
 (for class under patch) has been added (like reference to corresponding 
 specs because osgi-API is not really dead clear at that point).

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

[jira] Created: (FELIX-1307) Log situation in DeploymentAdmin impl very unclear

Log situation in DeploymentAdmin impl very unclear
--

 Key: FELIX-1307
 URL: https://issues.apache.org/jira/browse/FELIX-1307
 Project: Felix
  Issue Type: Improvement
  Components: Deployment Admin
Reporter: Toni Menzel
Priority: Trivial


e.g. StartBundleCommand.java : 
has this:
// TODO: m_log.log(LogService.LOG_DEBUG, won't wait for Packages refreshed 
event, event is already received);

all over the place.
And not just this one.

Question: what is the intend of commenting this out ? What is the plan here ?

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

Re: New committer - Filippo Diotalevi

2009-06-30 Thread Toni Menzel

Congrats, man !

On Tue, Jun 30, 2009 at 3:55 PM, Felix Meschbergerfmesc...@gmail.com wrote:
 Welcome to the team, Filippo !

 Regards
 Felix

 Richard S. Hall schrieb:
 Hello,

 I wanted to let everyone know that Filippo Diotalevi has been accepted
 as a new committer for his continued contributions around File Install,
 web site documentation, and more.

 Keep up the good work, Filippo, and thanks for your contribution.

 - richard





-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

DependencyManager + DeploymentAdmin used in Apache ACE

2009-06-29 Thread Toni Menzel

Hi,

Apache Ace, new in incubator and since last weekend also with code in
svn, has some dependencies of Felix Subprojects like DependencyManager
and (more important to me at least) DeploymentAdmin.
Those have never released so far but should be, if you ask me, at
least accessable as snapshot builds from some maven repository. Would
that make big problems ?
How about deploying them - as they are - at
http://people.apache.org/repo/m2-snapshot-repository/org/apache/felix/
or similar ?

Once they are there, its much easier to use/test/evaluate them even
outside of Ace.

?
cheers, Toni

-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [VOTE] Apache Felix File Install 1.2.0

2009-06-27 Thread Toni Menzel

+1

On Sat, Jun 27, 2009 at 6:30 PM, Karl Paulskarlpa...@gmail.com wrote:
 +1

 regards,

 Karl

 On Tue, Jun 23, 2009 at 5:59 PM, Clement
 Escoffierclement.escoff...@gmail.com wrote:
 +1,

 Except the changelog not up to date (already fixed by Richard in the trunk),
 everything is perfect.

 Regards,

 Clement

 On 23.06.2009, at 15:24, Rob Walker wrote:

 +1

 On 6/22/09 4:45 PM, Richard S. Hall wrote:

 I'd like to call a vote for the Apache Felix File Install 1.2.0. We
 solved 8 issues in this release:

 http://issues.apache.org/jira/browse/FELIX/fixforversion/12313932

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

 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 005 /tmp/felix-staging

 Please vote to approve this release:

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

 This vote will be open for 72 hours.

 --


 Ascert - Taking systems to the Edge
 r...@ascert.com
 +44 (0)20 7488 3470
 www.ascert.com






 --
 Karl Pauls
 karlpa...@gmail.com




-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [VOTE] Felix 1.8.1 framework and main subproject releases

2009-06-24 Thread Toni Menzel

+1

On 6/24/09, Stuart McCulloch mccu...@gmail.com wrote:
 2009/6/21 Karl Pauls karlpa...@gmail.com

 I would like to call a vote on the framework and main 1.8.1 subproject
 releases.

 This is a bug fix release mainly to allow felix to run with limited
 permissions when a security manager is installed.

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

 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 3 /tmp/felix-staging

 Please vote to approve this release:

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


 +1

 --
 Cheers, Stuart



-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: New feature in FileInstall

2009-06-24 Thread Toni Menzel

If someone needs votes for doing this effectively, here's my +1

On Wed, Jun 24, 2009 at 5:39 PM, Alin Dreghiciu adreghi...@gmail.comwrote:

Well, we are talking about pretty much a small change as it only adds the
code to read the content of the link file and instead of a file input
stream
it uses url.openStream. So, it does not introduce any new dependency and
the
changes are relative small in
size. I can out up a patch quickly. It may look like a lot of changes
but is just moving code around.

On Wed, Jun 24, 2009 at 4:39 PM, Richard S. Hall he...@ungoverned.org
wrote:

On 6/24/09 8:52 AM, Filippo Diotalevi wrote:

On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciuadreghi...@gmail.com
wrote:

Hi guys,
Yesterday I got the question if Pax URLs are supported by FileInstall.
Of
course there are not as you must have the bundle in the scanned
directory.
But, In my view with quite a simple change this can be done. And is
about
making FileInstall support any url, so including pax urls.
The idea is that file install to support beside jar, .cfg files also
.lnk
files. What is a link file? A simple text file that contains the url of
the
actual bundle to be installed.
So, if file install finds such a file, it reads the content and
installs
the
bundle mentioned in the file via url. If .lnk file changes the old
content
(bundle) is uninstalled and the new one is installed.
To me looks like a powerful option. A more advanced usage would be
that
teh .lnk file to be a properties file with properties as url and
start
and startlevel.

Hi Alin,
as discussed at [1], I think that there is definitely interest for
extending FI to support other artifacts besides jar and cfg files.
On the other side, I'm also of the opinion that FI should be usable
with the minimum felix configuration (felix+shell+fileinstall), with
no additional dependencies.

I think the technical solution to make everybody happy should be the
same adopted by the Apache Karaf Deployer ([2]): keep the fileinstall
lightweight, supporting only jar and cfg, and use the whiteboard
pattern to allow the definition of additional deployers.

Doing this way, FI would remain clean and lightweight, and you will be
able to install new bundles adding additional support for other
artifacts (.lnk, .war, karaf features and so on)

WDYT?

I agree.

- richard

[1]

http://www.nabble.com/-DISCUSS--Align-Karaf-deployer-and-felix-fileinstall-td24030876.html#a24032869
[2]

http://svn.apache.org/repos/asf/felix/trunk/karaf/deployer/filemonitor/src/main/java/org/apache/felix/karaf/deployer/filemonitor/DeploymentListener.java

--
Alin Dreghiciu
Software Developer - Looking for new projects!
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.

--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: Zurich meetup

2009-06-20 Thread Toni Menzel

Will arrive in Zurich 8:15am on sunday. So.. dinner is great, but who joins
for breakfast ? ;)Tsss, those cheap Flights are insane.


On Fri, Jun 19, 2009 at 5:25 PM, Rob Walker r...@ascert.com wrote:

 Likewise!


 Richard S. Hall wrote:

 Wish I could be there!

 - richard

 On 6/19/09 10:28 AM, Filippo Diotalevi wrote:

 On Fri, Jun 19, 2009 at 4:23 PM, Marcel
 Offermansmarcel.offerm...@luminis.nl  wrote:


 First time for me too, so no clue about good meeting points, I should
 arrive
 Sunday around 17:00.




 I'll arrive on Sunday afternoon too.
 A good meeting point can be the central station (Hauptbahnhof).
  From there we can easily walk to have dinner in the center.





 --


 Ascert - Taking systems to the Edge
 r...@ascert.com
 +44 (0)20 7488 3470
 www.ascert.com




-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: Release Status of Deployment Admin Implementation

2009-06-16 Thread Toni Menzel

Hey,
Tell me what you have in mind. The Jira issues ? Localization is not
started yet i see. Auto-Config is in progress (you ?) and also has
some pieces in Apache Ace..
If i can help ? Just don't want to do overlap work.

On Tue, Jun 16, 2009 at 9:15 AM, Christian van
Spaandonkchristian.vanspaand...@luminis.nl wrote:
 Hi Toni,

  currently there is no concrete roadmap for releasing Deployment Admin. That, 
 however, does not mean we should not be working towards a release :)
 I have been planning on addressing some of the existing issues for some time, 
 I hope to have some time to spare for this purpose next month.

 friendly,
  Christian
 
 From: tonit@googlemail.com [tonit@googlemail.com] On Behalf Of Toni 
 Menzel [t...@okidokiteam.com]
 Sent: Sunday, June 14, 2009 1:36 AM
 To: dev@felix.apache.org
 Subject: Release Status of Deployment Admin Implementation

 Hi,

 just found that the deployment admin implementation (currently version
 0.9.0-SNAPSHOT) has not ever been released under the apache flag. Any
 plans to do so ? I see just
 http://issues.apache.org/jira/browse/FELIX-454: Autoconf
 http://issues.apache.org/jira/browse/FELIX-518: Localization

 Will the release delayed until both features are solved ?
 Otherwise i would like to see this - formally donated as 1.0 - version
 soon as 0.9.0 or so (current snapshot).


 Also, since recently it depends on a not yet released
 dependencymanager version (2.0.2-SNAPSHOT).
 There is just an outstanding patch:
 http://issues.apache.org/jira/browse/FELIX-1201
 Probably start with this ?

 Toni

 --
 Toni Menzel
 Independent Software Developer
 Professional Profile: http://okidokiteam.com
 t...@okidokiteam.com
 http://www.ops4j.org     - New Energy for OSS Communities - Open
 Participation Software.




-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: Deploying snapshots

2009-06-16 Thread Toni Menzel

Whats wrong with the public/private key combo ?
Just currious..

On 6/16/09, Gert Vanthienen gert.vanthie...@gmail.com wrote:
Richard,

I don't think you can use a system variable or something like that to
replace the settings password with Maven 2.0.x, but starting with
Maven 2.1.x you can encrypt the passwords so they no longer have to be
stored in plain text in your settings.xml file.

Regards,

Gert Vanthienen

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

2009/6/16 Richard S. Hall he...@ungoverned.org:
Yeah, I wanted to deploy snapshots of them and some others too, but it
wasn't working for me as well.

Is this the only way? I prefer to type in my password...

- richard

On 6/16/09 4:48 AM, Gert Vanthienen wrote:

Guillaume,

You should be able to do that if you specify your svn
username/password in the Maven settings.xml file (cfr.
http://maven.apache.org/developers/committer-settings.html).

We had a discussion about using Hudson/Nexus for doing regular
snapshot releases a while ago, but we decided to stick with our
current Bamboo CI server. There's a pending INFRA issue
(https://issues.apache.org/jira/browse/INFRA-2085) for getting that
box set up for snapshot releases.

Regards,

Gert Vanthienen

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

2009/6/16 Guillaume Nodetgno...@gmail.com:

I'd like to deploy snapshots of framework / main onto the snapshot
repository.
What's the way to do this ?
Atm, I end up with the following error:

[INFO] Error deploying artifact: Failed to transfer file:

https://repository.apache.org/content/repositories/snapshots/org/apache/felix/org.apache.felix.framework/1.9.0-SNAPSHOT/org.apache.felix.framework-1.9.0-20090616.082913-1.jar.
Return code is: 401

--
Cheers,
Guillaume Nodet

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

Open Source SOA
http://fusesource.com

--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Release Status of Deployment Admin Implementation

2009-06-13 Thread Toni Menzel

Hi,

just found that the deployment admin implementation (currently version
0.9.0-SNAPSHOT) has not ever been released under the apache flag. Any
plans to do so ? I see just
http://issues.apache.org/jira/browse/FELIX-454: Autoconf
http://issues.apache.org/jira/browse/FELIX-518: Localization

Will the release delayed until both features are solved ?
Otherwise i would like to see this - formally donated as 1.0 - version
soon as 0.9.0 or so (current snapshot).


Also, since recently it depends on a not yet released
dependencymanager version (2.0.2-SNAPSHOT).
There is just an outstanding patch:
http://issues.apache.org/jira/browse/FELIX-1201
Probably start with this ?

Toni

-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [VOTE] Felix 1.8.0 framework and main subproject releases

2009-05-11 Thread Toni Menzel

+1 (non binding vote)

On 5/11/09, Felix Meschberger fmesc...@gmail.com wrote:
 +1

 Regards
 Felix

 Karl Pauls schrieb:
 I would like to call a vote on the framework and main 1.8.0 subproject
 releases.

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

 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 16 /tmp/felix-staging

 Additionally, a convenience binary release is provided at:

 http://people.apache.org/~pauls/1.8.0

 Please vote to approve this release:

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




-- 
Toni Menzel
Independent Software Developer - Looking for new projects!
Professional Profile: http://www.osgify.com
Blog: tonitcom.blogspot.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [Karaf] Switching to blueprint ...

2009-04-29 Thread Toni Menzel

The separate VM is a followup of our default Pax Runner based
TestContainer implementation.
As such, there can be (many) different TestContainer implementations.
Its just a matter of convinience you lose when not using the pax runner
richness.
If there is demand for a native felix testcontainer, we could do so in
quite a short amount of time.

Toni

On Wed, Apr 29, 2009 at 9:01 AM, Guillaume Nodet gno...@gmail.com wrote:

 Cool.  Just one question though.  How difficult would it be to run the
 tests in the same JVM in an isolated classloader ?  It would make
 debugging way easier than having to hack the test to add the necessary
 jvm option for remote debugging.

 2009/4/29 Alin Dreghiciu adreghi...@gmail.com:
  About tests, afaik iPojo will move also towards Pax Exam. We are
 discussing
  with Clement about doing the necessary changes in Pax Exam to support all
  features required by iPojo tests which were available in junit4osgi.
 
  On Tue, Apr 28, 2009 at 4:45 PM, Guillaume Nodet gno...@gmail.com
 wrote:
 
  The past days, I've been working on the blueprint implementation
  inside Geronimo [1].
  The spec is still being written so the implementation is not really
  stable and is still missing a lot of features.
  However, it's already somewhat usable and as I've hacked Karaf to
  start using blueprint instead of spring-dm in a branch [2].
  Tests do not even compile, but I've been able to start the console, so
  I thought I would talk about it a bit.
 
  This raises the question whether we want to switch to blueprint
  instead of spring-dm.
  I think we should, and even have to, given that  Spring-DM will switch
  to support Blueprint at some point in the future too.  Also the
  blueprint spec is way better than spring-dm wrt to namespace handlers
  (that are considered dependencies, so we would not have problems with
  namespace handlers not being available when a bundle is started) and
  classloading (i think classes loaded for namespace handlers will be
  loaded from the namespace handler bundle, thus freeing the bundle to
  import all the namespace handlers packages), though those areas are in
  flux.
 
  If so, we might even want to do that before renaming the packages, as
  the patch is quite big and would be quite broken after the rename imho
  ...
 
  As for tests, we'd have to switch to something else, which could be
  junit4osgi from iPojo or pax-exam for example.
 
  Feedback welcome.
 
  [1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint
  [2]
 https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-blueprint/
 
  --
  Cheers,
  Guillaume Nodet
  
  Blog: http://gnodet.blogspot.com/
  
  Open Source SOA
  http://fusesource.com
 
 
 
 
  --
  Alin Dreghiciu
  http://www.ops4j.org - New Energy for OSS Communities - Open
 Participation
  Software.
  http://www.qi4j.org - New Energy for Java - Domain Driven Development.
  Looking for a job.
 



 --
 Cheers,
 Guillaume Nodet
 
 Blog: http://gnodet.blogspot.com/
 
 Open Source SOA
 http://fusesource.com




-- 
Toni Menzel
Independent Software Developer - Looking for new projects!
Professional Profile: http://www.osgify.com
Blog: tonitcom.blogspot.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [VOTE] Felix 1.6.1 framework and main subproject releases

2009-04-29 Thread Toni Menzel

+1

On Tue, Apr 28, 2009 at 12:28 PM, Richard S. Hall he...@ungoverned.orgwrote:

 +1

 - richard



 On 4/26/09 5:48 PM, Karl Pauls wrote:

 I would like to call a vote on the framework and main 1.6.1 subproject
 releases.

 The source and binary release archives, signature files, SHA and MD5
 message digests for each are available as zip and tar.gz here:

 http://people.apache.org/~pauls/1.6.1http://people.apache.org/%7Epauls/1.6.1

 Additionally, a binary release is included (called felix-1.6.1).

 Please vote to approve these release archives:

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





-- 
Toni Menzel
Independent Software Developer - Looking for new projects!
Professional Profile: http://www.osgify.com
Blog: tonitcom.blogspot.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [Karaf] Switching to blueprint ...

2009-04-29 Thread Toni Menzel

ok, we will have a solution tracked with this item:
http://issues.ops4j.org/browse/PAXEXAM-79


On Wed, Apr 29, 2009 at 10:02 AM, Clement Escoffier 
clement.escoff...@gmail.com wrote:


 On 29.04.2009, at 09:08, Toni Menzel wrote:

  The separate VM is a followup of our default Pax Runner based
 TestContainer implementation.
 As such, there can be (many) different TestContainer implementations.
 Its just a matter of convinience you lose when not using the pax runner
 richness.
 If there is demand for a native felix testcontainer, we could do so in
 quite a short amount of time.


 Yes, there is a demand :-).

 As you know, I did some test with pax-exam. I find it pretty cool, but my
 main issue is that it dramatically slow...
 For example, running 2000 test case with junit4osgi (same VM isolated
 classloader) takes around 5 minutes
 20 tests with pax:exam and the pax-runner container takes around 3 minutes.

 I agree that sometimes having a separated VM is great to avoid
 side-effects... But providing an alternative would be great:
 -(sometimes we're looking about side effects), but of course I have ideas
 about that that we can discuss (playing with test suite, were each test
 suite run it's own OSGi container...).


 Clement





 Toni

 On Wed, Apr 29, 2009 at 9:01 AM, Guillaume Nodet gno...@gmail.com
 wrote:

  Cool.  Just one question though.  How difficult would it be to run the
 tests in the same JVM in an isolated classloader ?  It would make
 debugging way easier than having to hack the test to add the necessary
 jvm option for remote debugging.

 2009/4/29 Alin Dreghiciu adreghi...@gmail.com:

 About tests, afaik iPojo will move also towards Pax Exam. We are

 discussing

 with Clement about doing the necessary changes in Pax Exam to support
 all
 features required by iPojo tests which were available in junit4osgi.

 On Tue, Apr 28, 2009 at 4:45 PM, Guillaume Nodet gno...@gmail.com

 wrote:


  The past days, I've been working on the blueprint implementation
 inside Geronimo [1].
 The spec is still being written so the implementation is not really
 stable and is still missing a lot of features.
 However, it's already somewhat usable and as I've hacked Karaf to
 start using blueprint instead of spring-dm in a branch [2].
 Tests do not even compile, but I've been able to start the console, so
 I thought I would talk about it a bit.

 This raises the question whether we want to switch to blueprint
 instead of spring-dm.
 I think we should, and even have to, given that  Spring-DM will switch
 to support Blueprint at some point in the future too.  Also the
 blueprint spec is way better than spring-dm wrt to namespace handlers
 (that are considered dependencies, so we would not have problems with
 namespace handlers not being available when a bundle is started) and
 classloading (i think classes loaded for namespace handlers will be
 loaded from the namespace handler bundle, thus freeing the bundle to
 import all the namespace handlers packages), though those areas are in
 flux.

 If so, we might even want to do that before renaming the packages, as
 the patch is quite big and would be quite broken after the rename imho
 ...

 As for tests, we'd have to switch to something else, which could be
 junit4osgi from iPojo or pax-exam for example.

 Feedback welcome.

 [1] https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint
 [2]

 https://svn.apache.org/repos/asf/felix/sandbox/gnodet/karaf-blueprint/


 --
 Cheers,
 Guillaume Nodet
 
 Blog: http://gnodet.blogspot.com/
 
 Open Source SOA
 http://fusesource.com




 --
 Alin Dreghiciu
 http://www.ops4j.org - New Energy for OSS Communities - Open

 Participation

 Software.
 http://www.qi4j.org - New Energy for Java - Domain Driven Development.
 Looking for a job.




 --
 Cheers,
 Guillaume Nodet
 
 Blog: http://gnodet.blogspot.com/
 
 Open Source SOA
 http://fusesource.com




 --
 Toni Menzel
 Independent Software Developer - Looking for new projects!
 Professional Profile: http://www.osgify.com
 Blog: tonitcom.blogspot.com
 t...@okidokiteam.com
 http://www.ops4j.org - New Energy for OSS Communities - Open
 Participation Software.





-- 
Toni Menzel
Independent Software Developer - Looking for new projects!
Professional Profile: http://www.osgify.com
Blog: tonitcom.blogspot.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [vote] Use Nexus repository infrastructure for snapshots/releases deployment

2009-04-07 Thread Toni Menzel

+1 (non binding)

On Tue, Apr 7, 2009 at 2:38 PM, Alin Dreghiciu adreghi...@gmail.com wrote:

 +1 (non binding)

 On Tue, Apr 7, 2009 at 2:42 PM, Stuart McCulloch mccu...@gmail.com
 wrote:
  Hi everyone,
 
  I'd like to call a vote on using the Nexus repository infrastructure for
  deploying snapshots/releases of Apache Felix
  The proposed changes to the Felix parent pom can be found here:
  https://issues.apache.org/jira/browse/FELIX-1029
 
  We'll also need to update our release docs to match (based on
  http://maven.apache.org/developers/release/releasing.html)
 
  So, WYDT?
 
  [ ] +1 Yes, use Nexus infrastructure for deploying snapshots/releases of
  Apache Felix
  [ ] -1 No, keep with the current release process (please provide specific
  comments)
 
  --
  Cheers, Stuart
 



 --
 Alin Dreghiciu
 http://www.ops4j.org - New Energy for OSS Communities - Open
 Participation Software.
 http://www.qi4j.org - New Energy for Java - Domain Driven Development.
 Looking for a job.
 Sent from Cluj-Napoca, CJ, Romania




-- 
Toni Menzel
Software Developer
Professional Profile: http://www.osgify.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

2009-04-03 Thread Toni Menzel

I am also torn into the possibilities.Putting Karaf under felix will keep
e.g. equinox advocates away (thats why Alex refer's to the devil :) ?)
Also, any possible shortcoming (technical or political) of felix will
directly affect Karaf as a higher level enterprisy solution.

On the other hand, the one-shop stop for osgi sounds nice and convinient.
But then you never stop and at best eat up ops4j pax tools as well next
time.

But to be honest, i never looked at smx4 before it was brought to the felix
list. And Karaf has to earn the brand that felix already has.
No real best solution at this point i guess.
Maybe someone should (from smx4) should try to formulate a positioning
statement.
Then things may become more clear probably.

cheers,
Toni

On Fri, Apr 3, 2009 at 11:38 AM, Alex Karasulu akaras...@gmail.com wrote:

 On Fri, Apr 3, 2009 at 9:50 AM, James Strachan james.strac...@gmail.com
 wrote:

  2009/4/3 Niclas Hedhman nic...@hedhman.org:
   On Tue, Mar 31, 2009 at 12:03 AM, Guillaume Nodet gno...@gmail.com
  wrote:
   During ApacheCon last week, there has been some discussions around
   moving ServiceMix Kernel as a subproject of Felix.
   ServiceMix Kernel is a packaged distribution of Felix designed for
   server side applications (see http://servicemix.apache.org/kernel/for
   more informations).
  
   I think this would be beneficial for this project as it would enable
   to build a much bigger community around it, increase the visibility
   and the awareness around it. Of course, it would need a new name, but
   that's another problem.
   Another area that could be included in this move is the ServiceMix
   specs (OSGi enhanced versions of Java EE specifications from Geronimo)
   and ServiceMix bundles (we've released a bunch of bundles already, see
   http://servicemix.apache.org/smx4/bundles-repository.html).
  
   Guys,
   considering how much attention this have received, and positive
   comments all around (i'll add mine now), why move it to Felix.
 
  I think the aim was to build up the Karaf community; unify and align
  with more of Felix and hopefully get folks from outside of ServiceMIx
  and Felix to contribute and then when the community has grown we can
  go TLP later on if required.
 

 Yep it brings Karaf developers closer to Felix and Felix developers closer
 to Karaf.  Furthermore it makes Felix a one stop shop for OSGi.  I don't
 think we have the fear of ballooning up to a Jakarta either.  I think
 Niclas, you, understand that so as your old friend I'm going to think this
 is one of your devil's advocate positions :-).

 Alex




-- 
Toni Menzel
Software Developer
Professional Profile: http://www.osgify.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [DISCUSS] Move ServiceMix Kernel into Felix as a subproject

2009-04-03 Thread Toni Menzel

On Fri, Apr 3, 2009 at 12:40 PM, James Strachan james.strac...@gmail.comwrote:

 2009/4/3 Toni Menzel t...@okidokiteam.com:
  I am also torn into the possibilities.Putting Karaf under felix will keep
  e.g. equinox advocates away (thats why Alex refer's to the devil :) ?)
  Also, any possible shortcoming (technical or political) of felix will
  directly affect Karaf as a higher level enterprisy solution.

 Not really - already Felix hosts lots of code which is independent of
 the actual OSGi runtime code - including a runtime adapter code so
 most of the Felix project itself can be used on equinox.


Yeah, but then its because felix contains just too much ?
You could also ask from felix perspective:
Does felix describes itself as a osgi r4 framework + (default) compendium
implementations
OR
an osgi ecosystem providing it all?

Its basically all about measuring the Apache Felix brand (=put karaf into
felix tpl project)
against the chance to start rising an independent osgi enterprise eco system
(where smx4knl already started at)



  On the other hand, the one-shop stop for osgi sounds nice and convinient.
  But then you never stop and at best eat up ops4j pax tools as well next
  time.
 
  But to be honest, i never looked at smx4 before it was brought to the
 felix
  list. And Karaf has to earn the brand that felix already has.
  No real best solution at this point i guess.
  Maybe someone should (from smx4) should try to formulate a positioning
  statement.
  Then things may become more clear probably.

 I wonder if this helps...
 http://servicemix.apache.org/SMX4KNL/index.html

how did i miss that?
But i would suggest to add the fact that is a kind of batteries included
solution because all those features are promises felix itself could make
when giving it a the right provisioning setup (fileinstall,url
handlers,configadmin ..)
The main benefit of caraf to me is
- that everything is at its place by default (batteries included)
- higher level provisioning: feature concept (not really highlighted on the
page currently)
- one shop stop for the features and their documentation (no true currently,
a real must TODO when opening karaf)

Don't get me wrong, as an osgi maniac its all fine  great but putting on
the standard J2EE-Hat we heard those days complaining about osgi (not ready
for enterprise) it is not clear immediately that smx4knl is a good
start  for starting with osgi.
Caraf really could start changing their minds when presented properly.



 http://servicemix.apache.org/SMX4KNL/index.html

 --
 James
 ---
 http://macstrac.blogspot.com/

 Open Source Integration
 http://fusesource.com/




-- 
Toni Menzel
Software Developer
Professional Profile: http://www.osgify.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [VOTE] release maven-bundle-plugin 2.0.0

2009-02-27 Thread Toni Menzel

+1 non binding vote

On Fri, Feb 27, 2009 at 11:04 AM, Alin Dreghiciu adreghi...@gmail.comwrote:

 +1 (not binding)

 On Fri, Feb 27, 2009 at 11:01 AM, Stuart McCulloch mccu...@gmail.com
 wrote:
  Hi folks,
 
  I'd like to start a vote for the 2.0.0 release of the
 maven-bundle-plugin.
  This release primarily contains a major update of the Bnd tool, which
  now requires you to build with a Java5 JDK. It also contains a number
  of improvements requested by the community to improve usability.
 
  [ note you can still compile for earlier JVMs by using the appropriate
   source and target levels in the maven-compiler-plugin configuration ]
 
  Release 2.0.0 of the maven-bundle-plugin fixes the following issues:
 
   FELIX-807,FELIX-782,FELIX-660,FELIX-549,FELIX-546,FELIX-545,
  FELIX-831,FELIX-677
  All fixed by updating to use the latest version of the Bnd
  Tool (0.0.311)
 
   FELIX-941: store the generated default symbolicname in
  $(maven-symbolicname) property
   FELIX-912: set default Export-Package based on local source files
   FELIX-684: support filters in excludeDependencies, such as
 *;scope=runtime
   FELIX-806: pickup archive settings and enable support of
  addMavenDescriptor setting
   FELIX-850: local fix for MSHARED-86 (should use isFile instead of
 exists)
   FELIX-899: widen dependency resolution and pass everything except
  test dependencies onto BND
   FELIX-760: commit latest bindex code (based on r95 from the OSGi
  subversion repository)
   FELIX-699: set analyzer base before loading properties in manifest goal
  [ plus additional debug to help with problem determination ]
 
  I've built and signed the release candidate and made it available here:
 
 
 http://people.apache.org/~mcculls/releases/felix/maven-bundle-plugin/2.0.0/org/apache/felix/maven-bundle-plugin/2.0.0/http://people.apache.org/%7Emcculls/releases/felix/maven-bundle-plugin/2.0.0/org/apache/felix/maven-bundle-plugin/2.0.0/
 
  You can also find the KEYS for verifying the signature in this directory.
  To use the staging area as a plugin repository, add this to your POM:
 
   pluginRepositories
 pluginRepository
   idbundleplugin.staging/id
   url
 http://people.apache.org/~mcculls/releases/felix/maven-bundle-plugin/2.0.0http://people.apache.org/%7Emcculls/releases/felix/maven-bundle-plugin/2.0.0
 /url
 /pluginRepository
   /pluginRepositories
 
  Please check this release and cast your votes - the vote will be open
  until Wednesday 4th March to give people time to test the new plugin
  (and also because I'm starting this vote on a Friday).
 
   [ ] +1 Yes, release it now
   [ ] -1 No, don't release now (please provide specific comments)
 
  --
  Cheers, Stuart
 
  -
  To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
  For additional commands, e-mail: users-h...@felix.apache.org
 
 



 --
 Alin Dreghiciu
 http://www.ops4j.org - New Energy for OSS Communities - Open
 Participation Software.
 http://www.qi4j.org - New Energy for Java - Domain Driven Development.
 http://www.codedragons.com - New Energy for Projects - Great People
 working on Great Projects at Great Places
 Sent from: Huissen Ge Netherlands.

 ___
 general mailing list
 gene...@lists.ops4j.org
 http://lists.ops4j.org/mailman/listinfo/general




-- 
Toni Menzel
Software Developer
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [VOTE] Release of the dependencymanager 2.0.0

2009-01-30 Thread Toni Menzel

+1 (non binding vote)

On Fri, Jan 30, 2009 at 8:42 PM, Pierre De Rop 
pierre.de_...@alcatel-lucent.fr wrote:

 +1

 /pierre


 Marcel Offermans wrote:

 Hello all,

 I'm opening a new vote for the first release candidate for the dependency
 manager and its  optional shell command bundle. I've compiled everything and
 put it up for testing and checking here:

 http://people.apache.org/~marrs/dependencymanager-2.0.0/

 The KEYS file for verifying the signature is also in this directory and
 the checksum files should have the correct format.

 The main reason for naming this release 2.0.0 is that there have been many
 1.x versions and snapshots out there, so to avoid any confusion I'm starting
 with 2.0.0.

 Please check the release and cast your votes, the vote will be open for at
 least 72 hours:

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

 Greetings, Marcel






-- 
Toni Menzel
Software Developer
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [VOTE] Release configadmin 1.0.8

2009-01-15 Thread Toni Menzel

+1 non binding vote

On Thu, Jan 15, 2009 at 3:30 PM, Marcel Offermans 
marcel.offerm...@luminis.nl wrote:

 +1




-- 
Toni Menzel
Software Developer
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [VOTE] Felix 1.4.0 framework and related subproject release

2008-11-08 Thread Toni Menzel

+1 (non binding).

 Original-Nachricht 
 Datum: Fri, 7 Nov 2008 18:33:26 +0100
 Von: Karl Pauls [EMAIL PROTECTED]
 An: dev@felix.apache.org
 Betreff: Re: [VOTE] Felix 1.4.0 framework and related subproject release

 On Fri, Nov 7, 2008 at 6:18 PM, Stuart McCulloch [EMAIL PROTECTED]
 wrote:
  2008/11/7 Karl Pauls [EMAIL PROTECTED]
 
  I would like to call a vote on the following subproject releases,
 
  bundlerepository 1.2.1
  framework 1.4.0
  main 1.4.0
 
  The source and binary release archives, signature files, SHA and MD5
  message digests for each are available as zip and tar.gz here:
 
 
 http://people.apache.org/~pauls/1.4.0http://people.apache.org/%7Epauls/1.4.0
 
  Additionally, a binary release is included (called felix-1.4.0).
 
  Please vote to approve these release archives:
 
  [ ] +1 Approve the releases
  [ ] -1 Veto the releases (please provide specific comments)
 
 
  FYI, I notice there are some additional files in the binary zip:
 
__MACOSX/...
 
  and the tgz:
 
._changelog_shell.txt
...
 
  these files don't seem to appear in the maven jars / zips
 
  so... +1 for the release, if these two binaries are cleaned up to remove
 the
  OSX cruft :)
 
 Good catch. Should be fixed now :-)
 
 regards,
 
 Karl
 
  --
  Cheers, Stuart
 
 
 
 
 -- 
 Karl Pauls
 [EMAIL PROTECTED]

Re: Library Enabling Test Framework...?

2008-06-04 Thread Toni Menzel

Yes, documentation is on the way.
The project goals as well as the main obstacles for not using springDM's 
implementation can be found here:
https://scm.ops4j.org/repos/ops4j/laboratory/users/tonit/incubator/drone/README

There will be an official announcement on the ops4j mailinglist along with 
real documentation on the ops4j wiki somehwat next week. (hope every one is 
subscribed to it ;-) ?)

till then,
/Toni

 Original-Nachricht 
 Datum: Wed, 4 Jun 2008 16:41:26 +0300
 Von: Alin Dreghiciu [EMAIL PROTECTED]
 An: dev@felix.apache.org
 Betreff: Re: Library Enabling Test Framework...?

 As Guillaume pointerd out, Spring DM Testing support should be able to
 solve your use case.
 Toni Menzel is also working on such a testing support as part of Pax
 Drone, which is now in hie incubator but I expect that soon to be
 ready to use. There is no documentation yet about, but soon. Toni?
 
 Alin Dreghiciu
 
 On Wed, Jun 4, 2008 at 3:55 PM, Alex Karasulu [EMAIL PROTECTED]
 wrote:
  Niclas, Robert,
 
  It sounded to me as if Robert was more interested in a integration
 testing
  framework rather than the build tool used to generate the manifest and
 build
  the bundle.  Please excuse me if I'm wrong here tho.
 
  I just wanted to say that Directory too would like to start using OSGi
 but
  the biggest impediment to date is having a good mini/micro integration
  testing framework to test our components in the container right after
 the
  bundle is generated by Maven for that module.  We don't want to have to
  create a foo module then a foo-test module just to integration test
 since
  this will lead to a (Maven) module explosion.  It would be nice to have
 a
  JUnit-ish framework for in situ testing OSGi bundles inside target
  containers.
 
  Like Robert we want to take bundle foo and make sure if it's a library,
 the
  classes there in function properly by running some tests that access
 those
  classes within the container.  If foo bundle exposes a service we'd like
 to
  get a handle on that service and start running some tests on it etc.
 
  I think such a framework would help increase uptake.
 
  Best Regards,
  Alex
 
  On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman [EMAIL PROTECTED]
 wrote:
 
  On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote:
   over in JAMES, we'd like to OSGi enable our upcoming library releases
   so that they can be used unforked in OSGi environments. the plan is
 to
   use the maven plugin but we don't have a lot of OSGi experience. so
   i'd like to add some integration tests to check that the libraries
   function ok when used in an OSGi environment. this seems a reasonably
   general requirement and i was wondering about a general integration
   testing micro library to test that a library was correctly enabled.
 
  Robert,
 
  I think the first necessary step is to incorporate the so called BND
 tool
  into
  your build. If you are using Maven, then there is a plugin available
 here
  to
  make it easier.
 
  BND recursively walks through the classes and figures out what is
 needed
  and
  compares that against a recipe that you specify. The recipe can
 either be
  explicit (in which case every import has to specified or else an error)
 or
  you use wildcards (less recommended).
  The recipe also contains information about which packages should be
  Exported,
  ignored and kept private.
 
  With BND it is not too hard to maintain the recipe (typically an
 external
  file), and will lower the initial need for in-container tests.
 
  Setting it up is easy, if you know what you are doing, so I suggest
 that
  someone here volunteers (Stuart???) to help you out.
 
 
  Cheers
  --
  Niclas Hedhman, Software Developer
 
  I  live here; http://tinyurl.com/2qq9er
  I  work here; http://tinyurl.com/2ymelc
  I relax here; http://tinyurl.com/2cgsug
 
 
 
 
 
 -- 
 Alin Dreghiciu
 http://www.ops4j.org - New Energy for OSS Communities - Open
 Participation Software.
 http://www.qi4j.org - New Energy for Java - Domain Driven Development.
 http://malaysia.jayway.net - New Energy for Projects - Great People
 working on Great Projects at Great Places

[jira] Commented: (FELIX-528) Support nested folders in fileinstall

2008-05-30 Thread Toni Menzel (JIRA)

[
https://issues.apache.org/jira/browse/FELIX-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601132#action_12601132
]

Toni Menzel commented on FELIX-528:
---

Does ANYONE care about this NEW (for felix) component anymore ?

I mean, there are some rather trivial patches flying arround Jira in this
component now since nearly two months.

Since nobody commits or rejects those patches, i don't see chances for bigger
enhancements to be added as well.
So, it would be nice if somebody could clarify the future of this component in
felix ?

Otherwise i would suggest other place for this component with lower barriers of
entry to make things happen. (?)

Toni

Support nested folders in fileinstall
-

Key: FELIX-528
URL: https://issues.apache.org/jira/browse/FELIX-528
Project: Felix
Issue Type: New Feature
Components: File Install
Reporter: Toni Menzel
Priority: Minor
Attachments: FELIX-528.patch

Currently FileInstall just supports flat jar-Files as bundles in its load
folder.
How about supporting (nested) folders?
This way, you could:
1. just drop an arbitrary folder structure and fileinstall would install all
bundles inside.
2. you could enable/disable entire bundle-sets with:
2a. in/move it out of the folder
2b. rename the folder with prefix that means unrecognized folder
Just a thought..
Toni

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

[jira] Updated: (FELIX-534) Allow filtering by status in ps command (shell)


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

Toni Menzel updated FELIX-534:
--

Attachment: FELIX-534_2.patch

well, you are right.
I implemented a unix style piping mechanism on top of the current Command 
implementation.

Now this is possible:
# ps | grep 'compendium'
# headers | grep 'Export-Package' | grep 'org.osgi.framework'

and alike.

The new GrepCommandImpl uses an extended Command Interface that supports 
InputStreams.
I integrated those type of commands into ShellServiceImpl.

Keep in mind that i fought a bit with the Piping stuff but ..well i'll try to 
fix things if they show up.

Anyway, wdyt about the general approach?

Toni



 Allow filtering by status in ps command (shell)
 ---

 Key: FELIX-534
 URL: https://issues.apache.org/jira/browse/FELIX-534
 Project: Felix
  Issue Type: New Feature
Reporter: Toni Menzel
Priority: Minor
 Attachments: FELIX-534.patch, FELIX-534_2.patch


 If you have many bundles it would be nice if you could filter certain status 
 when executing the ps command like so:
 ps active resolved -- shows active and resolved bundles
 ps -- shows all bundles (just like its currently)
 Simple solution is attached.
 btw.: there is no shell component in Felix Jira..

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

[jira] Updated: (FELIX-534) Allow filtering by status in ps command (shell)


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

Toni Menzel updated FELIX-534:
--

Attachment: (was: FELIX-534.patch)

 Allow filtering by status in ps command (shell)
 ---

 Key: FELIX-534
 URL: https://issues.apache.org/jira/browse/FELIX-534
 Project: Felix
  Issue Type: New Feature
Reporter: Toni Menzel
Priority: Minor
 Attachments: FELIX-534_2.patch


 If you have many bundles it would be nice if you could filter certain status 
 when executing the ps command like so:
 ps active resolved -- shows active and resolved bundles
 ps -- shows all bundles (just like its currently)
 Simple solution is attached.
 btw.: there is no shell component in Felix Jira..

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

[jira] Updated: (FELIX-534) Allow filtering by status in ps command (shell)


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

Toni Menzel updated FELIX-534:
--

Attachment: FELIX-534_3.patch

FELIX-534_3.patch is a revised patch without extra formatting.

The grep command now accepts a -e flag to submit raw regular expressions.



 Allow filtering by status in ps command (shell)
 ---

 Key: FELIX-534
 URL: https://issues.apache.org/jira/browse/FELIX-534
 Project: Felix
  Issue Type: New Feature
Reporter: Toni Menzel
Priority: Minor
 Attachments: FELIX-534_2.patch, FELIX-534_3.patch


 If you have many bundles it would be nice if you could filter certain status 
 when executing the ps command like so:
 ps active resolved -- shows active and resolved bundles
 ps -- shows all bundles (just like its currently)
 Simple solution is attached.
 btw.: there is no shell component in Felix Jira..

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

[jira] Updated: (FELIX-529) improve logging in FileInstall


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

Toni Menzel updated FELIX-529:
--

Attachment: FELIX-529.patch

LogService Support, Minore integration improvements for FileInstall 

- use LogService as primary log target. Fallback to sysout/err
- tighten visibility of member vars to private instead of packagelevel.
- contains feature FELIX-524 and FELIX-528
- replaced static references with explicit parameters
- cancelation flag should be (at least) volatile to ensure visibility
- renamed non obvious field names (like jarfile)

 improve logging in FileInstall
 --

 Key: FELIX-529
 URL: https://issues.apache.org/jira/browse/FELIX-529
 Project: Felix
  Issue Type: Bug
  Components: File Install
Reporter: Toni Menzel
Priority: Trivial
 Attachments: FELIX-529.patch


 Logging currently goes to System.err Stream and prints common null arguments 
 - like Exception.
 This leads to common messages like Installed pax-url-mvn-0.3.1-SNAPSHOT.jar: 
 null on the error console.
 Fix:
 - Remove exception if null. 
 - write messages to System.out (like they usually do in felix)
 (i think there is no patchfile required, is it?)

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

[jira] Commented: (FELIX-534) Allow filtering by status in ps command (shell)


[ 
https://issues.apache.org/jira/browse/FELIX-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588437#action_12588437
 ] 

Toni Menzel commented on FELIX-534:
---

Not sure about the word simple: Is the java.util.regex implementation too 
slow/memory intense itself to be used or is it the probability of complex 
stuff someone _could_ enter? 

I don't think an ldap filter would give better usability for 85% of usages 
compared to a simple substring matching.
In this case i'd just use a substring matching. 
Though it reduces much of the capabilities - not sure about maybe providing a 
different set of powerful commands for powerful machines?
And the whole piping thing makes a lot more stuff possible but won't run/be 
useful on small devices.



 Allow filtering by status in ps command (shell)
 ---

 Key: FELIX-534
 URL: https://issues.apache.org/jira/browse/FELIX-534
 Project: Felix
  Issue Type: New Feature
Reporter: Toni Menzel
Priority: Minor
 Attachments: FELIX-534_2.patch, FELIX-534_3.patch


 If you have many bundles it would be nice if you could filter certain status 
 when executing the ps command like so:
 ps active resolved -- shows active and resolved bundles
 ps -- shows all bundles (just like its currently)
 Simple solution is attached.
 btw.: there is no shell component in Felix Jira..

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

[jira] Commented: (FELIX-528) Support nested folders in fileinstall


[ 
https://issues.apache.org/jira/browse/FELIX-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588440#action_12588440
 ] 

Toni Menzel commented on FELIX-528:
---

FELIX-529 contains this one as well as some other (small) so to say 
improvements. 

 Support nested folders in fileinstall
 -

 Key: FELIX-528
 URL: https://issues.apache.org/jira/browse/FELIX-528
 Project: Felix
  Issue Type: New Feature
  Components: File Install
Reporter: Toni Menzel
Priority: Minor
 Attachments: FELIX-528.patch


 Currently FileInstall just supports flat jar-Files as bundles in its load 
 folder.
 How about supporting (nested) folders?
 This way, you could:
 1. just drop an arbitrary folder structure and fileinstall would install all 
 bundles inside.
 2. you could enable/disable entire bundle-sets with:
 2a. in/move it out of the folder
 2b. rename the folder with prefix that means unrecognized folder
 Just a thought..
 Toni

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

[jira] Commented: (FELIX-524) Support Environment variables for getting the load directory for FileInstall


[ 
https://issues.apache.org/jira/browse/FELIX-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588439#action_12588439
 ] 

Toni Menzel commented on FELIX-524:
---

FELIX-529 contains this one as well as some other (small) so to say 
improvements.


 Support Environment variables for getting the load directory for FileInstall
 

 Key: FELIX-524
 URL: https://issues.apache.org/jira/browse/FELIX-524
 Project: Felix
  Issue Type: New Feature
  Components: File Install
Reporter: Peter Kriens
 Attachments: FELIX-524.patch


 Currently, File Install only looks in the System properties for the name of 
 the the load directory. I want to use it inside Eclipse (getting tired of 
 update manager) but then it would be nice if file install could be get the 
 load directory from an environment variable. This way, when I install a new 
 Eclipse I only have to install file install and load my extra bundles from 
 one location. If it was a property, I would have to edit configuration files.
 I added this in my local aQute copy, if nobody takes up the maintenance of 
 this unit then I can do it if I get commit access

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

[jira] Created: (FELIX-534) Allow filtering by status in ps command (shell)

2008-04-12 Thread Toni Menzel (JIRA)

Allow filtering by status in ps command (shell)
---

 Key: FELIX-534
 URL: https://issues.apache.org/jira/browse/FELIX-534
 Project: Felix
  Issue Type: New Feature
Reporter: Toni Menzel
Priority: Minor


If you have many bundles it would be nice if you could filter certain status 
when executing the ps command like so:
ps active resolved -- shows active and resolved bundles
ps -- shows all bundles (just like its currently)

Simple solution is attached.

btw.: there is no shell component in Felix Jira..

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

[jira] Updated: (FELIX-528) Support nested folders in fileinstall

2008-04-07 Thread Toni Menzel (JIRA)


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

Toni Menzel updated FELIX-528:
--

Attachment: FELIX-528.patch

If you like this feature, patch is attached.
Toni

 Support nested folders in fileinstall
 -

 Key: FELIX-528
 URL: https://issues.apache.org/jira/browse/FELIX-528
 Project: Felix
  Issue Type: New Feature
  Components: File Install
Reporter: Toni Menzel
Priority: Minor
 Attachments: FELIX-528.patch


 Currently FileInstall just supports flat jar-Files as bundles in its load 
 folder.
 How about supporting (nested) folders?
 This way, you could:
 1. just drop an arbitrary folder structure and fileinstall would install all 
 bundles inside.
 2. you could enable/disable entire bundle-sets with:
 2a. in/move it out of the folder
 2b. rename the folder with prefix that means unrecognized folder
 Just a thought..
 Toni

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

[jira] Created: (FELIX-530) Separate DirectoryWatch function from action

2008-04-07 Thread Toni Menzel (JIRA)

Separate DirectoryWatch function from action


 Key: FELIX-530
 URL: https://issues.apache.org/jira/browse/FELIX-530
 Project: Felix
  Issue Type: New Feature
  Components: File Install
Reporter: Toni Menzel


I would like to pull the actions out of the DirectoryWatcher class.
Instead, this class just detect/tracks changes like it currently does and calls 
an appropriate action contributed via extender pattern.
This way, other bundles can 
1. contribute functionality like handling other stuff than final bundles and 
.cfg files.
2. replace the current behavior
3. DirectoryWatcher gets slicker / easier to maintain

The current two behaviors (install/update/remove on .jar Bundles and .cfg) 
could be installed in the activator by default (just like felix.shell does with 
its commands)

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

[jira] Created: (FELIX-528) Support nested folders in fileinstall

Support nested folders in fileinstall
-

 Key: FELIX-528
 URL: https://issues.apache.org/jira/browse/FELIX-528
 Project: Felix
  Issue Type: New Feature
  Components: File Install
Reporter: Toni Menzel
Priority: Minor


Currently FileInstall just supports flat jar-Files as bundles in its load 
folder.
How about supporting (nested) folders?
This way, you could:
1. just drop an arbitrary folder structure and fileinstall would install all 
bundles inside.
2. you could enable/disable entire bundle-sets with:
2a. in/move it out of the folder
2b. rename the folder with prefix that means unrecognized folder

Just a thought..
Toni

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

[jira] Commented: (FELIX-512) Sort files before installing


[ 
https://issues.apache.org/jira/browse/FELIX-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586151#action_12586151
 ] 

Toni Menzel commented on FELIX-512:
---

So, what's the case here now? This item can be closed with won't fix because 
of peter's explanation? Personally i'd agree him.


 Sort files before installing
 

 Key: FELIX-512
 URL: https://issues.apache.org/jira/browse/FELIX-512
 Project: Felix
  Issue Type: Improvement
  Components: File Install
Reporter: Rodrigo Madera
Priority: Minor

 Make the component sort the files  it reads before it installs them, that way 
 we can use names as in Linux's rc directories:
 100_bundle_one
 110_bundle_two
 120_bundle_three
 etc.

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

[jira] Updated: (FELIX-524) Support Environment variables for getting the load directory for FileInstall


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

Toni Menzel updated FELIX-524:
--

Attachment: FELIX-524.patch

I needed this one (with Environment variables you mean data retrieved by 
System.getenv , correct?) lately.

I've added my changes to this item.

 Support Environment variables for getting the load directory for FileInstall
 

 Key: FELIX-524
 URL: https://issues.apache.org/jira/browse/FELIX-524
 Project: Felix
  Issue Type: New Feature
  Components: File Install
Reporter: Peter Kriens
 Attachments: FELIX-524.patch


 Currently, File Install only looks in the System properties for the name of 
 the the load directory. I want to use it inside Eclipse (getting tired of 
 update manager) but then it would be nice if file install could be get the 
 load directory from an environment variable. This way, when I install a new 
 Eclipse I only have to install file install and load my extra bundles from 
 one location. If it was a property, I would have to edit configuration files.
 I added this in my local aQute copy, if nobody takes up the maintenance of 
 this unit then I can do it if I get commit access

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

[jira] Created: (FELIX-529) improve logging in FileInstall