Subject: Re: [CANCEL][VOTE] Release Felix iPOJO 1.4.2 -
msg#00014
Hi,
I cancel the release vote as some issues were found and as well as a
regression.
I will update it and re-launch a vote before the end of the weeks.
Sorry for the inconvenience.
Regards,
Clement
On 26.08.2009, at 19:25, Clement Escoffier wrote:
Hi,
We recently fix 3 critical issues affecting iPOJO 1.4.0.
- FELIX-1411 Directory manipulation does not find components on
windows
- FELIX-1497 iPOJO Web Console plugin NPE when the service reference
list is null
- FELIX-1518 iPOJO manipulator is really slow even when annotation
are ignored
There are still some outstanding issues but they will be solved in
the new version (1.6.0)
Five artifacts are released:
- the manipulator
- the Ant task
- the Maven plugin
- the online-manipulator
- the web console plugin
Staging repository:
https://repository.apache.org/content/repositories/felix-staging-036/
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 036 /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 1 week.
Thanks and regards,
Clement
Thread at a glance:
Previous Message by Date:
Re: Releasing Gogo ?
yes, I plan to get it done this evening.
Derek
2009/9/1 Guillaume Nodet <gnodet@xxxxxxxxx>:
> Sounds good. Do you plan to work on that soon ?
>
> On Tue, Sep 1, 2009 at 13:22, Derek Baum<derek.baum@xxxxxxxxxxx> wrote:
>> yep 0.2 sounds like a good idea.
>>
>> I'd like to fix:
>>
>> FELIX-1526: rename <> operators to ()
>>
>> before the 0.2 release, as this will break any existing scripts that use <>.
>>
>> Derek
>>
>>
>>
>> 2009/9/1 Guillaume Nodet <gnodet@xxxxxxxxx>:
>>> I'd like to release a first version of Gogo.
>>> However, given the RFC is bound to change and that we might introduce
>>> other changes that will break the syntax, I wonder if we should use a
>>> 0.2.0 version instead of 1.0.0.
>>> In addition, we will release the org.osgi.service.command package
>>> which is not official, so I think keeping a version < 1.0.0 makes
>>> sense until a spec is released for that.
>>> Thoughts ?
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Next Message by Date:
[jira] Commented: (FELIX-1180) Improve Karaf DefaultJDBCLock to use proper logging mechanism instead of System err prints.
[
https://issues.apache.org/jira/browse/FELIX-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749911#action_12749911
]
Jamie goodyear commented on FELIX-1180:
---------------------------------------
New direction:
No logger dependency to be added to main module.
Just write to a configurable location (such as data/log/servicemix.log <- a
possible good default value).
> Improve Karaf DefaultJDBCLock to use proper logging mechanism instead of
> System err prints.
> -------------------------------------------------------------------------------------------
>
> Key: FELIX-1180
> URL: https://issues.apache.org/jira/browse/FELIX-1180
> Project: Felix
> Issue Type: Improvement
> Components: Karaf
> Reporter: Jamie goodyear
> Assignee: Chris Custine
> Attachments: felix-1180.patch
>
>
> Currently DefaultJDBCLock is using System.err.println to log information and
> errors. This class needs to be writing this information (along with full
> stack traces whenever an exception is caught) to the servicemix.log file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Previous Message by Thread:
Karaf admin commands in a command-line script
Hi all,
Karaf has a mechanism to create new instances that can be invoked from
within the Karaf shell, something like:
admin:create my_instance
admin:list
admin:start
etc
I need to be able to do some of these things from the OS command line
so I've started on external commands (e.g. admin-create.sh) that can
perform these tasks as well (they mostly use the same code as used by
the karaf shell).
I was wondering would the Felix/Karaf community be interested in
these? If so I'll start creating some Jiras and attach patches...
Best regards,
David Bosschaert
Next Message by Thread:
[jira] Commented: (FELIX-1180) Improve Karaf DefaultJDBCLock to use proper logging mechanism instead of System err prints.
[
https://issues.apache.org/jira/browse/FELIX-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749911#action_12749911
]
Jamie goodyear commented on FELIX-1180:
---------------------------------------
New direction:
No logger dependency to be added to main module.
Just write to a configurable location (such as data/log/servicemix.log <- a
possible good default value).
> Improve Karaf DefaultJDBCLock to use proper logging mechanism instead of
> System err prints.
> -------------------------------------------------------------------------------------------
>
> Key: FELIX-1180
> URL: https://issues.apache.org/jira/browse/FELIX-1180
> Project: Felix
> Issue Type: Improvement
> Components: Karaf
> Reporter: Jamie goodyear
> Assignee: Chris Custine
> Attachments: felix-1180.patch
>
>
> Currently DefaultJDBCLock is using System.err.println to log information and
> errors. This class needs to be writing this information (along with full
> stack traces whenever an exception is caught) to the servicemix.log file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.