Re: [VOTE] Apache Karaf 4.2.0.M1 release

2017-11-03 Thread Jon Anstey 
+1

On Sat, Oct 28, 2017 at 4:01 AM, Jean-Baptiste Onofré 
wrote:

> Hi all
>
> I submit Karaf 4.2.0.M1 release to your vote. It's not a GA release but a
> technical preview. The purpose is to perform a test campaign before the
> first GA Release.
> Especially the Java9 support is not yet complete as we need new
> dependencies releases.
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12311140=12338362
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1101/
>
> Git tag:
> karaf-4.2.0.M1
>
> Please vote for this release:
>
> [ ] +1 (approve the release)
> [ ] -1 (don't approve the release, provide reason)
>
> This vote is open for 72h.
>
> Thanks
> Regards
> JB
> ⁣​




-- 
Cheers,
Jon
---
Red Hat, Inc.
Email: jans...@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Camel in Action:
https://www.manning.com/books/camel-in-action-second-edition

Re: [VOTE] Release Apache Karaf 2.4.0

2014-09-17 Thread Jon Anstey 
Thanks Jamie! Kit looks good to me.

+1

On Wed, Sep 17, 2014 at 1:13 PM, Jamie G. jamie.goody...@gmail.com wrote:

 Hi,

 We resolved 441 issues in this release:

 http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.4.0-release.page?view=markup

 A Dependencies table will be created to track changes on the 2.4.x series.

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachekaraf-1011/

 Git tag:
 karaf-2.4.0

 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.




-- 
Cheers,
Jon
---
Red Hat, Inc.
Email: jans...@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen

Re: [VOTE] Release Apache Karaf 2.3.7

2014-09-04 Thread Jon Anstey 
+1 looks good to me.


On Tue, Sep 2, 2014 at 10:17 PM, Jamie G. jamie.goody...@gmail.com wrote:

 Hi,

 We resolved 15 issues in this release:

 http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.3.7-release.page?view=markup

 Dependency changes can be reviewed here:

 http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-2.3.x.page?revision=1613719view=markup

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachekaraf-1009/

 Git tag:
 karaf-2.3.7

 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.




-- 
Cheers,
Jon
---
Red Hat, Inc.
Email: jans...@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen

Re: [3/5] git commit: KARAF-3029 - Support encryption of Maven repo passwords

2014-06-17 Thread Jon Anstey 
Didn't mean to commit this and a few others yet. It tagged along with
another commit... I'll revert it ASAP :-)


On Tue, Jun 17, 2014 at 12:10 PM, jans...@apache.org wrote:

 KARAF-3029 - Support encryption of Maven repo passwords


 Project: http://git-wip-us.apache.org/repos/asf/karaf/repo
 Commit: http://git-wip-us.apache.org/repos/asf/karaf/commit/5bc5bf35
 Tree: http://git-wip-us.apache.org/repos/asf/karaf/tree/5bc5bf35
 Diff: http://git-wip-us.apache.org/repos/asf/karaf/diff/5bc5bf35

 Branch: refs/heads/karaf-2.x
 Commit: 5bc5bf35ff086e8ffd2ba84783319f8e8719d1aa
 Parents: 353bca3
 Author: Jonathan Anstey jans...@gmail.com
 Authored: Tue Jun 10 11:55:24 2014 -0230
 Committer: Jonathan Anstey jans...@gmail.com
 Committed: Tue Jun 17 11:01:57 2014 -0230

 --
  assemblies/apache-karaf/pom.xml |  2 +-
  .../src/main/descriptors/unix-bin-release.xml   | 33 ++-
  .../src/main/descriptors/unix-bin-snapshot.xml  | 44 +++-
  .../descriptors/unix-minimal-bin-release.xml| 44 +++-
  .../descriptors/unix-minimal-bin-snapshot.xml   | 44 +++-
  .../main/descriptors/windows-bin-release.xml| 44 +++-
  .../main/descriptors/windows-bin-snapshot.xml   | 44 +++-
  .../descriptors/windows-minimal-bin-release.xml | 44 +++-
  .../windows-minimal-bin-snapshot.xml| 44 +++-
  .../release/etc/org.ops4j.pax.url.mvn.cfg   |  2 +-
  .../snapshot/etc/org.ops4j.pax.url.mvn.cfg  |  2 +-
  .../filtered-resources/etc/startup.properties   | 13 +-
  .../minimal/startup.properties  |  3 +-
  .../standard/src/main/resources/features.xml|  2 +-
  etc/appended-resources/supplemental-models.xml  |  4 +-
  .../org/apache/karaf/main/MainStartTest.java|  2 +-
  pom.xml | 16 +--
  tooling/features-maven-plugin/pom.xml   |  2 +-
  18 files changed, 368 insertions(+), 21 deletions(-)
 --



 http://git-wip-us.apache.org/repos/asf/karaf/blob/5bc5bf35/assemblies/apache-karaf/pom.xml
 --
 diff --git a/assemblies/apache-karaf/pom.xml
 b/assemblies/apache-karaf/pom.xml
 index dbb4250..c287222 100644
 --- a/assemblies/apache-karaf/pom.xml
 +++ b/assemblies/apache-karaf/pom.xml
 @@ -277,7 +277,7 @@
  /dependency
  dependency
  groupIdorg.ops4j.pax.url/groupId
 -artifactIdpax-url-mvn/artifactId
 +artifactIdpax-url-aether/artifactId
  /dependency
  dependency
  groupIdorg.ops4j.pax.url/groupId


 http://git-wip-us.apache.org/repos/asf/karaf/blob/5bc5bf35/assemblies/apache-karaf/src/main/descriptors/unix-bin-release.xml
 --
 diff --git
 a/assemblies/apache-karaf/src/main/descriptors/unix-bin-release.xml
 b/assemblies/apache-karaf/src/main/descriptors/unix-bin-release.xml
 index 1c4657c..52a4475 100644
 --- a/assemblies/apache-karaf/src/main/descriptors/unix-bin-release.xml
 +++ b/assemblies/apache-karaf/src/main/descriptors/unix-bin-release.xml
 @@ -160,8 +160,39 @@

  
 org/ops4j/pax/url/${artifact.artifactId}/${artifact.baseVersion}/${artifact.artifactId}-${artifact.baseVersion}${dashClassifier?}.${artifact.extension}
  /outputFileNameMapping
  includes
 -includeorg.ops4j.pax.url:pax-url-mvn/include
 +includeorg.ops4j.pax.url:pax-url-aether/include
  includeorg.ops4j.pax.url:pax-url-wrap/include
 +includeorg.ops4j.pax.url:pax-url-commons/include
 +includeorg.ops4j.pax.url:pax-url-maven-commons/include
 +/includes
 +/dependencySet
 +dependencySet
 +outputDirectory/system/outputDirectory
 +unpackfalse/unpack
 +useProjectArtifactfalse/useProjectArtifact
 +outputFileNameMapping
 +
  
 org/ops4j/pax/swissbox/${artifact.artifactId}/${artifact.baseVersion}/${artifact.artifactId}-${artifact.baseVersion}${dashClassifier?}.${artifact.extension}
 +/outputFileNameMapping
 +includes
 +includeorg.ops4j.pax.swissbox:pax-swissbox-bnd/include
 +
  includeorg.ops4j.pax.swissbox:pax-swissbox-property/include
 +/includes
 +/dependencySet
 +dependencySet
 +outputDirectory/system/outputDirectory
 +unpackfalse/unpack
 +useProjectArtifactfalse/useProjectArtifact
 +outputFileNameMapping
 +
  
 org/ops4j/base/${artifact.artifactId}/${artifact.baseVersion}/${artifact.artifactId}-${artifact.baseVersion}${dashClassifier?}.${artifact.extension}
 +/outputFileNameMapping
 +includes

Re: [VOTE] Release Apache Karaf 2.3.5

2014-04-11 Thread Jon Anstey 
+1 (non binding)

Re: [VOTE] Release Apache Karaf 3.0.1

2014-04-11 Thread Jon Anstey 
+1 looks good to me.


On Thu, Apr 10, 2014 at 7:27 PM, Jamie G. jamie.goody...@gmail.com wrote:

 Hi,

 We resolved 145 issues in this release:

 http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.1-release.page?view=markup

 Dependency changes can be reviewed here:

 http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
  (The website published table will be updated after vote)

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachekaraf-1005/

 Git tag:
 karaf-3.0.1

 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.




-- 
Cheers,
Jon
---
Red Hat, Inc.
Email: jans...@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen

Re: [VOTE] Release Apache Karaf version 2.3.4

2014-02-16 Thread Jon Anstey 
+1 (non binding)
On Feb 14, 2014 10:39 PM, Jamie G. jamie.goody...@gmail.com wrote:

 Hi,

 We resolved 116 issues in this release (web page will be published post RC
 promotion):

 https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.3.4-release.page

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachekaraf-1000/

 Repository: karaf
 Updated Tags:  refs/tags/karaf-2.3.4 [created] 653d885f4

 2.3.x Dependencies table:

 https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-
 2.3.x.page

 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.

Re: git commit: [KARAF-2753] Logging for override mechanism. Added additional logging and unit test to trigger log events

2014-02-12 Thread Jon Anstey 
No need to revert this completely IMO. The wording is too strong though. I
know of many companies (can't say names here) that have rebranded
customized versions of Karaf that would not be able to ship with a message
like that in the logs. Or they would just not be able to use this feature.
Looks really bad if your product always spits out that it may have
malicious code even if you know you put it there :-)


On Wed, Feb 12, 2014 at 1:05 PM, Jamie G. jamie.goody...@gmail.com wrote:

 Changing vendors to me would be something i'd like to be warned about. I
 have Apache Camel installed, with XYZ under the hood - lets me know its a
 franken-build. That being said, if i was going to fork and build my own
 camel jar to fix a local issue, why would i then need to use the override,
 i'd just deploy the library, refresh, and carry on (different work flows
 for different folks - I do get that that's simplifying things - generally
 we'd end up with a large list of bundles needing changing and the override
 would simplify managing that recipe update).

 Regardless, I'm open to amending how vendors are handled, if we want to
 change the message or scrap it all together. Personally i think something
 should be noted since things are changing (i'd like to know I'm going from
 Land Rover parts to something made by Ford in my Range Rover).

 As to a global on/off switch for the mechanism that would be a nice
 addition.

 --Jamie


 On Wed, Feb 12, 2014 at 12:23 PM, Guillaume Nodet gno...@apache.org
 wrote:

  I just think the check is worth nothing.   If someone build a customized
  version of a bundle (let's say camel), he will usually build by forking
  from camel, in which case the vendor would still be the same.  And if the
  user wants to make things cleaner and actually change the vendor to
 reflect
  the fact that it does not come from Apache, then we throw at him a
 WARNING
  log.
  Again, I don't think we should assume the user does not know what he
 does,
  I'd rather add a global flag to disable overrides if you think it's
 safer,
  but the file does not even exist by default, which means the user
 actually
  know what he is doing...
 
 
  2014-02-12 16:42 GMT+01:00 Jamie G. jamie.goody...@gmail.com:
 
   My interpretation is that a bundle is being updated by its maintainer,
  if a
   different group is providing the replacement bundle then Karaf should
 be
   making some noise about it as its masquerading as being what was
  originally
   intended by the feature provider. I'm up for different wordings
 however.
   What would you suggest?
  
  
   On Wed, Feb 12, 2014 at 12:07 PM, Guillaume Nodet gno...@apache.org
   wrote:
  
Yes, I was going to add that I had no problems saying a bundle has
 been
overridden (though not sure if it has to be with a WARNING level).
It's really the vendor check which I don't get and the log of
  Malicious
code possibly introduced by patch override, see log for details.
   
   
2014-02-12 16:30 GMT+01:00 Achim Nierbeck bcanh...@googlemail.com:
   
 Well, I hope you didn't get distracted by my comment.
 Though as far as I can see the change only introduced some logging
 to let the user know something changed due to adding another
 feature,
 I think this is a viable solution, especially when looking for
  failures
 or unintended changes.
 No?


 2014-02-12 16:15 GMT+01:00 Guillaume Nodet gno...@apache.org:

  I'm tempted to -1 this change.
 
  What kind of problems are you trying to solve here ?
  Imho, such code is unnecessary because there are many other ways
 to
  introduce so called malicious code.
  If one wants to be safe, there is already an existing way to
 solve
   the
  problem which is signed bundles.
 
  Now, an example on how to introduce malicious code : if such a
   bundle
 is
  installed first, the features service will think the correct
  bundle
is
  already installed and will not install the safe bundle.  This
 can
   be
 done
  by manually installing the bundle before installing features, or
 by
 adding
  it to the etc/startup.properties.
  Another option is just to hack the features file manually and
  change
the
  url of the bundle, it will have exactly the same effect.
 
  In addition, checking the vendor is not a guarantee, as if
 someone
wanted
  to fake a bundle, setting that header is not more difficult
 than
 changing
  the symbolic name or version.
 
  I've had a use case where the user wanted to make sure that no
 malicious
  code is introduced or used.  In such a case, there is already an
existing
  solution which is fully supported by OSGi (and Karaf) which is
  signed
  bundles.  It works well and it's secured.  Well, secured to the
  point
 that
  you control the file system.  In all cases, if you don't trust
 the
   file
  system, there's no

Re: git commit: [KARAF-2753] Logging for override mechanism. Added additional logging and unit test to trigger log events

2014-02-12 Thread Jon Anstey 
How about WARNING: Bundle Vendor for X has changed, please check if this
is intentional. where X is the bundle name?


On Wed, Feb 12, 2014 at 3:39 PM, Jon Anstey jans...@gmail.com wrote:

 Yeah, I get that it only pops up when the vendor changes. I was just
 concerned about the malicious code implication as that would cause alarm
 to admins in most deployments.

 BTW its not a problem in the custom Karaf distro that I work on ;-) but I
 know of other Karaf users that may have this problem...


 On Wed, Feb 12, 2014 at 3:14 PM, Jamie G. jamie.goody...@gmail.comwrote:

 To be fare that only happens when vendors switch. Perhaps WARNING: Bundle
 Vendor has changed, please review your feature, unexpected behaviours may
 occur. Using the car part analogy if my BMW's alternator belt was
 replaced
 with a FIAT part then I'd expect to be told by the mechanic - I have an
 expected behaviour from the brand. Note, this does not prevent the
 installation and use of the part, it just makes sure the user is aware of
 the switch.

 --Jamie


 On Wed, Feb 12, 2014 at 2:20 PM, Jon Anstey jans...@gmail.com wrote:

  No need to revert this completely IMO. The wording is too strong
 though. I
  know of many companies (can't say names here) that have rebranded
  customized versions of Karaf that would not be able to ship with a
 message
  like that in the logs. Or they would just not be able to use this
 feature.
  Looks really bad if your product always spits out that it may have
  malicious code even if you know you put it there :-)
 
 
  On Wed, Feb 12, 2014 at 1:05 PM, Jamie G. jamie.goody...@gmail.com
  wrote:
 
   Changing vendors to me would be something i'd like to be warned
 about. I
   have Apache Camel installed, with XYZ under the hood - lets me know
 its a
   franken-build. That being said, if i was going to fork and build my
 own
   camel jar to fix a local issue, why would i then need to use the
  override,
   i'd just deploy the library, refresh, and carry on (different work
 flows
   for different folks - I do get that that's simplifying things -
 generally
   we'd end up with a large list of bundles needing changing and the
  override
   would simplify managing that recipe update).
  
   Regardless, I'm open to amending how vendors are handled, if we want
 to
   change the message or scrap it all together. Personally i think
 something
   should be noted since things are changing (i'd like to know I'm going
  from
   Land Rover parts to something made by Ford in my Range Rover).
  
   As to a global on/off switch for the mechanism that would be a nice
   addition.
  
   --Jamie
  
  
   On Wed, Feb 12, 2014 at 12:23 PM, Guillaume Nodet gno...@apache.org
   wrote:
  
I just think the check is worth nothing.   If someone build a
  customized
version of a bundle (let's say camel), he will usually build by
 forking
from camel, in which case the vendor would still be the same.  And
 if
  the
user wants to make things cleaner and actually change the vendor to
   reflect
the fact that it does not come from Apache, then we throw at him a
   WARNING
log.
Again, I don't think we should assume the user does not know what he
   does,
I'd rather add a global flag to disable overrides if you think it's
   safer,
but the file does not even exist by default, which means the user
   actually
know what he is doing...
   
   
2014-02-12 16:42 GMT+01:00 Jamie G. jamie.goody...@gmail.com:
   
 My interpretation is that a bundle is being updated by its
  maintainer,
if a
 different group is providing the replacement bundle then Karaf
 should
   be
 making some noise about it as its masquerading as being what was
originally
 intended by the feature provider. I'm up for different wordings
   however.
 What would you suggest?


 On Wed, Feb 12, 2014 at 12:07 PM, Guillaume Nodet 
 gno...@apache.org
  
 wrote:

  Yes, I was going to add that I had no problems saying a bundle
 has
   been
  overridden (though not sure if it has to be with a WARNING
 level).
  It's really the vendor check which I don't get and the log of
Malicious
  code possibly introduced by patch override, see log for
 details.
 
 
  2014-02-12 16:30 GMT+01:00 Achim Nierbeck 
 bcanh...@googlemail.com
  :
 
   Well, I hope you didn't get distracted by my comment.
   Though as far as I can see the change only introduced some
  logging
   to let the user know something changed due to adding another
   feature,
   I think this is a viable solution, especially when looking for
failures
   or unintended changes.
   No?
  
  
   2014-02-12 16:15 GMT+01:00 Guillaume Nodet gno...@apache.org
 :
  
I'm tempted to -1 this change.
   
What kind of problems are you trying to solve here ?
Imho, such code is unnecessary because there are many other
  ways
   to
introduce so

Re: git commit: [KARAF-2753] Logging for override mechanism. Added additional logging and unit test to trigger log events

2014-02-12 Thread Jon Anstey 
Awesome. Thanks!


On Wed, Feb 12, 2014 at 3:46 PM, Jamie G. jamie.goody...@gmail.com wrote:

 That would be acceptable to me - gives users a head's up that something
 more than a simple minor bump has occurred, and spurs them to action.

 --Jamie


 On Wed, Feb 12, 2014 at 3:44 PM, Jon Anstey jans...@gmail.com wrote:

  How about WARNING: Bundle Vendor for X has changed, please check if this
  is intentional. where X is the bundle name?
 
 
  On Wed, Feb 12, 2014 at 3:39 PM, Jon Anstey jans...@gmail.com wrote:
 
   Yeah, I get that it only pops up when the vendor changes. I was just
   concerned about the malicious code implication as that would cause
  alarm
   to admins in most deployments.
  
   BTW its not a problem in the custom Karaf distro that I work on ;-)
 but I
   know of other Karaf users that may have this problem...
  
  
   On Wed, Feb 12, 2014 at 3:14 PM, Jamie G. jamie.goody...@gmail.com
  wrote:
  
   To be fare that only happens when vendors switch. Perhaps WARNING:
  Bundle
   Vendor has changed, please review your feature, unexpected behaviours
  may
   occur. Using the car part analogy if my BMW's alternator belt was
   replaced
   with a FIAT part then I'd expect to be told by the mechanic - I have
 an
   expected behaviour from the brand. Note, this does not prevent the
   installation and use of the part, it just makes sure the user is aware
  of
   the switch.
  
   --Jamie
  
  
   On Wed, Feb 12, 2014 at 2:20 PM, Jon Anstey jans...@gmail.com
 wrote:
  
No need to revert this completely IMO. The wording is too strong
   though. I
know of many companies (can't say names here) that have rebranded
customized versions of Karaf that would not be able to ship with a
   message
like that in the logs. Or they would just not be able to use this
   feature.
Looks really bad if your product always spits out that it may have
malicious code even if you know you put it there :-)
   
   
On Wed, Feb 12, 2014 at 1:05 PM, Jamie G. jamie.goody...@gmail.com
 
wrote:
   
 Changing vendors to me would be something i'd like to be warned
   about. I
 have Apache Camel installed, with XYZ under the hood - lets me
 know
   its a
 franken-build. That being said, if i was going to fork and build
 my
   own
 camel jar to fix a local issue, why would i then need to use the
override,
 i'd just deploy the library, refresh, and carry on (different work
   flows
 for different folks - I do get that that's simplifying things -
   generally
 we'd end up with a large list of bundles needing changing and the
override
 would simplify managing that recipe update).

 Regardless, I'm open to amending how vendors are handled, if we
 want
   to
 change the message or scrap it all together. Personally i think
   something
 should be noted since things are changing (i'd like to know I'm
  going
from
 Land Rover parts to something made by Ford in my Range Rover).

 As to a global on/off switch for the mechanism that would be a
 nice
 addition.

 --Jamie


 On Wed, Feb 12, 2014 at 12:23 PM, Guillaume Nodet 
  gno...@apache.org
 wrote:

  I just think the check is worth nothing.   If someone build a
customized
  version of a bundle (let's say camel), he will usually build by
   forking
  from camel, in which case the vendor would still be the same.
  And
   if
the
  user wants to make things cleaner and actually change the vendor
  to
 reflect
  the fact that it does not come from Apache, then we throw at
 him a
 WARNING
  log.
  Again, I don't think we should assume the user does not know
 what
  he
 does,
  I'd rather add a global flag to disable overrides if you think
  it's
 safer,
  but the file does not even exist by default, which means the
 user
 actually
  know what he is doing...
 
 
  2014-02-12 16:42 GMT+01:00 Jamie G. jamie.goody...@gmail.com:
 
   My interpretation is that a bundle is being updated by its
maintainer,
  if a
   different group is providing the replacement bundle then Karaf
   should
 be
   making some noise about it as its masquerading as being what
 was
  originally
   intended by the feature provider. I'm up for different
 wordings
 however.
   What would you suggest?
  
  
   On Wed, Feb 12, 2014 at 12:07 PM, Guillaume Nodet 
   gno...@apache.org

   wrote:
  
Yes, I was going to add that I had no problems saying a
 bundle
   has
 been
overridden (though not sure if it has to be with a WARNING
   level).
It's really the vendor check which I don't get and the log
 of
  Malicious
code possibly introduced by patch override, see log for
   details.
   
   
2014-02-12 16:30 GMT+01:00 Achim Nierbeck 
   bcanh...@googlemail.com
:
   
 Well, I hope

Re: git commit: KARAF-2727 - fix script for Solaris

2014-01-23 Thread Jon Anstey 
This also works on Solaris:

JAVA_HOME=$(/usr/libexec/java_home)

So I'm going with this change instead.


On Thu, Jan 23, 2014 at 12:26 PM, Achim Nierbeck bcanh...@googlemail.comwrote:

 Hmm, are you sure about that fix?
 cause for darwin (mac-os) we need this behaviour
 I suggest to add an extra part for solaris


 2014/1/23 jans...@apache.org

  Updated Branches:
refs/heads/karaf-2.x 38a78b272 - 6f68f11dc
 
 
  KARAF-2727 - fix script for Solaris
 
 
  Project: http://git-wip-us.apache.org/repos/asf/karaf/repo
  Commit: http://git-wip-us.apache.org/repos/asf/karaf/commit/6f68f11d
  Tree: http://git-wip-us.apache.org/repos/asf/karaf/tree/6f68f11d
  Diff: http://git-wip-us.apache.org/repos/asf/karaf/diff/6f68f11d
 
  Branch: refs/heads/karaf-2.x
  Commit: 6f68f11dc851fab2923276b841ebdda8927b58c4
  Parents: 38a78b2
  Author: Jonathan Anstey jans...@gmail.com
  Authored: Thu Jan 23 12:22:10 2014 -0330
  Committer: Jonathan Anstey jans...@gmail.com
  Committed: Thu Jan 23 12:24:46 2014 -0330
 
  --
   assemblies/apache-karaf/src/main/distribution/unix-shell/bin/karaf | 2
 +-
   assemblies/apache-karaf/src/main/filtered-resources/bin/admin  | 2
 +-
   assemblies/apache-karaf/src/main/filtered-resources/bin/client | 2
 +-
   assemblies/apache-karaf/src/main/filtered-resources/bin/shell  | 2
 +-
   4 files changed, 4 insertions(+), 4 deletions(-)
  --
 
 
 
 
 http://git-wip-us.apache.org/repos/asf/karaf/blob/6f68f11d/assemblies/apache-karaf/src/main/distribution/unix-shell/bin/karaf
  --
  diff --git
  a/assemblies/apache-karaf/src/main/distribution/unix-shell/bin/karaf
  b/assemblies/apache-karaf/src/main/distribution/unix-shell/bin/karaf
  index 8c1eb39..c9beb95 100755
  --- a/assemblies/apache-karaf/src/main/distribution/unix-shell/bin/karaf
  +++ b/assemblies/apache-karaf/src/main/distribution/unix-shell/bin/karaf
  @@ -195,7 +195,7 @@ locateJava() {
   fi
 
  if [ x$JAVA_HOME = x ]  [ $darwin = true ]; then
  -   JAVA_HOME=$(/usr/libexec/java_home)
  +   JAVA_HOME=`/usr/libexec/java_home`
  fi
   if [ x$JAVA = x ]  [ -r /etc/gentoo-release ] ; then
   JAVA_HOME=`java-config --jre-home`
 
 
 
 http://git-wip-us.apache.org/repos/asf/karaf/blob/6f68f11d/assemblies/apache-karaf/src/main/filtered-resources/bin/admin
  --
  diff --git
 a/assemblies/apache-karaf/src/main/filtered-resources/bin/admin
  b/assemblies/apache-karaf/src/main/filtered-resources/bin/admin
  index a866338..7f6c807 100644
  --- a/assemblies/apache-karaf/src/main/filtered-resources/bin/admin
  +++ b/assemblies/apache-karaf/src/main/filtered-resources/bin/admin
  @@ -188,7 +188,7 @@ locateJava() {
   fi
 
   if [ x$JAVA_HOME = x ]  [ $darwin = true ]; then
  -JAVA_HOME=$(/usr/libexec/java_home)
  +JAVA_HOME=`/usr/libexec/java_home`
   fi
   if [ x$JAVA = x ]  [ -r /etc/gentoo-release ] ; then
   JAVA_HOME=`java-config --jre-home`
 
 
 
 http://git-wip-us.apache.org/repos/asf/karaf/blob/6f68f11d/assemblies/apache-karaf/src/main/filtered-resources/bin/client
  --
  diff --git
  a/assemblies/apache-karaf/src/main/filtered-resources/bin/client
  b/assemblies/apache-karaf/src/main/filtered-resources/bin/client
  index 8fa5497..ba369d3 100644
  --- a/assemblies/apache-karaf/src/main/filtered-resources/bin/client
  +++ b/assemblies/apache-karaf/src/main/filtered-resources/bin/client
  @@ -188,7 +188,7 @@ locateJava() {
   fi
 
   if [ x$JAVA_HOME = x ]  [ $darwin = true ]; then
  -JAVA_HOME=$(/usr/libexec/java_home)
  +JAVA_HOME=`/usr/libexec/java_home`
   fi
   if [ x$JAVA = x ]  [ -r /etc/gentoo-release ] ; then
   JAVA_HOME=`java-config --jre-home`
 
 
 
 http://git-wip-us.apache.org/repos/asf/karaf/blob/6f68f11d/assemblies/apache-karaf/src/main/filtered-resources/bin/shell
  --
  diff --git
 a/assemblies/apache-karaf/src/main/filtered-resources/bin/shell
  b/assemblies/apache-karaf/src/main/filtered-resources/bin/shell
  index 0df1d8f..a93121e 100644
  --- a/assemblies/apache-karaf/src/main/filtered-resources/bin/shell
  +++ b/assemblies/apache-karaf/src/main/filtered-resources/bin/shell
  @@ -187,7 +187,7 @@ locateJava() {
   fi
 
   if [ x$JAVA_HOME = x ]  [ $darwin = true ]; then
  -JAVA_HOME=$(/usr/libexec/java_home)
  +JAVA_HOME=`/usr/libexec/java_home`
   fi
   if [ x$JAVA = x ]  [ -r /etc/gentoo-release ] ; then
   JAVA_HOME=`java-config --jre-home`
 
 


 --

 Apache Karaf http://karaf.apache.org/ Committer  PMC
 OPS4J Pax Web

Re: [VOTE] Release Apache Karaf version 3.0.0

2013-12-21 Thread Jon Anstey 
+1 non binding. Will be nice to see this one go out :-) Great job guys!
On Dec 21, 2013 2:11 PM, Jamie G. jamie.goody...@gmail.com wrote:

 Hi,

 We resolved 1158 issues in this release:

 http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup

 Dependency changes can be reviewed here:

 http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
 (The website published table will be updated after vote)

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachekaraf-013/

 Git tag:
 karaf-3.0.0

 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.

Re: Board Report for December, 2013

2013-11-22 Thread Jon Anstey 
Looks good JB. +1


On Fri, Nov 22, 2013 at 9:28 AM, Jean-Baptiste Onofré j...@nanthrax.netwrote:

 Hi all,

 I prepared the Board Report for December, 2013:

 https://cwiki.apache.org/confluence/display/KARAF/Board+Reports

 Please review it.

 I will update the report with the latest numbers end of November.

 Thanks,
 Regards
 JB
 --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com




-- 
Cheers,
Jon
---
Red Hat, Inc.
Email: jans...@redhat.com
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen

fw: hello

2013-07-21 Thread Jon Anstey 
 http://personeelsservice-kwb.nl/tcxfv/hniyxuwxstblt














 janstey















 7/21/2013 5:52:25 PM

Re: fw: hello

2013-07-21 Thread Jon Anstey 
Please don't click this link. Some hacker in Belarus hijacked my account
today and sent this out.

Cheers,
Jon
On 2013-07-21 2:23 PM, Jon Anstey jans...@gmail.com wrote:

  http://personeelsservice-kwb.nl/tcxfv/hniyxuwxstblt














  janstey















  7/21/2013 5:52:25 PM

Re: [VOTE] Release Apache Karaf 2.2.6 RC#4

2012-04-05 Thread Jon Anstey 
Just built the src distro
https://repository.apache.org/content/repositories/orgapachekaraf-008/org/apache/karaf/apache-karaf/2.2.6/apache-karaf-2.2.6-src.tar.gzand
all looks well. Fourth time's the charm? :)

+1 (non-binding)

On Thu, Apr 5, 2012 at 10:03 AM, Jamie G. jamie.goody...@gmail.com wrote:

 Hi,

 We resolved 78 issues in this release (web page will be published post
 RC promotion):

 https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.2.6-release.page

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachekaraf-008/

 Release tags:
 https://svn.apache.org/repos/asf/karaf/tags/karaf-2.2.6/

 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.




-- 
Cheers,
Jon
---
FuseSource
Email: j...@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen

Re: [VOTE] Release Apache Karaf 2.2.6 - RC#3

2012-04-04 Thread Jon Anstey 
Hey guys,

I just tried this out on Ubuntu 64bit and looks good. Also tried out the
shiny new service wrapper on Win 2008 64bit and also looks good - nice
work! :) Here's my +1 FWIW

Cheers,
Jon

On Wed, Apr 4, 2012 at 1:19 PM, Jamie G. jamie.goody...@gmail.com wrote:

 Hi,

 We resolved 76 issues in this release (web page will be published post
 RC promotion):

 https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.2.6-release.page

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

 Release tags:
 https://svn.apache.org/repos/asf/karaf/tags/karaf-2.2.6/

 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.




-- 
Cheers,
Jon
---
FuseSource
Email: j...@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen

Re: ServiceMix in Action

2010-08-15 Thread Jon Anstey 
Yay! Go Charles! :)

On Fri, Aug 13, 2010 at 4:47 AM, Charles Moulliard cmoulli...@gmail.comwrote:

 Hi,

 I have been contacted by Manning to discuss the opportunity to write a book
 about ServiceMix in Action. Following the discussions that we have had
 together, the general feeling is that a book is necessary Why :
 1) Documentation on Apache Web Site is obsolete, not up to date,
 2) ServiceMix4 gains more attention from architect, developers and Java
 community in general,
 3) This book can contribute to success of architecture designed around
 modularity and including Enterprise features,
 5) Publication of a ServiceMix book + Aries book (in discussion too) will
 be
 a perfect match to present in more detail Servicemix, Karaf,
 high-availability, management, security, deployment, design of solution
 with
 Camel/CXF, jbi, blueprint, transaction ... Those two books will represent
 the bricks for the architect in charge to design enterprise solutions for
 OSGI world !

 Remark :
 1) To avoid confusion with the books in preparation, I have proposed to
 change the name of the book of Alexandre de Castro Alves (
 http://www.manning.com/alves/) which is not at all oriented to OSGI
 Enterprise and to review the scope for the incoming book Aries in action
 which is from my point of view more oriented to solve Enterprise issues and
 because Aries implements OSGI EE.
 2) I plan to write the proposal in the coming next days/weeks (if I find
 time between my missions !)

 If people are interested to write with me the book, please let me know ?
 They will help me to correct my bad/poor English ;-)

 Kind regards,

 Charles Moulliard

 Senior Enterprise Architect (J2EE, .NET, SOA)
 Apache Camel - Karaf - ServiceMix Committer
 ~~~
 Blog : http://cmoulliard.blogspot.com |  Twitter :
 http://twitter.com/cmoulliard
 Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: cmoulliard




-- 
Cheers,
Jon

Camel in Action: http://manning.com/ibsen
Open Source Integration: http://fusesource.com
Blog: http://janstey.blogspot.com