This list is closed, nobody may subscribe to it.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
|
Oct
(61) |
Nov
(88) |
Dec
(27) |
| 2010 |
Jan
(55) |
Feb
(93) |
Mar
(133) |
Apr
(148) |
May
(92) |
Jun
(56) |
Jul
(110) |
Aug
(28) |
Sep
(229) |
Oct
(93) |
Nov
(137) |
Dec
(91) |
| 2011 |
Jan
(62) |
Feb
(207) |
Mar
(157) |
Apr
(59) |
May
(122) |
Jun
(56) |
Jul
(105) |
Aug
(154) |
Sep
(64) |
Oct
(232) |
Nov
(224) |
Dec
(60) |
| 2012 |
Jan
(93) |
Feb
(251) |
Mar
(571) |
Apr
(205) |
May
(82) |
Jun
(48) |
Jul
(49) |
Aug
(34) |
Sep
(69) |
Oct
(22) |
Nov
(85) |
Dec
(41) |
| 2013 |
Jan
(30) |
Feb
(50) |
Mar
(66) |
Apr
(37) |
May
(11) |
Jun
(36) |
Jul
(40) |
Aug
(20) |
Sep
(9) |
Oct
(9) |
Nov
(28) |
Dec
(38) |
| 2014 |
Jan
(19) |
Feb
(20) |
Mar
(11) |
Apr
(5) |
May
(16) |
Jun
(26) |
Jul
(50) |
Aug
(60) |
Sep
(75) |
Oct
(49) |
Nov
(37) |
Dec
(9) |
| 2015 |
Jan
(20) |
Feb
(51) |
Mar
(72) |
Apr
(33) |
May
(22) |
Jun
(35) |
Jul
(38) |
Aug
(47) |
Sep
(48) |
Oct
(21) |
Nov
(47) |
Dec
(31) |
| 2016 |
Jan
(57) |
Feb
(42) |
Mar
(23) |
Apr
(21) |
May
(27) |
Jun
(9) |
Jul
(10) |
Aug
(43) |
Sep
(69) |
Oct
(30) |
Nov
(27) |
Dec
(34) |
| 2017 |
Jan
(34) |
Feb
(38) |
Mar
(35) |
Apr
(35) |
May
(40) |
Jun
(10) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <je...@sa...> - 2017-05-04 04:41:53
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2105/> |
|
From: Stefan R. <sro...@ar...> - 2017-05-03 12:35:28
|
@Nullable only works with MethodInjection. I do not know if this is a
design choice or simply a bug in the PicoContainer Framework that
@Nullable do not work with other Injection types.
But you can just move the NullProxyResolver from Saros/I to the Core and
then use it in Saros/I and Saros/S.
On 02.05.2017 08:12, Michael Krummrei wrote:
>
> Hello,
>
>
> i recently discovered (with Franz' help :) ) a bug regarding the usage
> of Picocontainers and the @nullable-Annotation.
>
>
> ---- what happened: -----
>
> The ConnectionHandler depends optionally on IProxyResolver. The
> parameter is annotated with "@nullable", so, while getting the
> component, it should be ok if no proxyresolver is provided. (see the
> following code)
>
>
> public ConnectionHandler(final XMPPConnectionService connectionService,
> final TCPServer tcpServer, final MDNSService mDNSService,
> final IConnectionManager transferManager,
> @Nullable final IProxyResolver proxyResolver,
> final Preferences preferences) {
>
>
> ...................
>
>
> The problem is, without a ProxyResolver getComponents() throws an
> UnsatisfiableDepency-Exception, so the nullable-annotation does NOT
> seem to behave as specified. As a Hotfix i added a second Constructor
> to ConnectionHandler without the proxyResolver-Parameter, since
> according to the picocontainer-documentation getComponents() returns
> the fitting constructor with the least amount of parameters. The fix
> worked and getComponents() did not threw an
> UnsatisfiableDepency-Exception anymore.
>
> even if this worked in my case, if you think of a component which has
> multiple nullable-annotations, you can imagine the increase in
> necessary additional constructors for a fix.
>
>
> regards,
>
> M.Krummrei
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> DPP-Devel mailing list
> DPP...@li...
> https://lists.sourceforge.net/lists/listinfo/dpp-devel
|
|
From: <je...@sa...> - 2017-05-03 04:38:56
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2104/> |
|
From: Michael K. <mic...@fu...> - 2017-05-02 06:12:35
|
Hello,
i recently discovered (with Franz' help :) ) a bug regarding the usage
of Picocontainers and the @nullable-Annotation.
---- what happened: -----
The ConnectionHandler depends optionally on IProxyResolver. The
parameter is annotated with "@nullable", so, while getting the
component, it should be ok if no proxyresolver is provided. (see the
following code)
public ConnectionHandler(final XMPPConnectionService connectionService,
final TCPServer tcpServer, final MDNSService mDNSService,
final IConnectionManager transferManager,
@Nullable final IProxyResolver proxyResolver,
final Preferences preferences) {
...................
The problem is, without a ProxyResolver getComponents() throws an
UnsatisfiableDepency-Exception, so the nullable-annotation does NOT seem
to behave as specified. As a Hotfix i added a second Constructor to
ConnectionHandler without the proxyResolver-Parameter, since according
to the picocontainer-documentation getComponents() returns the fitting
constructor with the least amount of parameters. The fix worked and
getComponents() did not threw an UnsatisfiableDepency-Exception anymore.
even if this worked in my case, if you think of a component which has
multiple nullable-annotations, you can imagine the increase in necessary
additional constructors for a fix.
regards,
M.Krummrei
|
|
From: <je...@sa...> - 2017-05-02 04:37:24
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2103/> |
|
From: <je...@sa...> - 2017-05-01 04:38:19
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2102/> |
|
From: <je...@sa...> - 2017-04-30 04:43:14
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2101/> |
|
From: <je...@sa...> - 2017-04-29 04:38:12
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2100/> |
|
From: <je...@sa...> - 2017-04-28 04:39:25
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2099/> |
|
From: <je...@sa...> - 2017-04-27 04:37:59
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2098/> |
|
From: <je...@sa...> - 2017-04-26 04:37:53
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2097/> |
|
From: <je...@sa...> - 2017-04-25 04:37:20
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2096/> |
|
From: <je...@sa...> - 2017-04-24 04:37:42
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2095/> |
|
From: <je...@sa...> - 2017-04-23 04:36:58
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2094/> |
|
From: <je...@sa...> - 2017-04-22 04:38:10
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2093/> |
|
From: <je...@sa...> - 2017-04-21 04:37:45
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2092/> |
|
From: <je...@sa...> - 2017-04-20 04:37:39
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2091/> |
|
From: <je...@sa...> - 2017-04-19 04:37:33
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2090/> |
|
From: <je...@sa...> - 2017-04-18 04:37:07
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2089/> |
|
From: Stefan R. <sro...@ar...> - 2017-04-17 20:41:40
|
Just ignore the test. Assertions are enabled in IntelliJ and Eclipse (this test also fails in Eclipse) but not in the current CI environment. The test is broken (and -ea is no enabled in the CI). On 17.04.2017 22:35, Tobias Bouschen wrote: > Hi all, > > While trying to run the jUnit test suite for the Saros core, I noticed > that UPnpTest#testDispose() consistently fails when run in IntelliJ but > not when run in Eclipse. > > This is due to the standard run configurations being different: IntelliJ > uses the vm option -ea (to enable asserts) by default, Eclipse does not. > If this option is also enabled in Eclipse, the test case fails as well. > > The problem is a violated assertion outside of the test suite (in > UPnPServiceImpl#createPortMapping(), line 168 to be precise) which is > violated the second time #createPortMapping() is called during the test > (UPnPTest#testDispose(), line 163). > > I am not quite sure whether this is a problem with the implementation or > the test and if I should create a bugtracker entry for this. > > Regards, > Tobias > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > DPP-Devel mailing list > DPP...@li... > https://lists.sourceforge.net/lists/listinfo/dpp-devel |
|
From: Tobias B. <tob...@fu...> - 2017-04-17 20:35:13
|
Hi all, While trying to run the jUnit test suite for the Saros core, I noticed that UPnpTest#testDispose() consistently fails when run in IntelliJ but not when run in Eclipse. This is due to the standard run configurations being different: IntelliJ uses the vm option -ea (to enable asserts) by default, Eclipse does not. If this option is also enabled in Eclipse, the test case fails as well. The problem is a violated assertion outside of the test suite (in UPnPServiceImpl#createPortMapping(), line 168 to be precise) which is violated the second time #createPortMapping() is called during the test (UPnPTest#testDispose(), line 163). I am not quite sure whether this is a problem with the implementation or the test and if I should create a bugtracker entry for this. Regards, Tobias |
|
From: <je...@sa...> - 2017-04-17 04:37:43
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2088/> |
|
From: <je...@sa...> - 2017-04-16 04:38:16
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2087/> |
|
From: <je...@sa...> - 2017-04-15 04:38:53
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2086/> |
|
From: <je...@sa...> - 2017-04-14 04:38:55
|
See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2085/> |