[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
[ https://issues.apache.org/jira/browse/EDGENT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371922#comment-16371922 ] Dale LaBossiere commented on EDGENT-440: update: Chris's latest changes addressed the *tests.jar.asc issue. He said he'll look into the source-release file issue. > Adjust "release" processing so only desired artifacts are uploaded to > Nexus/MavenCentral > > > Key: EDGENT-440 > URL: https://issues.apache.org/jira/browse/EDGENT-440 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Major > > The release process tooling/config for 1.2.0 uploaded some unwanted artifacts > to Nexus and they had to be manually removed before continuing the release. > Adjust the “deploy” processing so as to upload only the desired artifacts to > nexus (no “test” jars, no “distribution” bundles, no “test projects) > We really should have some “release validation” processing, that anyone can > run as part of validating a releasee, for checking the staged nexus artifacts > * have exactly the expected set of jars/wars/pom-only > * the jars have exactly the expected/required (jar/war dependent) > LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
[ https://issues.apache.org/jira/browse/EDGENT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370557#comment-16370557 ] Dale LaBossiere commented on EDGENT-440: These unwanted files are still present in a newly generated release snapshot: * .../*--tests.jar.asc # the signature file of the no longer present test jar files * edgent-parent/.../edgent-parent--source-release.* > Adjust "release" processing so only desired artifacts are uploaded to > Nexus/MavenCentral > > > Key: EDGENT-440 > URL: https://issues.apache.org/jira/browse/EDGENT-440 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Major > > The release process tooling/config for 1.2.0 uploaded some unwanted artifacts > to Nexus and they had to be manually removed before continuing the release. > Adjust the “deploy” processing so as to upload only the desired artifacts to > nexus (no “test” jars, no “distribution” bundles, no “test projects) > We really should have some “release validation” processing, that anyone can > run as part of validating a releasee, for checking the staged nexus artifacts > * have exactly the expected set of jars/wars/pom-only > * the jars have exactly the expected/required (jar/war dependent) > LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
[ https://issues.apache.org/jira/browse/EDGENT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16360939#comment-16360939 ] Dale LaBossiere commented on EDGENT-440: Chris believes publishing of the un-wanted test jars has been addressed via [https://github.com/apache/incubator-edgent/pull/344] I suspect the undesired edgent-parent jars noted above may still be present. Chris? > Adjust "release" processing so only desired artifacts are uploaded to > Nexus/MavenCentral > > > Key: EDGENT-440 > URL: https://issues.apache.org/jira/browse/EDGENT-440 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Major > > The release process tooling/config for 1.2.0 uploaded some unwanted artifacts > to Nexus and they had to be manually removed before continuing the release. > Adjust the “deploy” processing so as to upload only the desired artifacts to > nexus (no “test” jars, no “distribution” bundles, no “test projects) > We really should have some “release validation” processing, that anyone can > run as part of validating a releasee, for checking the staged nexus artifacts > * have exactly the expected set of jars/wars/pom-only > * the jars have exactly the expected/required (jar/war dependent) > LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (EDGENT-445) Console testOverridePortNumber() fails in Jenkins
[ https://issues.apache.org/jira/browse/EDGENT-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere resolved EDGENT-445. Resolution: Fixed Fix Version/s: Apache Edgent 1.3.0 via https://github.com/apache/incubator-edgent/pull/343 > Console testOverridePortNumber() fails in Jenkins > - > > Key: EDGENT-445 > URL: https://issues.apache.org/jira/browse/EDGENT-445 > Project: Edgent > Issue Type: Test > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Major > Fix For: Apache Edgent 1.3.0 > > > The way the test is currently written doesn't seem to work well in the > Jenkins test environment (the actual port != expected port). Hmm... maybe > something to do with the j8+j7 tests and the "singleton" HttpServer instance? > Would hope that something would fail if for example the "available port" was > no longer available when the server started. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (EDGENT-445) Console testOverridePortNumber() fails in Jenkins
[ https://issues.apache.org/jira/browse/EDGENT-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345754#comment-16345754 ] Dale LaBossiere commented on EDGENT-445: Yeah the singleton and test ordering, or not spawning a new JVM for each test class, is the issue. Looks like J8 tests get a new JVM for each test class - i.e., both HttpServerPortTest and HttpServerTest get new HttpServer instances regardless of which order the tests are run. For J7 tests, only the first of those two classes gets a new server instance. Hence when HttpServerTest happens first (Jenkins) HttpServerPortTest fails (you can see the actual port that's reported is the same as the port that got used for the preceding HttpServerTest and there's no "getInstance" log message indicating a new HttpServer is being created. > Console testOverridePortNumber() fails in Jenkins > - > > Key: EDGENT-445 > URL: https://issues.apache.org/jira/browse/EDGENT-445 > Project: Edgent > Issue Type: Test > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Major > > The way the test is currently written doesn't seem to work well in the > Jenkins test environment (the actual port != expected port). Hmm... maybe > something to do with the j8+j7 tests and the "singleton" HttpServer instance? > Would hope that something would fail if for example the "available port" was > no longer available when the server started. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (EDGENT-445) Console testOverridePortNumber() fails in Jenkins
Dale LaBossiere created EDGENT-445: -- Summary: Console testOverridePortNumber() fails in Jenkins Key: EDGENT-445 URL: https://issues.apache.org/jira/browse/EDGENT-445 Project: Edgent Issue Type: Test Components: Test Reporter: Dale LaBossiere Assignee: Dale LaBossiere The way the test is currently written doesn't seem to work well in the Jenkins test environment (the actual port != expected port). Hmm... maybe something to do with the j8+j7 tests and the "singleton" HttpServer instance? Would hope that something would fail if for example the "available port" was no longer available when the server started. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (EDGENT-444) Improve how to create aggregated javadoc
Dale LaBossiere created EDGENT-444: -- Summary: Improve how to create aggregated javadoc Key: EDGENT-444 URL: https://issues.apache.org/jira/browse/EDGENT-444 Project: Edgent Issue Type: Task Components: Miscellaneous Reporter: Dale LaBossiere DOCUMENTATION.md describes how to create the aggregated javadoc (e.g., for adding to the Edgent website). See there for more info on the issues/problems. It would be really nice if (a) there was some way to generate the aggregated javadoc that didn't involve wacking the pom and (b) it was automatically generated as part of "release:perform" (maybe via the inclusion of some profile?). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
[ https://issues.apache.org/jira/browse/EDGENT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326532#comment-16326532 ] Dale LaBossiere commented on EDGENT-440: Forgot to mention that I added buildTools/check_jars.sh. The script checks that LICENSE,... metadata are present in jars/wars. It can be run against a built workspace (e.g., pre-release) or against artifacts retrieved by samples/get-edgent-jars. What's missing is some tool that can pull down the full set of RC artifacts staged in Nexus to verify them, and to verify there are no missing or extra artifacts present. > Adjust "release" processing so only desired artifacts are uploaded to > Nexus/MavenCentral > > > Key: EDGENT-440 > URL: https://issues.apache.org/jira/browse/EDGENT-440 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Major > > The release process tooling/config for 1.2.0 uploaded some unwanted artifacts > to Nexus and they had to be manually removed before continuing the release. > Adjust the “deploy” processing so as to upload only the desired artifacts to > nexus (no “test” jars, no “distribution” bundles, no “test projects) > We really should have some “release validation” processing, that anyone can > run as part of validating a releasee, for checking the staged nexus artifacts > * have exactly the expected set of jars/wars/pom-only > * the jars have exactly the expected/required (jar/war dependent) > LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
[ https://issues.apache.org/jira/browse/EDGENT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326530#comment-16326530 ] Dale LaBossiere commented on EDGENT-440: As of 1/15/2018 a release:perform still uploads the following undesired items: * edgent-parent: edgent-parent--source-release.* * *-tests.jar throughout the j8, j7 and android platform artifacts > Adjust "release" processing so only desired artifacts are uploaded to > Nexus/MavenCentral > > > Key: EDGENT-440 > URL: https://issues.apache.org/jira/browse/EDGENT-440 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Major > > The release process tooling/config for 1.2.0 uploaded some unwanted artifacts > to Nexus and they had to be manually removed before continuing the release. > Adjust the “deploy” processing so as to upload only the desired artifacts to > nexus (no “test” jars, no “distribution” bundles, no “test projects) > We really should have some “release validation” processing, that anyone can > run as part of validating a releasee, for checking the staged nexus artifacts > * have exactly the expected set of jars/wars/pom-only > * the jars have exactly the expected/required (jar/war dependent) > LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (EDGENT-398) intermittent test failure Execution failed for task ':connectors:wsclient-javax.websocket:test'
[ https://issues.apache.org/jira/browse/EDGENT-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-398. -- Resolution: Cannot Reproduce old jira, don't think tests are encountering these anymore so closing > intermittent test failure Execution failed for task > ':connectors:wsclient-javax.websocket:test' > --- > > Key: EDGENT-398 > URL: https://issues.apache.org/jira/browse/EDGENT-398 > Project: Edgent > Issue Type: Test > Components: Test >Affects Versions: Apache Edgent 1.1.0 > Environment: Mac OSx 10.12.1 > java version "1.8.0_92" > Java(TM) SE Runtime Environment (build 1.8.0_92-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode) >Reporter: Kathey Marsden >Priority: Minor > > I saw this failure once when running tests against the 1.1.0 release > candidate. Dale's theory: > "The web socket tests run against a public web socket server. It’s possible > that it was acting up briefly. I haven’t seen problems on my OSX Sierra > fwiw." > Below is the stack trace. Initial assessment is that it is not an Edgent > issue but filing here in case anyone else hits it. > * What went wrong: > Execution failed for task ':connectors:wsclient-javax.websocket:test'. > > There were failing tests. See the results at: > > /edgent/releasetesting1.1/edgent-1.1.0-src/connectors/wsclient-javax.websocket/build/test-results/test/ > type="java.lang.AssertionError">java.lang.AssertionError: contents:[一, 二] > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at > org.apache.edgent.test.topology.TopologyAbstractTest.completeAndValidate(TopologyAbstractTest.java:98) > at > org.apache.edgent.test.topology.TopologyAbstractTest.completeAndValidate(TopologyAbstractTest.java:82) > at > org.apache.edgent.test.connectors.wsclient.javax.websocket.WebSocketClientTest.testReconnectBytes(WebSocketClientTest.java:402) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at >
[jira] [Closed] (EDGENT-242) desensitize IotProviderTest for timing
[ https://issues.apache.org/jira/browse/EDGENT-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-242. -- Resolution: Cannot Reproduce This jira is pretty old and the tests don't seem to be encountering it these days so closing it. > desensitize IotProviderTest for timing > -- > > Key: EDGENT-242 > URL: https://issues.apache.org/jira/browse/EDGENT-242 > Project: Edgent > Issue Type: Test > Components: Test >Reporter: Dale LaBossiere > Labels: newbie > > The following is on the line that's checking jobMbean current state. > Runs fine on my system. Seems like a "wait to get to RUNNING" loop is needed > to make the test more robust. > [junit] expected: but was: > [junit] junit.framework.AssertionFailedError: expected: but > was: > [junit] at > org.apache.edgent.test.fvt.iot.IotProviderTest.testIotProviderCloseApplicationDirect(IotProviderTest.java:161) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-31) FileStreamsTextFileWriterTest testRetainAgeBased test fails with expected:<2> but was:<3>
[ https://issues.apache.org/jira/browse/EDGENT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-31: -- Fix Version/s: Apache Edgent 1.2.0 > FileStreamsTextFileWriterTest testRetainAgeBased test fails with expected:<2> > but was:<3> > - > > Key: EDGENT-31 > URL: https://issues.apache.org/jira/browse/EDGENT-31 > Project: Edgent > Issue Type: Bug > Components: Test >Affects Versions: 0.4.0 > Environment: Windows 7 git bash >Reporter: Kathey Marsden >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > For me on Windows 7 using git bash,FileStreamsTextFileWriterTest > testRetainAgeBased test fails as follows. > [C:\Users\XXX_XX~1\AppData\Local\Temp\test13135096780280359925txt_20160376_092842, > > C:\Users\XXX_XX~1\AppData\Local\Temp\test13135096780280359925txt_20160376_092844, > > C:\Users\XXX_XX~1\AppData\Local\Temp\test13135096780280359925txt_20160376_092846] > expected:<2> but was:<3> > junit.framework.AssertionFailedError: > [C:\Users\XXX_XX~1\AppData\Local\Temp\test13135096780280359925txt_20160376_092842, > > C:\Users\XXX_XX~1\AppData\Local\Temp\test13135096780280359925txt_20160376_092844, > > C:\Users\XXX_XX~1\AppData\Local\Temp\test13135096780280359925txt_20160376_092846] > expected:<2> but was:<3> > at > quarks.test.connectors.file.FileStreamsTextFileWriterTest.completeAndValidateWriter(FileStreamsTextFileWriterTest.java:812) > at > quarks.test.connectors.file.FileStreamsTextFileWriterTest.testRetainAgeBased(FileStreamsTextFileWriterTest.java:451) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-435) CME in TrackingScheduledExecutor seen with testMultiTopologyPollWithError()
[ https://issues.apache.org/jira/browse/EDGENT-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-435. -- > CME in TrackingScheduledExecutor seen with testMultiTopologyPollWithError() > --- > > Key: EDGENT-435 > URL: https://issues.apache.org/jira/browse/EDGENT-435 > Project: Edgent > Issue Type: Bug > Components: Runtime >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > fix TrackingScheduledExecutor CME seen with > testMultiTopologyPollWithError() Jenkins #118 > Being done as part of PR-309: > https://github.com/apache/incubator-edgent/pull/309/commits/d50be305b178132cb7b546d600d9b58c48d069d0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-435) CME in TrackingScheduledExecutor seen with testMultiTopologyPollWithError()
[ https://issues.apache.org/jira/browse/EDGENT-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-435: --- Fix Version/s: Apache Edgent 1.2.0 > CME in TrackingScheduledExecutor seen with testMultiTopologyPollWithError() > --- > > Key: EDGENT-435 > URL: https://issues.apache.org/jira/browse/EDGENT-435 > Project: Edgent > Issue Type: Bug > Components: Runtime >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > fix TrackingScheduledExecutor CME seen with > testMultiTopologyPollWithError() Jenkins #118 > Being done as part of PR-309: > https://github.com/apache/incubator-edgent/pull/309/commits/d50be305b178132cb7b546d600d9b58c48d069d0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-331) HttpConnector put/post mishandling string to byte
[
https://issues.apache.org/jira/browse/EDGENT-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere updated EDGENT-331:
---
Fix Version/s: Apache Edgent 1.1.0
> HttpConnector put/post mishandling string to byte
> -
>
> Key: EDGENT-331
> URL: https://issues.apache.org/jira/browse/EDGENT-331
> Project: Edgent
> Issue Type: Bug
> Components: Connectors
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>Priority: Minor
> Fix For: Apache Edgent 1.1.0
>
>
> HttpGlobalTest testJson{Put,Post} fail on MSWin box where default code page
> is 437 OEM-UnitedStates (not utf8)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (EDGENT-374) IotProvider edgentControl commands are silent no-ops under some failure conditions
[ https://issues.apache.org/jira/browse/EDGENT-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-374. -- > IotProvider edgentControl commands are silent no-ops under some failure > conditions > -- > > Key: EDGENT-374 > URL: https://issues.apache.org/jira/browse/EDGENT-374 > Project: Edgent > Issue Type: Bug > Components: Providers >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.1.0 > > > Sending an IotProvider app an edgentControl command request is a silent no-op > under at least these conditions: > - unable to locate the specified MXBean service - e.g., due to misspelt name > or alias) > - unable to locate the Method for the bean - e.g., due to misspelt method > name, wrong number or args specified > Seems like JsonControlService.controlOperation() should log an error or at > least a warn for these cases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-359) CLONE - Review release process / documentation
[ https://issues.apache.org/jira/browse/EDGENT-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-359. -- > CLONE - Review release process / documentation > -- > > Key: EDGENT-359 > URL: https://issues.apache.org/jira/browse/EDGENT-359 > Project: Edgent > Issue Type: Sub-task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-381) update NOTICES for 2017
[ https://issues.apache.org/jira/browse/EDGENT-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-381. -- > update NOTICES for 2017 > --- > > Key: EDGENT-381 > URL: https://issues.apache.org/jira/browse/EDGENT-381 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Trivial > Fix For: Apache Edgent 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-334) Release Apache Edgent 1.1.0
[ https://issues.apache.org/jira/browse/EDGENT-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-334. -- > Release Apache Edgent 1.1.0 > --- > > Key: EDGENT-334 > URL: https://issues.apache.org/jira/browse/EDGENT-334 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Affects Versions: Apache Edgent 1.1.0 >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Trivial > Labels: release > > Create and release Apache Edgent incubating 1.1.0 > See https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-396) JobMonitorApp restarts job 3 times more than it should
[
https://issues.apache.org/jira/browse/EDGENT-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere closed EDGENT-396.
--
> JobMonitorApp restarts job 3 times more than it should
> --
>
> Key: EDGENT-396
> URL: https://issues.apache.org/jira/browse/EDGENT-396
> Project: Edgent
> Issue Type: Bug
> Components: Runtime
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
> Fix For: Apache Edgent 1.2.0
>
>
> N.B. I don't think this bug affects IotProvider since I'm pretty sure that
> while IotProvider includes JobMonitorApp, it doesn't register a
> JobRegistryService so the monitor does nothing. JIRA forthcoming for that.
> JobMonitorAppTest exercises the app but it doesn't perform any validation
> that restarts were actually happening. Adding instrumentation / validation
> highlights that 3x the number of rebuilds/restarts are happening.
> {code}
> appOne: buildCnt: 7 injectedFailureCnt: 2
> appTwo: buildCnt: 10 injectedFailureCnt: 3
> {code}
> Further investigation identifies the JobMonitorApp's job event filtering as
> the problem. Each "failed" job ends up with 3 events that pass through the
> filter
> {code}
> RUNNING, RUNNING, UNHEALTHY
> RUNNING, CLOSED, UNHEALTHY
> CLOSED, CLOSED, UNHEALTHY
> {code}
> ... or something like that
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (EDGENT-399) fix publish_release.sh
[ https://issues.apache.org/jira/browse/EDGENT-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-399. -- > fix publish_release.sh > -- > > Key: EDGENT-399 > URL: https://issues.apache.org/jira/browse/EDGENT-399 > Project: Edgent > Issue Type: Bug > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > using the wrong variable name for the URL to the RC -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-399) fix publish_release.sh
[ https://issues.apache.org/jira/browse/EDGENT-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-399: --- Fix Version/s: Apache Edgent 1.2.0 > fix publish_release.sh > -- > > Key: EDGENT-399 > URL: https://issues.apache.org/jira/browse/EDGENT-399 > Project: Edgent > Issue Type: Bug > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > using the wrong variable name for the URL to the RC -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-406) Improve documentation for ApplicationServiceMXBean.registerJar()
[ https://issues.apache.org/jira/browse/EDGENT-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-406. -- > Improve documentation for ApplicationServiceMXBean.registerJar() > > > Key: EDGENT-406 > URL: https://issues.apache.org/jira/browse/EDGENT-406 > Project: Edgent > Issue Type: Improvement >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > Clarify the requirements on the jar. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-406) Improve documentation for ApplicationServiceMXBean.registerJar()
[ https://issues.apache.org/jira/browse/EDGENT-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-406: --- Fix Version/s: Apache Edgent 1.2.0 > Improve documentation for ApplicationServiceMXBean.registerJar() > > > Key: EDGENT-406 > URL: https://issues.apache.org/jira/browse/EDGENT-406 > Project: Edgent > Issue Type: Improvement >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > Clarify the requirements on the jar. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-407) JsonFunctions: more convenience functions for creation and unpartitioned window
[
https://issues.apache.org/jira/browse/EDGENT-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere closed EDGENT-407.
--
> JsonFunctions: more convenience functions for creation and unpartitioned
> window
> ---
>
> Key: EDGENT-407
> URL: https://issues.apache.org/jira/browse/EDGENT-407
> Project: Edgent
> Issue Type: Wish
> Components: API
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
> Fix For: Apache Edgent 1.2.0
>
>
> Recently I've found myself repetitively doing the following when transforming
> a stream of simple numerics into a JsonObject (e.g., for publishing via
> IotDevice(TStream)):
> {code}
> TStream s = ...
> TStream js = s.map(val -> {
> JsonObject jo = new JsonObject();
> jo.addProperty("propName", val);
> return jo.
> });
> {code}
> Unfortunately, addProperty() returns void so the above can't be reduced to
> something like:
> {code}
> return new JsonObject().addProperty("propName", val)
> {code}
> I'd like an ease-of-use function like:
> {code}
> TStream js = s.map(JsonFunctions.valueOfNumber("propName"));
> {code}
> For completeness, there should also be {{valueOfString(), valueOfCharacter(),
> valueOfBoolean()}}.
> Also, JsonAnalytics works with JsonElement partitioned windows:
> {{TWindow}}. It should be trivial to be able to
> specify an unpartitioned window. {{Functions.unpartitioned()}} provides that
> for Integer keyed windows. There should be a corresponding
> {{JsonFunctions.unpartitioned()}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (EDGENT-407) JsonFunctions: more convenience functions for creation and unpartitioned window
[
https://issues.apache.org/jira/browse/EDGENT-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere updated EDGENT-407:
---
Fix Version/s: Apache Edgent 1.2.0
> JsonFunctions: more convenience functions for creation and unpartitioned
> window
> ---
>
> Key: EDGENT-407
> URL: https://issues.apache.org/jira/browse/EDGENT-407
> Project: Edgent
> Issue Type: Wish
> Components: API
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
> Fix For: Apache Edgent 1.2.0
>
>
> Recently I've found myself repetitively doing the following when transforming
> a stream of simple numerics into a JsonObject (e.g., for publishing via
> IotDevice(TStream)):
> {code}
> TStream s = ...
> TStream js = s.map(val -> {
> JsonObject jo = new JsonObject();
> jo.addProperty("propName", val);
> return jo.
> });
> {code}
> Unfortunately, addProperty() returns void so the above can't be reduced to
> something like:
> {code}
> return new JsonObject().addProperty("propName", val)
> {code}
> I'd like an ease-of-use function like:
> {code}
> TStream js = s.map(JsonFunctions.valueOfNumber("propName"));
> {code}
> For completeness, there should also be {{valueOfString(), valueOfCharacter(),
> valueOfBoolean()}}.
> Also, JsonAnalytics works with JsonElement partitioned windows:
> {{TWindow}}. It should be trivial to be able to
> specify an unpartitioned window. {{Functions.unpartitioned()}} provides that
> for Integer keyed windows. There should be a corresponding
> {{JsonFunctions.unpartitioned()}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (EDGENT-408) MqttOpenTest failing due to unhealthy test.mosquitto.org
[ https://issues.apache.org/jira/browse/EDGENT-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-408. -- > MqttOpenTest failing due to unhealthy test.mosquitto.org > > > Key: EDGENT-408 > URL: https://issues.apache.org/jira/browse/EDGENT-408 > Project: Edgent > Issue Type: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > it's been several days where the MqttOpenTest tests are failing due to an > unhealthy condition for the test.mosquitto.org public server. > I've seen a 20-40sec delay from CONNECT to CONNACT (e.g., mosquitto_pub -v) > and our tests time out without receiving any msgs/tuples. FWIW, once > connected it appears that msg publish/subscribe work w/o delays. > Don't know why the first 6-7 tests don't fail the connection check in > MqttOpenTest.setupAuthInfo()) but then the rest do and are skipped. > Switch the tests to use the public test server @ iot.eclipse.org -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-409) Add analytic aggregations for non-JsonObject types
[
https://issues.apache.org/jira/browse/EDGENT-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere closed EDGENT-409.
--
> Add analytic aggregations for non-JsonObject types
> --
>
> Key: EDGENT-409
> URL: https://issues.apache.org/jira/browse/EDGENT-409
> Project: Edgent
> Issue Type: New Feature
> Components: Analytics
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
> Fix For: Apache Edgent 1.2.0
>
>
> On more than one occasion I've found myself wishing for analytic aggregations
> like our {{o.a.e.analytics.math3.stat.Statistic.MEAN}}, etc but either being
> unable to use {{JsonAnalytics}} because it lacks batched aggregation support
> or simply wanting something less cumbersome to use because I had a simple use
> case - e.g., wanting to compute a windowed MEAN for a TStream
> yielding a stream of TStream.
> Life would be better if there were Collection-based (not TStream/TWindow
> based) aggregation methods supporting the same set of Statistic and
> Regression aggregate ops that have been defined for use on JsonObjects. For
> example,
> {code}
> static double aggregate(Collection c, UnivariateAggregate
> stat)
> {code}
> See the associated PR for the full API, etc.
> Unfortunately the existing {{o.a.e.analytics.math3.stat.Statistic}} and
> Regression enums lack a "Json" name or package prefix though they are
> inherently tied to other unnecessarily Json-specific interfaces/classes.
> That results in the need to define tuple-type-agnostic analogs like
> Statistics2 and Regression2 (for lack of something better) and the supporting
> interfaces/classes.
> Not included with this JIRA/PR is the opportunity to then unify around using
> these new tuple-type-agnostic Statistic2,Regression2 by augmenting
> JsonAnalytics to have methods that take them as arguments. Then
> json-specific Statistic, Regression and the JsonAnalytic methods that use
> them can be marked deprecated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (EDGENT-408) MqttOpenTest failing due to unhealthy test.mosquitto.org
[ https://issues.apache.org/jira/browse/EDGENT-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-408: --- Fix Version/s: Apache Edgent 1.2.0 > MqttOpenTest failing due to unhealthy test.mosquitto.org > > > Key: EDGENT-408 > URL: https://issues.apache.org/jira/browse/EDGENT-408 > Project: Edgent > Issue Type: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > it's been several days where the MqttOpenTest tests are failing due to an > unhealthy condition for the test.mosquitto.org public server. > I've seen a 20-40sec delay from CONNECT to CONNACT (e.g., mosquitto_pub -v) > and our tests time out without receiving any msgs/tuples. FWIW, once > connected it appears that msg publish/subscribe work w/o delays. > Don't know why the first 6-7 tests don't fail the connection check in > MqttOpenTest.setupAuthInfo()) but then the rest do and are skipped. > Switch the tests to use the public test server @ iot.eclipse.org -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-409) Add analytic aggregations for non-JsonObject types
[
https://issues.apache.org/jira/browse/EDGENT-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere updated EDGENT-409:
---
Fix Version/s: Apache Edgent 1.2.0
> Add analytic aggregations for non-JsonObject types
> --
>
> Key: EDGENT-409
> URL: https://issues.apache.org/jira/browse/EDGENT-409
> Project: Edgent
> Issue Type: New Feature
> Components: Analytics
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
> Fix For: Apache Edgent 1.2.0
>
>
> On more than one occasion I've found myself wishing for analytic aggregations
> like our {{o.a.e.analytics.math3.stat.Statistic.MEAN}}, etc but either being
> unable to use {{JsonAnalytics}} because it lacks batched aggregation support
> or simply wanting something less cumbersome to use because I had a simple use
> case - e.g., wanting to compute a windowed MEAN for a TStream
> yielding a stream of TStream.
> Life would be better if there were Collection-based (not TStream/TWindow
> based) aggregation methods supporting the same set of Statistic and
> Regression aggregate ops that have been defined for use on JsonObjects. For
> example,
> {code}
> static double aggregate(Collection c, UnivariateAggregate
> stat)
> {code}
> See the associated PR for the full API, etc.
> Unfortunately the existing {{o.a.e.analytics.math3.stat.Statistic}} and
> Regression enums lack a "Json" name or package prefix though they are
> inherently tied to other unnecessarily Json-specific interfaces/classes.
> That results in the need to define tuple-type-agnostic analogs like
> Statistics2 and Regression2 (for lack of something better) and the supporting
> interfaces/classes.
> Not included with this JIRA/PR is the opportunity to then unify around using
> these new tuple-type-agnostic Statistic2,Regression2 by augmenting
> JsonAnalytics to have methods that take them as arguments. Then
> json-specific Statistic, Regression and the JsonAnalytic methods that use
> them can be marked deprecated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (EDGENT-417) remove old ant-build cruft
[ https://issues.apache.org/jira/browse/EDGENT-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-417. -- > remove old ant-build cruft > -- > > Key: EDGENT-417 > URL: https://issues.apache.org/jira/browse/EDGENT-417 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > There are still a lot (all?) the old ant build.xml files in the repo > following the conversion to gradle. Some are still needed for the > (unconverted) java7/android platform build retrolambda processing. It > appears that the rest can, and should be, removed. > As part of this JIRA if it's rather easy to further reduce the code in the > top level build.xml (or common-build.xml) then maybe do that too. Otherwise > address in follow-on item. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-417) remove old ant-build cruft
[ https://issues.apache.org/jira/browse/EDGENT-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-417: --- Fix Version/s: Apache Edgent 1.2.0 > remove old ant-build cruft > -- > > Key: EDGENT-417 > URL: https://issues.apache.org/jira/browse/EDGENT-417 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > There are still a lot (all?) the old ant build.xml files in the repo > following the conversion to gradle. Some are still needed for the > (unconverted) java7/android platform build retrolambda processing. It > appears that the rest can, and should be, removed. > As part of this JIRA if it's rather easy to further reduce the code in the > top level build.xml (or common-build.xml) then maybe do that too. Otherwise > address in follow-on item. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-419) Remove use of java8 default interface methods by tests
[ https://issues.apache.org/jira/browse/EDGENT-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-419. -- > Remove use of java8 default interface methods by tests > -- > > Key: EDGENT-419 > URL: https://issues.apache.org/jira/browse/EDGENT-419 > Project: Edgent > Issue Type: Task > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > The gradle/ant retrolambda processing is handling the use of java8 "default" > interface methods but it's causing problems in a maven context. Refactor to > eliminate its use. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-424) Cleanup things that maven-javadoc-plugin 2.10.4 complains about
[ https://issues.apache.org/jira/browse/EDGENT-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-424: --- Fix Version/s: Apache Edgent 1.2.0 > Cleanup things that maven-javadoc-plugin 2.10.4 complains about > --- > > Key: EDGENT-424 > URL: https://issues.apache.org/jira/browse/EDGENT-424 > Project: Edgent > Issue Type: Task >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > That plugin's processing is more picky than we're encountering with the > gradle tooling. > - remove cross project links to non-dependent projects > - remove anchor refs from @see > - replace problem '>' with amp-gt; > - remove problem -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-422) desensitize FileStreamsTextFileWriterTest
[ https://issues.apache.org/jira/browse/EDGENT-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-422. -- > desensitize FileStreamsTextFileWriterTest > - > > Key: EDGENT-422 > URL: https://issues.apache.org/jira/browse/EDGENT-422 > Project: Edgent > Issue Type: Test > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > Was running tests on OSX (which has known directory watcher limitations) and > FileStreamsTextFileWriterTest.testWriterWatcherReader() failed. From > everything I could tell it simply timed out before everything finished. > Increase the timeout limit for it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-424) Cleanup things that maven-javadoc-plugin 2.10.4 complains about
[ https://issues.apache.org/jira/browse/EDGENT-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-424. -- > Cleanup things that maven-javadoc-plugin 2.10.4 complains about > --- > > Key: EDGENT-424 > URL: https://issues.apache.org/jira/browse/EDGENT-424 > Project: Edgent > Issue Type: Task >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > That plugin's processing is more picky than we're encountering with the > gradle tooling. > - remove cross project links to non-dependent projects > - remove anchor refs from @see > - replace problem '>' with amp-gt; > - remove problem -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-422) desensitize FileStreamsTextFileWriterTest
[ https://issues.apache.org/jira/browse/EDGENT-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-422: --- Fix Version/s: Apache Edgent 1.2.0 > desensitize FileStreamsTextFileWriterTest > - > > Key: EDGENT-422 > URL: https://issues.apache.org/jira/browse/EDGENT-422 > Project: Edgent > Issue Type: Test > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > Was running tests on OSX (which has known directory watcher limitations) and > FileStreamsTextFileWriterTest.testWriterWatcherReader() failed. From > everything I could tell it simply timed out before everything finished. > Increase the timeout limit for it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-443) j7 api/topology is generating an undesirable test-server jar
[
https://issues.apache.org/jira/browse/EDGENT-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere closed EDGENT-443.
--
> j7 api/topology is generating an undesirable test-server jar
>
>
> Key: EDGENT-443
> URL: https://issues.apache.org/jira/browse/EDGENT-443
> Project: Edgent
> Issue Type: Bug
> Components: Miscellaneous
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
> Fix For: Apache Edgent 1.2.0
>
>
> platforms/java7/api/topology/pom.xml is unnecessarily generating a
> {{edgent-api-topology--test-server.jar}}. That artifact is present in
> the 1.2.0-incubating nexus content (it wasn't manually removed, related
> EDGENT-440) - not a big deal, just cleanup for the next release.
> I believe the pom's (unnecessary) processing is left over from a time when
> the j8 api/topology test jar used to include some test app that was
> subsequently refactored into its own edgent-test-appservice-applications
> project/jar.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (EDGENT-428) Adding support for csv in MetricsSetup
[ https://issues.apache.org/jira/browse/EDGENT-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-428. -- > Adding support for csv in MetricsSetup > -- > > Key: EDGENT-428 > URL: https://issues.apache.org/jira/browse/EDGENT-428 > Project: Edgent > Issue Type: New Feature > Components: Utils >Affects Versions: Apache Edgent 1.1.0 > Environment: Raspberry PI >Reporter: Thomas Cristanis Cabral Nogueira >Assignee: Dale LaBossiere >Priority: Minor > Labels: features > Fix For: Apache Edgent 1.2.0 > > Attachments: Screen Shot 2017-07-18 at 09.34.36.png, Screen Shot > 2017-07-18 at 09.35.24.png, Screen Shot 2017-07-19 at 11.48.37.png > > > In the current project status only had the support will JMX. So it was > implementing the support to generate .csv files in accordance with [metrics > library|http://metrics.dropwizard.io/3.1.0/manual/core/#man-core-reporters-csv] > already used in the project. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-428) Adding support for csv in MetricsSetup
[ https://issues.apache.org/jira/browse/EDGENT-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-428: --- Fix Version/s: (was: Apache Edgent 1.1.0) Apache Edgent 1.2.0 > Adding support for csv in MetricsSetup > -- > > Key: EDGENT-428 > URL: https://issues.apache.org/jira/browse/EDGENT-428 > Project: Edgent > Issue Type: New Feature > Components: Utils >Affects Versions: Apache Edgent 1.1.0 > Environment: Raspberry PI >Reporter: Thomas Cristanis Cabral Nogueira >Assignee: Dale LaBossiere >Priority: Minor > Labels: features > Fix For: Apache Edgent 1.2.0 > > Attachments: Screen Shot 2017-07-18 at 09.34.36.png, Screen Shot > 2017-07-18 at 09.35.24.png, Screen Shot 2017-07-19 at 11.48.37.png > > > In the current project status only had the support will JMX. So it was > implementing the support to generate .csv files in accordance with [metrics > library|http://metrics.dropwizard.io/3.1.0/manual/core/#man-core-reporters-csv] > already used in the project. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (EDGENT-439) optionally specify TCP port for Jetty HTTP server in console
[ https://issues.apache.org/jira/browse/EDGENT-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-439: --- Fix Version/s: Apache Edgent 1.3.0 > optionally specify TCP port for Jetty HTTP server in console > > > Key: EDGENT-439 > URL: https://issues.apache.org/jira/browse/EDGENT-439 > Project: Edgent > Issue Type: Bug > Components: Console >Affects Versions: Apache Edgent 1.1.0 >Reporter: Edward Pring >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.3.0 > > > In org.apache.edgent.console.server.HttpServer, the server port is hardwired > to "0", so Jetty chooses a random port number each time it starts. This is a > problem when Edgent runs in a Docker container. By default, Docker blocks > access to all ports in a container. Port access can be enabled for a specific > port by number when a container is created, but not after it has started > running. > Perhaps Edgent could honor a port number if specified with "java > *-Djetty.http.port=8080* ...", or use "0" if not. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-441) Adjust Kafka tests to tolerate slow consumer startup
[ https://issues.apache.org/jira/browse/EDGENT-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-441. -- > Adjust Kafka tests to tolerate slow consumer startup > > > Key: EDGENT-441 > URL: https://issues.apache.org/jira/browse/EDGENT-441 > Project: Edgent > Issue Type: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > As part of validating 1.2.0 I ran samples/connectors/kafka. > Manually running of the kafka tests didn't initially succeed due to consumer > startup being very slow (10sec?) this time on my Mac for some reason (running > local zookeeper & kafka server). > Adjust both the test's PUB_DELAY_MSEC (15s) and SEC_TIMEOUT (40s) was > required to make them pass. > I'm pretty sure this has nothing to do with the connector/Edgent (but will > check more). > The tests should be changed so as to tolerate this sort of condition if > possible e.g., instead of using a fixed initial delay for publishing, there > should be some "gate" that blocks tuple publishing until the subscriber is > connected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-442) j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc
[ https://issues.apache.org/jira/browse/EDGENT-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-442. -- > j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc > > > Key: EDGENT-442 > URL: https://issues.apache.org/jira/browse/EDGENT-442 > Project: Edgent > Issue Type: Bug > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > The META-INF/LICENSE, NOTICE, DISCLAIMER and DEPENDENCIES are missing from > the java7 connectors/websocket-jetty jar included in the 1.2.0-incubating > release. > Just fix for the next release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-178) console: stream hover should report "alias" in addition to tags; maybe oplet hover too
[
https://issues.apache.org/jira/browse/EDGENT-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere closed EDGENT-178.
--
> console: stream hover should report "alias" in addition to tags; maybe oplet
> hover too
> --
>
> Key: EDGENT-178
> URL: https://issues.apache.org/jira/browse/EDGENT-178
> Project: Edgent
> Issue Type: Improvement
> Components: Console
>Reporter: Dale LaBossiere
>Assignee: Queenie Ma
>Priority: Minor
> Labels: newbie
> Attachments: alias_stream_hover.png, oplet_hover.png,
> oplet_hover2.png, oplet_properties.png
>
>
> TStream.alias("someAlias") manifests itself in graph.Connector similar to
> tags. I'm pretty sure the graph json captures the alias already.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (EDGENT-327) some http urls in the website prevent full local testing
[ https://issues.apache.org/jira/browse/EDGENT-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-327. -- > some http urls in the website prevent full local testing > > > Key: EDGENT-327 > URL: https://issues.apache.org/jira/browse/EDGENT-327 > Project: Edgent > Issue Type: Task > Components: Web Site >Reporter: Dale LaBossiere >Assignee: Queenie Ma >Priority: Trivial > > If you create a local / test instance of the website (e.g., "jekyll server") > all of the javadoc related links go to the live website. > site/_config.yml defines docurl which is used in many places. See the note > there about issues encountered when I tried changing it from a http url to a > / url... though overall it seemed to work. > Also the javadoc "latest", 1.0.0, ... links in > site/_data/mydoc/mydoc_topnav.yml are http links. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-289) Verify an Eclipse runtime development environment can be setup
[ https://issues.apache.org/jira/browse/EDGENT-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-289. -- > Verify an Eclipse runtime development environment can be setup > -- > > Key: EDGENT-289 > URL: https://issues.apache.org/jira/browse/EDGENT-289 > Project: Edgent > Issue Type: Sub-task >Reporter: Dale LaBossiere >Assignee: Queenie Ma >Priority: Trivial > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-364) Update instructions on how to use the binary/source release bundles
[ https://issues.apache.org/jira/browse/EDGENT-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-364. -- > Update instructions on how to use the binary/source release bundles > --- > > Key: EDGENT-364 > URL: https://issues.apache.org/jira/browse/EDGENT-364 > Project: Edgent > Issue Type: Improvement > Components: Documentation, Web Site >Reporter: Queenie Ma >Assignee: Queenie Ma >Priority: Minor > > I figure this information can be updated in the [Downloading Apache > Edgent|http://edgent.incubator.apache.org/docs/edgent-getting-started.html#downloading-apache-edgent] > section of the _Getting started_ page. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-219) new keyedTimeBatchWindowTest isn't robust?
[ https://issues.apache.org/jira/browse/EDGENT-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-219. -- Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > new keyedTimeBatchWindowTest isn't robust? > -- > > Key: EDGENT-219 > URL: https://issues.apache.org/jira/browse/EDGENT-219 > Project: Edgent > Issue Type: Test > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > From a recent travis-ci run, the test failed. Presumably just a test timing > sensitivity issue? If so can it be desensitized? > [junit] Running quarks.test.window.WindowTest > [junit] Testsuite: quarks.test.window.WindowTest > [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: > 39.843 sec > [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: > 39.843 sec > [junit] > [junit] Testcase: > keyedTimeBatchWindowTest(quarks.test.window.WindowTest):FAILED > [junit] Values:[219, 200, 200, 200, 200, 200, 200, 200, 200, 200] > [junit] junit.framework.AssertionFailedError: Values:[219, 200, 200, 200, > 200, 200, 200, 200, 200, 200] > [junit] at > quarks.test.window.WindowTest.keyedTimeBatchWindowTest(WindowTest.java:422) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-273) Add scripts, etc to enable building samples against a binary-release
[ https://issues.apache.org/jira/browse/EDGENT-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-273. -- Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > Add scripts, etc to enable building samples against a binary-release > > > Key: EDGENT-273 > URL: https://issues.apache.org/jira/browse/EDGENT-273 > Project: Edgent > Issue Type: Improvement > Components: Samples >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > Right now all of the sample jars are only built as part of building Edgent (a > repo or source-release image). At least one sample, > scenarios/iotp/range/scenario, uses pi4j-core.jar and the binary-release > can't include the compiled sample -- pi4j-core is LGPL and incompatible with > ASF licensing. > The binary-release does include the sample src. It should also include > scripts and Eclipse .project/.classpath to enable users to build the samples > against a binary-release image. > Consider creating samples-source and samples-binary release jars and removing > that content from the binary-release? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-393) Wish for Ranges.outsideOf()
[
https://issues.apache.org/jira/browse/EDGENT-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere closed EDGENT-393.
--
Resolution: Fixed
Fix Version/s: Apache Edgent 1.2.0
> Wish for Ranges.outsideOf()
> ---
>
> Key: EDGENT-393
> URL: https://issues.apache.org/jira/browse/EDGENT-393
> Project: Edgent
> Issue Type: Wish
> Components: API
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>Priority: Minor
> Fix For: Apache Edgent 1.2.0
>
>
> I want to be able to write something like:
> {code}
> TStream ...
> .filter(Functions.not(Ranges.closed(100,200))) // true if outside
> [100..200]
> {code}
> The above creates only a single Range and single "not" predicate at topology
> construction time.
> If I made the following mistake I'd create a Range for every tuple:
> {code}
> TStream ...
> .filter(t -> ! Ranges.closed(100,200).contains(t))
> {code}
> In the absence of a "not" Predicate like approach I'd have to explicitly
> allocate my range outside of the lambda:
> {code}
> Range myRange = Ranges.closed(100,200);
> TStream ...
> .filter(t -> ! myRange.contains(t))
> {code}
> The implementation of "not" is trivial and seems like it might be useful in
> other cases:
> {code}
> static Predicate not(Predicate predicate) {
> return t -> ! predicate.test(t);
> }
> {code}
> Yes, I'd be trading off an additional {{Predicate.test()}} invocation per
> tuple against the "out of line" myRange instantiation approach. But I'd get
> to choose which was more important to me.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (EDGENT-413) Simplify download experience
[ https://issues.apache.org/jira/browse/EDGENT-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-413. -- Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > Simplify download experience > > > Key: EDGENT-413 > URL: https://issues.apache.org/jira/browse/EDGENT-413 > Project: Edgent > Issue Type: Improvement >Reporter: John D. Ament >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > Edgent binaries are not distributed via maven. To simplify consumer use > cases, it would be better to see these binaries in a java based repository > manager. > When doing this, it would also be good to remove the heavy binary > distribution in favor of a simpler maven staging repository with the binaries > in it, but it may make sense to split out that work after this is in. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-429) JobMonitorApp.closeJob() doesn't wait for close
[ https://issues.apache.org/jira/browse/EDGENT-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-429. -- Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > JobMonitorApp.closeJob() doesn't wait for close > --- > > Key: EDGENT-429 > URL: https://issues.apache.org/jira/browse/EDGENT-429 > Project: Edgent > Issue Type: Bug > Components: Runtime >Reporter: Dale LaBossiere >Assignee: Christofer Dutz >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > The wait loop in closeJob() never runs because "waitForMillis < 0;" is the > opposite of what's needed. The result can be premature / inaccurate > IllegalStateExceptions. > Detected by SonarQube and fixed in the maven/PR-309 work. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-423) Range.toStringUnsigned() not supported on Java7/android
[ https://issues.apache.org/jira/browse/EDGENT-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-423. -- Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > Range.toStringUnsigned() not supported on Java7/android > --- > > Key: EDGENT-423 > URL: https://issues.apache.org/jira/browse/EDGENT-423 > Project: Edgent > Issue Type: Bug > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Christofer Dutz >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > From Chris Dutz: > While fine tuning my maven migration, I stumbled over a problem in the > analytics/sensors modules. > As part of the build I am validating the classes for Java7 against the > signatures of the Java 7 SDK. Here my plugin found an issue I thought was > worth reporting. > In the class org.apache.edgent.analytics.sensors.Range almost at the end in > the method toUnsignedString we are using Byte.toUnsignedInt, which is only > available in Java 8 … there is no back-port for java 7 for this code. > Eventually we should replace this with code that works on Java 7 too. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-431) cleanup some console code hygiene warnings reported by IntelliJ/SonarQube
[ https://issues.apache.org/jira/browse/EDGENT-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-431. -- Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > cleanup some console code hygiene warnings reported by IntelliJ/SonarQube > - > > Key: EDGENT-431 > URL: https://issues.apache.org/jira/browse/EDGENT-431 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Christofer Dutz >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > JobUtil, MetricsGson, MetricsUtil > Part of PR-309 (maven conversion) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-432) Reduce runtime of some WindowsTest tests
[ https://issues.apache.org/jira/browse/EDGENT-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-432. -- Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > Reduce runtime of some WindowsTest tests > > > Key: EDGENT-432 > URL: https://issues.apache.org/jira/browse/EDGENT-432 > Project: Edgent > Issue Type: Task > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > There are a few that run for 11s. > This has been addressed as part of PR-309. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-434) desentize PlumbingTest.testParallelBalanced
[ https://issues.apache.org/jira/browse/EDGENT-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-434. -- Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > desentize PlumbingTest.testParallelBalanced > --- > > Key: EDGENT-434 > URL: https://issues.apache.org/jira/browse/EDGENT-434 > Project: Edgent > Issue Type: Task > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > Getting intermittent test failures. > Being addressed as part of PR-309 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-438) Enhance WebSocketClientTest's "skip if can't connect"
[ https://issues.apache.org/jira/browse/EDGENT-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-438. -- Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > Enhance WebSocketClientTest's "skip if can't connect" > - > > Key: EDGENT-438 > URL: https://issues.apache.org/jira/browse/EDGENT-438 > Project: Edgent > Issue Type: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > At my work location, WebSocketClientTest.skipTestIfCantConnect() to the > public websocket server succeeds but subsequently, when the connector creates > the real websocket and connects, that fails with > `Didn't switch protocols, expected status <101>, but got <403>`... which > causes a test failure. > For some reason my work location isn't allowing a websocket connect to that > public server. These tests run fine from other locations (e.g., home, the CI > servers). > Basically, enhance the connect test code to do a real websocket connect > instead of just a simple socket.connect(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-436) change tests that use complete() TMO for successful runs
[ https://issues.apache.org/jira/browse/EDGENT-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere closed EDGENT-436. -- Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > change tests that use complete() TMO for successful runs > > > Key: EDGENT-436 > URL: https://issues.apache.org/jira/browse/EDGENT-436 > Project: Edgent > Issue Type: Task > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > Fix For: Apache Edgent 1.2.0 > > > Some tests await the completion TMO before checking for results. This can > yield intermittent failures when running on loaded systems and generally > doesn't play well with automatic bumping of TMO values when > edgent.build.ci=true. > Most of the time the tests can define actual completion-conditions. > Being done as part of PR-309: > File connector: > https://github.com/apache/incubator-edgent/pull/309/commits/e231c41ac38ede13d9cdc20473f09e8ea402e323 > JDBC connector: > https://github.com/apache/incubator-edgent/pull/309/commits/b7897e595072e2c4ae6a084a1a356018c2e5cb44 > Command connector: > https://github.com/apache/incubator-edgent/pull/309/commits/719fe6d8bf787e16cff01c49d86b2ae281437cc5 > Websocket connector: > https://github.com/apache/incubator-edgent/pull/309/commits/a6db4b8f9d2d49ba62f815c51fb4fd1cd3edc9b1 > MQTT connector: > https://github.com/apache/incubator-edgent/pull/309/commits/786d934f0837d387e2b97043a68cc56cc793608e -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (EDGENT-443) j7 api/topology is generating an undesirable test-server jar
[
https://issues.apache.org/jira/browse/EDGENT-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere resolved EDGENT-443.
Resolution: Fixed
Fix Version/s: Apache Edgent 1.2.0
> j7 api/topology is generating an undesirable test-server jar
>
>
> Key: EDGENT-443
> URL: https://issues.apache.org/jira/browse/EDGENT-443
> Project: Edgent
> Issue Type: Bug
> Components: Miscellaneous
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
> Fix For: Apache Edgent 1.2.0
>
>
> platforms/java7/api/topology/pom.xml is unnecessarily generating a
> {{edgent-api-topology--test-server.jar}}. That artifact is present in
> the 1.2.0-incubating nexus content (it wasn't manually removed, related
> EDGENT-440) - not a big deal, just cleanup for the next release.
> I believe the pom's (unnecessary) processing is left over from a time when
> the j8 api/topology test jar used to include some test app that was
> subsequently refactored into its own edgent-test-appservice-applications
> project/jar.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (EDGENT-442) j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc
[ https://issues.apache.org/jira/browse/EDGENT-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere resolved EDGENT-442. Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc > > > Key: EDGENT-442 > URL: https://issues.apache.org/jira/browse/EDGENT-442 > Project: Edgent > Issue Type: Bug > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > Fix For: Apache Edgent 1.2.0 > > > The META-INF/LICENSE, NOTICE, DISCLAIMER and DEPENDENCIES are missing from > the java7 connectors/websocket-jetty jar included in the 1.2.0-incubating > release. > Just fix for the next release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (EDGENT-418) Think LICENSE/NOTICE in binary release .jar & .war are wrong
[ https://issues.apache.org/jira/browse/EDGENT-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere resolved EDGENT-418. Resolution: Fixed Fix Version/s: Apache Edgent 1.2.0 > Think LICENSE/NOTICE in binary release .jar & .war are wrong > > > Key: EDGENT-418 > URL: https://issues.apache.org/jira/browse/EDGENT-418 > Project: Edgent > Issue Type: Bug > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Critical > Fix For: Apache Edgent 1.2.0 > > > An email thread on LICENSE/NOTICE in a .war on general@incubator got me > thinking/checking re Edgent. > The Edgent binary release bundle (.tgz) has a custom/appropriate LICENSE and > NOTICE file. > The Edgent binary release .jar/.war artifacts only have pretty much stock > LICENSE & NOTICE files in them. That seems incorrect. (it's not clear to me > if we can just use the same binary-bundle's LICENSE/NOTICE in each .jar/.war > or if each one has to have customization for that particular artifact. I > hope it's the former (common ones for all binary artifacts). > Today these artifacts are only released as part of the binary-bundle so at > least it has the correct info at the top level. But in the hopefully near > future we will also be publishing on maven-central and then it seems even > more important to get .jar/.war contents correct. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (EDGENT-442) j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc
[ https://issues.apache.org/jira/browse/EDGENT-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16289645#comment-16289645 ] Dale LaBossiere commented on EDGENT-442: fixed via https://github.com/apache/incubator-edgent/pull/335 > j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc > > > Key: EDGENT-442 > URL: https://issues.apache.org/jira/browse/EDGENT-442 > Project: Edgent > Issue Type: Bug > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > > The META-INF/LICENSE, NOTICE, DISCLAIMER and DEPENDENCIES are missing from > the java7 connectors/websocket-jetty jar included in the 1.2.0-incubating > release. > Just fix for the next release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (EDGENT-443) j7 api/topology is generating an undesirable test-server jar
[
https://issues.apache.org/jira/browse/EDGENT-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16289630#comment-16289630
]
Dale LaBossiere commented on EDGENT-443:
fixed via https://github.com/apache/incubator-edgent/pull/336
> j7 api/topology is generating an undesirable test-server jar
>
>
> Key: EDGENT-443
> URL: https://issues.apache.org/jira/browse/EDGENT-443
> Project: Edgent
> Issue Type: Bug
> Components: Miscellaneous
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>
> platforms/java7/api/topology/pom.xml is unnecessarily generating a
> {{edgent-api-topology--test-server.jar}}. That artifact is present in
> the 1.2.0-incubating nexus content (it wasn't manually removed, related
> EDGENT-440) - not a big deal, just cleanup for the next release.
> I believe the pom's (unnecessary) processing is left over from a time when
> the j8 api/topology test jar used to include some test app that was
> subsequently refactored into its own edgent-test-appservice-applications
> project/jar.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
[
https://issues.apache.org/jira/browse/EDGENT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16289579#comment-16289579
]
Dale LaBossiere commented on EDGENT-440:
See related EDGENT-443 that will eliminate the undesired/unnecessary j7
{{edgent-api-topology--test-server.jar}}
> Adjust "release" processing so only desired artifacts are uploaded to
> Nexus/MavenCentral
>
>
> Key: EDGENT-440
> URL: https://issues.apache.org/jira/browse/EDGENT-440
> Project: Edgent
> Issue Type: Task
> Components: Miscellaneous
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>
> The release process tooling/config for 1.2.0 uploaded some unwanted artifacts
> to Nexus and they had to be manually removed before continuing the release.
> Adjust the “deploy” processing so as to upload only the desired artifacts to
> nexus (no “test” jars, no “distribution” bundles, no “test projects)
> We really should have some “release validation” processing, that anyone can
> run as part of validating a releasee, for checking the staged nexus artifacts
> * have exactly the expected set of jars/wars/pom-only
> * the jars have exactly the expected/required (jar/war dependent)
> LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (EDGENT-443) j7 api/topology is generating an undesirable test-server jar
Dale LaBossiere created EDGENT-443:
--
Summary: j7 api/topology is generating an undesirable test-server
jar
Key: EDGENT-443
URL: https://issues.apache.org/jira/browse/EDGENT-443
Project: Edgent
Issue Type: Bug
Components: Miscellaneous
Reporter: Dale LaBossiere
Assignee: Dale LaBossiere
platforms/java7/api/topology/pom.xml is unnecessarily generating a
{{edgent-api-topology--test-server.jar}}. That artifact is present in the
1.2.0-incubating nexus content (it wasn't manually removed, related EDGENT-440)
- not a big deal, just cleanup for the next release.
I believe the pom's (unnecessary) processing is left over from a time when the
j8 api/topology test jar used to include some test app that was subsequently
refactored into its own edgent-test-appservice-applications project/jar.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (EDGENT-442) j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc
[
https://issues.apache.org/jira/browse/EDGENT-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16289535#comment-16289535
]
Dale LaBossiere commented on EDGENT-442:
The pom can't use the typical {{META-INF/**}}
because the j8 jar has "service" metadata that needs to
be included.
The pom's (incorrect) solution of using
{{META-INF/*,META-INF/maven/**}}
PLUS a jar-plugin config decl that specifies
{{META-INF/services/**}}
{{org/apache/edgent/javax/websocket/impl/*.class}}
is causing the problem.
The simple solution is to only include the "services" metadata and class files
from the j8 jar and omit the jar-plugin decl.
> j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc
>
>
> Key: EDGENT-442
> URL: https://issues.apache.org/jira/browse/EDGENT-442
> Project: Edgent
> Issue Type: Bug
> Components: Miscellaneous
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>
> The META-INF/LICENSE, NOTICE, DISCLAIMER and DEPENDENCIES are missing from
> the java7 connectors/websocket-jetty jar included in the 1.2.0-incubating
> release.
> Just fix for the next release.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (EDGENT-442) j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc
Dale LaBossiere created EDGENT-442: -- Summary: j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc Key: EDGENT-442 URL: https://issues.apache.org/jira/browse/EDGENT-442 Project: Edgent Issue Type: Bug Components: Miscellaneous Reporter: Dale LaBossiere Assignee: Dale LaBossiere The META-INF/LICENSE, NOTICE, DISCLAIMER and DEPENDENCIES are missing from the java7 connectors/websocket-jetty jar included in the 1.2.0-incubating release. Just fix for the next release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
[ https://issues.apache.org/jira/browse/EDGENT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286599#comment-16286599 ] Dale LaBossiere commented on EDGENT-440: PR-334 eliminated the staging of the edgent-test* projects https://github.com/apache/incubator-edgent/pull/334 > Adjust "release" processing so only desired artifacts are uploaded to > Nexus/MavenCentral > > > Key: EDGENT-440 > URL: https://issues.apache.org/jira/browse/EDGENT-440 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere > > The release process tooling/config for 1.2.0 uploaded some unwanted artifacts > to Nexus and they had to be manually removed before continuing the release. > Adjust the “deploy” processing so as to upload only the desired artifacts to > nexus (no “test” jars, no “distribution” bundles, no “test projects) > We really should have some “release validation” processing, that anyone can > run as part of validating a releasee, for checking the staged nexus artifacts > * have exactly the expected set of jars/wars/pom-only > * the jars have exactly the expected/required (jar/war dependent) > LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
[ https://issues.apache.org/jira/browse/EDGENT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere reassigned EDGENT-440: -- Assignee: Dale LaBossiere > Adjust "release" processing so only desired artifacts are uploaded to > Nexus/MavenCentral > > > Key: EDGENT-440 > URL: https://issues.apache.org/jira/browse/EDGENT-440 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > > The release process tooling/config for 1.2.0 uploaded some unwanted artifacts > to Nexus and they had to be manually removed before continuing the release. > Adjust the “deploy” processing so as to upload only the desired artifacts to > nexus (no “test” jars, no “distribution” bundles, no “test projects) > We really should have some “release validation” processing, that anyone can > run as part of validating a releasee, for checking the staged nexus artifacts > * have exactly the expected set of jars/wars/pom-only > * the jars have exactly the expected/required (jar/war dependent) > LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
[ https://issues.apache.org/jira/browse/EDGENT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286603#comment-16286603 ] Dale LaBossiere commented on EDGENT-440: Looking into the test-jar deploy issue, I see the maven-deploy-plugin lacks the necessary configurability to achieve omitting the test-jar artifacts. As noted in 1, the solution is to not create test-jars. However, edgent-parent/pom.xml includes config to generate test-jars as they’re needed by the (retrolambda hackery? :-) for j7 test-class generation. Don’t know if there's some other (sensible/maven) way to achieve generating j7 test-classes w/o j8 test-jars. But I’m willing to surrender on that, because Chris says he can/will create a script to achieve the effect. 1 - https://stackoverflow.com/questions/8246136/maven-deploy-not-to-upload-test-jar > Adjust "release" processing so only desired artifacts are uploaded to > Nexus/MavenCentral > > > Key: EDGENT-440 > URL: https://issues.apache.org/jira/browse/EDGENT-440 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > > The release process tooling/config for 1.2.0 uploaded some unwanted artifacts > to Nexus and they had to be manually removed before continuing the release. > Adjust the “deploy” processing so as to upload only the desired artifacts to > nexus (no “test” jars, no “distribution” bundles, no “test projects) > We really should have some “release validation” processing, that anyone can > run as part of validating a releasee, for checking the staged nexus artifacts > * have exactly the expected set of jars/wars/pom-only > * the jars have exactly the expected/required (jar/war dependent) > LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
[ https://issues.apache.org/jira/browse/EDGENT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286402#comment-16286402 ] Dale LaBossiere commented on EDGENT-440: Chris's commit 465d076 eliminated "distribution bundles" from deploy to Nexus > Adjust "release" processing so only desired artifacts are uploaded to > Nexus/MavenCentral > > > Key: EDGENT-440 > URL: https://issues.apache.org/jira/browse/EDGENT-440 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere > > The release process tooling/config for 1.2.0 uploaded some unwanted artifacts > to Nexus and they had to be manually removed before continuing the release. > Adjust the “deploy” processing so as to upload only the desired artifacts to > nexus (no “test” jars, no “distribution” bundles, no “test projects) > We really should have some “release validation” processing, that anyone can > run as part of validating a releasee, for checking the staged nexus artifacts > * have exactly the expected set of jars/wars/pom-only > * the jars have exactly the expected/required (jar/war dependent) > LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (EDGENT-441) Adjust Kafka tests to tolerate slow consumer startup
[ https://issues.apache.org/jira/browse/EDGENT-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere resolved EDGENT-441. Resolution: Fixed fixed via https://github.com/apache/incubator-edgent/pull/330 > Adjust Kafka tests to tolerate slow consumer startup > > > Key: EDGENT-441 > URL: https://issues.apache.org/jira/browse/EDGENT-441 > Project: Edgent > Issue Type: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > > As part of validating 1.2.0 I ran samples/connectors/kafka. > Manually running of the kafka tests didn't initially succeed due to consumer > startup being very slow (10sec?) this time on my Mac for some reason (running > local zookeeper & kafka server). > Adjust both the test's PUB_DELAY_MSEC (15s) and SEC_TIMEOUT (40s) was > required to make them pass. > I'm pretty sure this has nothing to do with the connector/Edgent (but will > check more). > The tests should be changed so as to tolerate this sort of condition if > possible e.g., instead of using a fixed initial delay for publishing, there > should be some "gate" that blocks tuple publishing until the subscriber is > connected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (EDGENT-439) optionally specify TCP port for Jetty HTTP server in console
[ https://issues.apache.org/jira/browse/EDGENT-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere resolved EDGENT-439. Resolution: Fixed fixed via https://github.com/apache/incubator-edgent/pull/331 > optionally specify TCP port for Jetty HTTP server in console > > > Key: EDGENT-439 > URL: https://issues.apache.org/jira/browse/EDGENT-439 > Project: Edgent > Issue Type: Bug > Components: Console >Affects Versions: Apache Edgent 1.1.0 >Reporter: Edward Pring >Assignee: Dale LaBossiere >Priority: Minor > > In org.apache.edgent.console.server.HttpServer, the server port is hardwired > to "0", so Jetty chooses a random port number each time it starts. This is a > problem when Edgent runs in a Docker container. By default, Docker blocks > access to all ports in a container. Port access can be enabled for a specific > port by number when a container is created, but not after it has started > running. > Perhaps Edgent could honor a port number if specified with "java > *-Djetty.http.port=8080* ...", or use "0" if not. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (EDGENT-439) optionally specify TCP port for Jetty HTTP server in console
[ https://issues.apache.org/jira/browse/EDGENT-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285430#comment-16285430 ] Dale LaBossiere commented on EDGENT-439: with PR-331, the Edgent Console port can be overridden using the "edgent.console.port" system property. > optionally specify TCP port for Jetty HTTP server in console > > > Key: EDGENT-439 > URL: https://issues.apache.org/jira/browse/EDGENT-439 > Project: Edgent > Issue Type: Bug > Components: Console >Affects Versions: Apache Edgent 1.1.0 >Reporter: Edward Pring >Assignee: Dale LaBossiere >Priority: Minor > > In org.apache.edgent.console.server.HttpServer, the server port is hardwired > to "0", so Jetty chooses a random port number each time it starts. This is a > problem when Edgent runs in a Docker container. By default, Docker blocks > access to all ports in a container. Port access can be enabled for a specific > port by number when a container is created, but not after it has started > running. > Perhaps Edgent could honor a port number if specified with "java > *-Djetty.http.port=8080* ...", or use "0" if not. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (EDGENT-439) optionally specify TCP port for Jetty HTTP server in console
[ https://issues.apache.org/jira/browse/EDGENT-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere reassigned EDGENT-439: -- Assignee: Dale LaBossiere > optionally specify TCP port for Jetty HTTP server in console > > > Key: EDGENT-439 > URL: https://issues.apache.org/jira/browse/EDGENT-439 > Project: Edgent > Issue Type: Bug > Components: Console >Affects Versions: Apache Edgent 1.1.0 >Reporter: Edward Pring >Assignee: Dale LaBossiere >Priority: Minor > > In org.apache.edgent.console.server.HttpServer, the server port is hardwired > to "0", so Jetty chooses a random port number each time it starts. This is a > problem when Edgent runs in a Docker container. By default, Docker blocks > access to all ports in a container. Port access can be enabled for a specific > port by number when a container is created, but not after it has started > running. > Perhaps Edgent could honor a port number if specified with "java > *-Djetty.http.port=8080* ...", or use "0" if not. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (EDGENT-441) Adjust Kafka tests to tolerate slow consumer startup
Dale LaBossiere created EDGENT-441: -- Summary: Adjust Kafka tests to tolerate slow consumer startup Key: EDGENT-441 URL: https://issues.apache.org/jira/browse/EDGENT-441 Project: Edgent Issue Type: Test Reporter: Dale LaBossiere As part of validating 1.2.0 I ran samples/connectors/kafka. Manually running of the kafka tests didn't initially succeed due to consumer startup being very slow (10sec?) this time on my Mac for some reason (running local zookeeper & kafka server). Adjust both the test's PUB_DELAY_MSEC (15s) and SEC_TIMEOUT (40s) was required to make them pass. I'm pretty sure this has nothing to do with the connector/Edgent (but will check more). The tests should be changed so as to tolerate this sort of condition if possible e.g., instead of using a fixed initial delay for publishing, there should be some "gate" that blocks tuple publishing until the subscriber is connected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral
Dale LaBossiere created EDGENT-440: -- Summary: Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral Key: EDGENT-440 URL: https://issues.apache.org/jira/browse/EDGENT-440 Project: Edgent Issue Type: Task Components: Miscellaneous Reporter: Dale LaBossiere The release process tooling/config for 1.2.0 uploaded some unwanted artifacts to Nexus and they had to be manually removed before continuing the release. Adjust the “deploy” processing so as to upload only the desired artifacts to nexus (no “test” jars, no “distribution” bundles, no “test projects) We really should have some “release validation” processing, that anyone can run as part of validating a releasee, for checking the staged nexus artifacts * have exactly the expected set of jars/wars/pom-only * the jars have exactly the expected/required (jar/war dependent) LICENSE, NOTICE and DISCLAIMER and contain a DEPENDENCIES -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (EDGENT-438) Enhance WebSocketClientTest's "skip if can't connect"
Dale LaBossiere created EDGENT-438: -- Summary: Enhance WebSocketClientTest's "skip if can't connect" Key: EDGENT-438 URL: https://issues.apache.org/jira/browse/EDGENT-438 Project: Edgent Issue Type: Test Reporter: Dale LaBossiere Assignee: Dale LaBossiere At my work location, WebSocketClientTest.skipTestIfCantConnect() to the public websocket server succeeds but subsequently, when the connector creates the real websocket and connects, that fails with `Didn't switch protocols, expected status <101>, but got <403>`... which causes a test failure. For some reason my work location isn't allowing a websocket connect to that public server. These tests run fine from other locations (e.g., home, the CI servers). Basically, enhance the connect test code to do a real websocket connect instead of just a simple socket.connect(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (EDGENT-437) Reduce the number of Edgent jars?
Dale LaBossiere created EDGENT-437:
--
Summary: Reduce the number of Edgent jars?
Key: EDGENT-437
URL: https://issues.apache.org/jira/browse/EDGENT-437
Project: Edgent
Issue Type: Wish
Components: Miscellaneous
Reporter: Dale LaBossiere
Edgent has released 3 sets of jars, one for each platform: java8, java7,
android.
Each platform-set consists of approximately 40 jars.
The new world of releasing Edgent jars to Maven Central doesn't change the
above but it now seems more in your face. Reducing the number of jars that
users deal with seems desirable.
Re: per-platform-jars
Presumably we could have just released a single J7-based set of jars (including
the android-specific jars in that) that would be used on J8,J7 and Android.
I'm pretty sure J8 clients can use J8-lambdas and link and run against the J7
jars.
That said, it sort of feels better to have a real J8 set for J8 execution
environments.
As for J7/Android, do we really need separate sets for both? To clarify, the
Android set is just a copy of the J7-based set, minus a couple J7-only things
(like the console, JMX, development provider) plus a couple of Android-specific
jars (edgent-android-hardware, edgent-android-topology). Would it be bad if we
combined them to a superset of the two? The documentation would address that a
couple are J7-only and a couple are Android-only.
So it seems we could reduce to either:
- a single J7-based set
- a J8-based set and a J7-based set
Thoughts on that?
I don't think it should affect the decision for the above but the complexity of
Edgent maven-based build tooling would be lessened accordingly - i.e., each
platform/set has its own set of 40+ poms so we'd be able to get rid of some.
Re: 40-jars-per-set
===
The large number of jars was fallout from a "micro-service" point of view -
package everything as small as possible and let the developer / deployment
environment include only what's needed in order to lessen (not fully minimize)
the size of an deployment installation.
Some of the jars / features are optional - e.g., what connectors the app uses,
what analytics the app uses. And the Edgent console is generally utilized only
in a development-only context - not imagined to be deployed to a production
device execution context.
The core of the Edgent runtime itself is partitioned to facilitate alternate
implementations. At least at this time there is only a single implementation
and there aren't any discussions, etc of that situation changing any time soon.
These packages represent about 13 jars - the packages:
- api.{execution,function,graph,oplet,topology,window}
- spi.{graph,topology}
- runtime.{appservice,etiao,jmxcontrol,jobregistry,jsoncontrol}
It seems those could reasonably be bundled into a single "edgent-core" jar.
There are three provider implementations: direct,iot,development.
I'm not so sure about bundling them in a single jar (particularly development)
or in the "edgent-core" jar.
It seems appropriate to keep the connectors and analytics "optional" packages
packaged as they are today. That still leaves a fair number of jars (there
would still be e.g., 15 for different connectors, 2 for analytics, 2 for apps,
2 for utils, 1 for console). These "optional" packages are the ones that have
significant 3rd-party jar dependencies.
Thinking out loud...
If we only had to support Edgent application "uber-jars" as a deployment
packaging scheme then we could bundle all of Edgent in a single jar - the
uber-jar construction processing incorporates only "referenced" classes into
the uber-jar. Uber-jars aren't practical as "the only" deployment model.
I suppose an alternative could be to supply (or utilize) some other tooling
that could select "desired" Edgent packages (e.g., that multiple applications
on a device might use) from a single Edgent jar and compose them into a
"custom" Edgent jar for deployment purposes, thereby enabling release of only a
single Edgent jar? Note, the deployment also needs to include any transitive
3rd-party dependency jars.
Thoughts on initially reducing the number of "edgent-core" jars, etc?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (EDGENT-393) Wish for Ranges.outsideOf()
[
https://issues.apache.org/jira/browse/EDGENT-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240903#comment-16240903
]
Dale LaBossiere commented on EDGENT-393:
Upon further thinking I'm less ready to commit to asking for / adding
Functions.not().
Instead I'm changing this JIRA to ask for a Range specific enhancement
to accomplish the same effect: Ranges.outsideOf().
Used like:
{code}
TStream ...
.filter(Ranges.outsideOf(Ranges.closed(100,200))) // true if outside
[100..200]
{code}
> Wish for Ranges.outsideOf()
> ---
>
> Key: EDGENT-393
> URL: https://issues.apache.org/jira/browse/EDGENT-393
> Project: Edgent
> Issue Type: Wish
> Components: API
>Reporter: Dale LaBossiere
>Priority: Minor
>
> I want to be able to write something like:
> {code}
> TStream ...
> .filter(Functions.not(Ranges.closed(100,200))) // true if outside
> [100..200]
> {code}
> The above creates only a single Range and single "not" predicate at topology
> construction time.
> If I made the following mistake I'd create a Range for every tuple:
> {code}
> TStream ...
> .filter(t -> ! Ranges.closed(100,200).contains(t))
> {code}
> In the absence of a "not" Predicate like approach I'd have to explicitly
> allocate my range outside of the lambda:
> {code}
> Range myRange = Ranges.closed(100,200);
> TStream ...
> .filter(t -> ! myRange.contains(t))
> {code}
> The implementation of "not" is trivial and seems like it might be useful in
> other cases:
> {code}
> static Predicate not(Predicate predicate) {
> return t -> ! predicate.test(t);
> }
> {code}
> Yes, I'd be trading off an additional {{Predicate.test()}} invocation per
> tuple against the "out of line" myRange instantiation approach. But I'd get
> to choose which was more important to me.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (EDGENT-393) Wish for Ranges.outsideOf()
[
https://issues.apache.org/jira/browse/EDGENT-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere updated EDGENT-393:
---
Summary: Wish for Ranges.outsideOf() (was: Wish for Functions.not())
> Wish for Ranges.outsideOf()
> ---
>
> Key: EDGENT-393
> URL: https://issues.apache.org/jira/browse/EDGENT-393
> Project: Edgent
> Issue Type: Wish
> Components: API
>Reporter: Dale LaBossiere
>Priority: Minor
>
> I want to be able to write something like:
> {code}
> TStream ...
> .filter(Functions.not(Ranges.closed(100,200))) // true if outside
> [100..200]
> {code}
> The above creates only a single Range and single "not" predicate at topology
> construction time.
> If I made the following mistake I'd create a Range for every tuple:
> {code}
> TStream ...
> .filter(t -> ! Ranges.closed(100,200).contains(t))
> {code}
> In the absence of a "not" Predicate like approach I'd have to explicitly
> allocate my range outside of the lambda:
> {code}
> Range myRange = Ranges.closed(100,200);
> TStream ...
> .filter(t -> ! myRange.contains(t))
> {code}
> The implementation of "not" is trivial and seems like it might be useful in
> other cases:
> {code}
> static Predicate not(Predicate predicate) {
> return t -> ! predicate.test(t);
> }
> {code}
> Yes, I'd be trading off an additional {{Predicate.test()}} invocation per
> tuple against the "out of line" myRange instantiation approach. But I'd get
> to choose which was more important to me.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (EDGENT-393) Wish for Ranges.outsideOf()
[
https://issues.apache.org/jira/browse/EDGENT-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere reassigned EDGENT-393:
--
Assignee: Dale LaBossiere
> Wish for Ranges.outsideOf()
> ---
>
> Key: EDGENT-393
> URL: https://issues.apache.org/jira/browse/EDGENT-393
> Project: Edgent
> Issue Type: Wish
> Components: API
>Reporter: Dale LaBossiere
>Assignee: Dale LaBossiere
>Priority: Minor
>
> I want to be able to write something like:
> {code}
> TStream ...
> .filter(Functions.not(Ranges.closed(100,200))) // true if outside
> [100..200]
> {code}
> The above creates only a single Range and single "not" predicate at topology
> construction time.
> If I made the following mistake I'd create a Range for every tuple:
> {code}
> TStream ...
> .filter(t -> ! Ranges.closed(100,200).contains(t))
> {code}
> In the absence of a "not" Predicate like approach I'd have to explicitly
> allocate my range outside of the lambda:
> {code}
> Range myRange = Ranges.closed(100,200);
> TStream ...
> .filter(t -> ! myRange.contains(t))
> {code}
> The implementation of "not" is trivial and seems like it might be useful in
> other cases:
> {code}
> static Predicate not(Predicate predicate) {
> return t -> ! predicate.test(t);
> }
> {code}
> Yes, I'd be trading off an additional {{Predicate.test()}} invocation per
> tuple against the "out of line" myRange instantiation approach. But I'd get
> to choose which was more important to me.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (EDGENT-219) new keyedTimeBatchWindowTest isn't robust?
[ https://issues.apache.org/jira/browse/EDGENT-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240593#comment-16240593 ] Dale LaBossiere commented on EDGENT-219: some rework of WindowsTest has occurred as part of PR-309 > new keyedTimeBatchWindowTest isn't robust? > -- > > Key: EDGENT-219 > URL: https://issues.apache.org/jira/browse/EDGENT-219 > Project: Edgent > Issue Type: Test > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > > From a recent travis-ci run, the test failed. Presumably just a test timing > sensitivity issue? If so can it be desensitized? > [junit] Running quarks.test.window.WindowTest > [junit] Testsuite: quarks.test.window.WindowTest > [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: > 39.843 sec > [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: > 39.843 sec > [junit] > [junit] Testcase: > keyedTimeBatchWindowTest(quarks.test.window.WindowTest):FAILED > [junit] Values:[219, 200, 200, 200, 200, 200, 200, 200, 200, 200] > [junit] junit.framework.AssertionFailedError: Values:[219, 200, 200, 200, > 200, 200, 200, 200, 200, 200] > [junit] at > quarks.test.window.WindowTest.keyedTimeBatchWindowTest(WindowTest.java:422) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (EDGENT-219) new keyedTimeBatchWindowTest isn't robust?
[ https://issues.apache.org/jira/browse/EDGENT-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240593#comment-16240593 ] Dale LaBossiere edited comment on EDGENT-219 at 11/6/17 5:37 PM: - some rework of WindowsTest has occurred as part of PR-309 (switch to maven) was (Author: dlaboss): some rework of WindowsTest has occurred as part of PR-309 > new keyedTimeBatchWindowTest isn't robust? > -- > > Key: EDGENT-219 > URL: https://issues.apache.org/jira/browse/EDGENT-219 > Project: Edgent > Issue Type: Test > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > > From a recent travis-ci run, the test failed. Presumably just a test timing > sensitivity issue? If so can it be desensitized? > [junit] Running quarks.test.window.WindowTest > [junit] Testsuite: quarks.test.window.WindowTest > [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: > 39.843 sec > [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: > 39.843 sec > [junit] > [junit] Testcase: > keyedTimeBatchWindowTest(quarks.test.window.WindowTest):FAILED > [junit] Values:[219, 200, 200, 200, 200, 200, 200, 200, 200, 200] > [junit] junit.framework.AssertionFailedError: Values:[219, 200, 200, 200, > 200, 200, 200, 200, 200, 200] > [junit] at > quarks.test.window.WindowTest.keyedTimeBatchWindowTest(WindowTest.java:422) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (EDGENT-219) new keyedTimeBatchWindowTest isn't robust?
[ https://issues.apache.org/jira/browse/EDGENT-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere reassigned EDGENT-219: -- Assignee: Dale LaBossiere > new keyedTimeBatchWindowTest isn't robust? > -- > > Key: EDGENT-219 > URL: https://issues.apache.org/jira/browse/EDGENT-219 > Project: Edgent > Issue Type: Test > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > > From a recent travis-ci run, the test failed. Presumably just a test timing > sensitivity issue? If so can it be desensitized? > [junit] Running quarks.test.window.WindowTest > [junit] Testsuite: quarks.test.window.WindowTest > [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: > 39.843 sec > [junit] Tests run: 10, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: > 39.843 sec > [junit] > [junit] Testcase: > keyedTimeBatchWindowTest(quarks.test.window.WindowTest):FAILED > [junit] Values:[219, 200, 200, 200, 200, 200, 200, 200, 200, 200] > [junit] junit.framework.AssertionFailedError: Values:[219, 200, 200, 200, > 200, 200, 200, 200, 200, 200] > [junit] at > quarks.test.window.WindowTest.keyedTimeBatchWindowTest(WindowTest.java:422) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (EDGENT-258) testMultiTopologyPollWithError failure; CME in TrackingScheduledExecutor.cancelAllAsyncTasks()
[
https://issues.apache.org/jira/browse/EDGENT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale LaBossiere closed EDGENT-258.
--
Resolution: Duplicate
Duplicate of EDGENT-435
> testMultiTopologyPollWithError failure; CME in
> TrackingScheduledExecutor.cancelAllAsyncTasks()
> --
>
> Key: EDGENT-258
> URL: https://issues.apache.org/jira/browse/EDGENT-258
> Project: Edgent
> Issue Type: Bug
> Components: Runtime, Test
>Reporter: Dale LaBossiere
>
> This happened in an (ant) travis-ci run.
> The DirectTStreamTest.testMultiTopologyPollWithError() test failed with a
> CancellationException (end of the traces below). Perhaps that was fallout
> from a CME reported within TrackingScheduledExecutor.cancelAllAsyncTasks() on
> the iteration of asyncTasks @ TrackingScheduledExecutor:121 which is the line:
> for (RunnableScheduledFuture task : asyncTasks) {
> (there's also an InterruptedException below)
> But I don't see how that CME can happen. asyncTasks is a (private)
> SynchronizedSet and all iteration on it in TrackingScheduledExecutor does the
> required "synchronized(asyncTasks) { iterate... }" pattern. The
> SynchronizedSet methods all synchronize on the SynchronizedSet object
> (asyncTasks) too so
> an operation like add() or remove() can't occur during that synchronized
> iteration. All access to the underlying set is via the SynchronizedSet. So
> how can that CME happen???
> The only possible non-CME-inducing flaw I see is in removeTrack() where
> there's the non-synchronized sequential access:
> asyncTasks.remove();
> if (asyncTasks.isEmpty() ... // hence may not reflect state following
> preceeding remove()
> Note, there should normally only be 4 instances reporting "Expected Test
> Exception" but there a 8 (maybe due to removeTrack()?). Trust me, they're
> all from this test method execution. I've triple checked :-)
> I'm also confused a bit by the thread pool/thread ids reported on those 8
> instances. Would have expected them to all be associated with the test's
> allocated fixed thread pool and would have expected that to have a single
> pool with 4 thread. But that doesn't seem to be the case?
> Here's the various msgs from the test's execution. Maybe someone else can
> figure it out. From
> https://travis-ci.org/apache/incubator-edgent/builds/164076026
> [junit] Sep 30, 2016 4:37:46 PM
> org.apache.edgent.runtime.etiao.TrackingScheduledExecutor afterExecute
> [junit] SEVERE: Thread:
> pool-5-thread-7-0a765e86-37c1-4299-9655-118420e3f1be: task terminated with
> exception :
> [junit] java.lang.RuntimeException: java.lang.RuntimeException: Expected
> Test Exception
> [junit] at
> org.apache.edgent.oplet.core.PeriodicSource.run(PeriodicSource.java:83)
> [junit] at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [junit] at
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [junit] at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [junit] at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [junit] at
> org.apache.edgent.runtime.etiao.TrackingScheduledExecutor$TrackedFuture.run(TrackingScheduledExecutor.java:205)
> [junit] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [junit] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [junit] at
> org.apache.edgent.runtime.etiao.ThreadFactoryTracker$2.run(ThreadFactoryTracker.java:87)
> [junit] at java.lang.Thread.run(Thread.java:745)
> [junit] Caused by: java.lang.RuntimeException: Expected Test Exception
> [junit] at
> org.apache.edgent.test.topology.TStreamTest.lambda$null$5f279479$1(TStreamTest.java:774)
> [junit] at
> org.apache.edgent.test.topology.TStreamTest$$Lambda$8/2070622949.accept(Unknown
> Source)
> [junit] at
> org.apache.edgent.function.Functions$ThreadSafeConsumer.accept(Functions.java:204)
> [junit] at
> org.apache.edgent.runtime.etiao.SettableForwarder.accept(SettableForwarder.java:54)
> [junit] at org.apache.edgent.oplet.core.FanOut.accept(FanOut.java:50)
> [junit] at
> org.apache.edgent.runtime.etiao.SettableForwarder.accept(SettableForwarder.java:54)
> [junit] at org.apache.edgent.oplet.core.Source.submit(Source.java:47)
> [junit] at
> org.apache.edgent.oplet.functional.SupplierPeriodicSource.fetchTuples(SupplierPeriodicSource.java:52)
> [junit] at
> org.apache.edgent.oplet.core.PeriodicSource.run(PeriodicSource.java:81)
> [junit] ... 9 more
>
[jira] [Updated] (EDGENT-433) Automatically bump some TMO values when running in CI test context
[ https://issues.apache.org/jira/browse/EDGENT-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere updated EDGENT-433: --- Component/s: Test Runtime > Automatically bump some TMO values when running in CI test context > -- > > Key: EDGENT-433 > URL: https://issues.apache.org/jira/browse/EDGENT-433 > Project: Edgent > Issue Type: Test > Components: Runtime, Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere > > Runs in Jenkins are experiencing a lot of transient problems and TMO values > are thought to be contributors to this. > This is being addressed as part of PR-309 > Automatically bump some TMO values when edgent.build.ci=true. > - tweek test.topology.TStreamTest.waitForCompletion() > - tweek topology.spi.tester.AbstractTester.complete() > - tweek runtime.etiao.Executable.invokeAction() > The above may eliminate the need for other test specific uses of > edgent.build.ci in: FiltersTest, PlumbingTest, WindowTest, Mqtt, > wsclient. We'll see. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (EDGENT-436) change tests that use complete() TMO for successful runs
[ https://issues.apache.org/jira/browse/EDGENT-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere reassigned EDGENT-436: -- Assignee: Dale LaBossiere > change tests that use complete() TMO for successful runs > > > Key: EDGENT-436 > URL: https://issues.apache.org/jira/browse/EDGENT-436 > Project: Edgent > Issue Type: Test > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > > Some tests await the completion TMO before checking for results. This can > yield intermittent failures when running on loaded systems and generally > doesn't play well with automatic bumping of TMO values when > edgent.build.ci=true. > Most of the time the tests can define actual completion-conditions. > Being done as part of PR-309: > File connector: > https://github.com/apache/incubator-edgent/pull/309/commits/e231c41ac38ede13d9cdc20473f09e8ea402e323 > JDBC connector: > https://github.com/apache/incubator-edgent/pull/309/commits/b7897e595072e2c4ae6a084a1a356018c2e5cb44 > Command connector: > https://github.com/apache/incubator-edgent/pull/309/commits/719fe6d8bf787e16cff01c49d86b2ae281437cc5 > Websocket connector: > https://github.com/apache/incubator-edgent/pull/309/commits/a6db4b8f9d2d49ba62f815c51fb4fd1cd3edc9b1 > MQTT connector: > https://github.com/apache/incubator-edgent/pull/309/commits/786d934f0837d387e2b97043a68cc56cc793608e -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (EDGENT-435) CME in TrackingScheduledExecutor seen with testMultiTopologyPollWithError()
[ https://issues.apache.org/jira/browse/EDGENT-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere reassigned EDGENT-435: -- Assignee: Dale LaBossiere > CME in TrackingScheduledExecutor seen with testMultiTopologyPollWithError() > --- > > Key: EDGENT-435 > URL: https://issues.apache.org/jira/browse/EDGENT-435 > Project: Edgent > Issue Type: Bug > Components: Runtime >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > > fix TrackingScheduledExecutor CME seen with > testMultiTopologyPollWithError() Jenkins #118 > Being done as part of PR-309: > https://github.com/apache/incubator-edgent/pull/309/commits/d50be305b178132cb7b546d600d9b58c48d069d0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (EDGENT-432) Reduce runtime of some WindowsTest tests
Dale LaBossiere created EDGENT-432: -- Summary: Reduce runtime of some WindowsTest tests Key: EDGENT-432 URL: https://issues.apache.org/jira/browse/EDGENT-432 Project: Edgent Issue Type: Task Components: Test Reporter: Dale LaBossiere Priority: Minor There are a few that run for 11s. This has been addressed as part of PR-309. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (EDGENT-432) Reduce runtime of some WindowsTest tests
[ https://issues.apache.org/jira/browse/EDGENT-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere reassigned EDGENT-432: -- Assignee: Dale LaBossiere > Reduce runtime of some WindowsTest tests > > > Key: EDGENT-432 > URL: https://issues.apache.org/jira/browse/EDGENT-432 > Project: Edgent > Issue Type: Task > Components: Test >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > > There are a few that run for 11s. > This has been addressed as part of PR-309. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (EDGENT-273) Add scripts, etc to enable building samples against a binary-release
[ https://issues.apache.org/jira/browse/EDGENT-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16191840#comment-16191840 ] Dale LaBossiere commented on EDGENT-273: the way the samples are being handled and distributed is being refactored in the maven retooling effort - PR-309 > Add scripts, etc to enable building samples against a binary-release > > > Key: EDGENT-273 > URL: https://issues.apache.org/jira/browse/EDGENT-273 > Project: Edgent > Issue Type: Improvement > Components: Samples >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > > Right now all of the sample jars are only built as part of building Edgent (a > repo or source-release image). At least one sample, > scenarios/iotp/range/scenario, uses pi4j-core.jar and the binary-release > can't include the compiled sample -- pi4j-core is LGPL and incompatible with > ASF licensing. > The binary-release does include the sample src. It should also include > scripts and Eclipse .project/.classpath to enable users to build the samples > against a binary-release image. > Consider creating samples-source and samples-binary release jars and removing > that content from the binary-release? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (EDGENT-334) Release Apache Edgent 1.1.0
[ https://issues.apache.org/jira/browse/EDGENT-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere resolved EDGENT-334. Resolution: Fixed 1.1.0 has been available for a while now > Release Apache Edgent 1.1.0 > --- > > Key: EDGENT-334 > URL: https://issues.apache.org/jira/browse/EDGENT-334 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Affects Versions: Apache Edgent 1.1.0 >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Trivial > Labels: release > > Create and release Apache Edgent incubating 1.1.0 > See https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (EDGENT-413) Simplify download experience
[ https://issues.apache.org/jira/browse/EDGENT-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16191817#comment-16191817 ] Dale LaBossiere commented on EDGENT-413: this is being addressed as part of the maven retooling - PR-309 > Simplify download experience > > > Key: EDGENT-413 > URL: https://issues.apache.org/jira/browse/EDGENT-413 > Project: Edgent > Issue Type: Improvement >Reporter: John D. Ament >Assignee: Dale LaBossiere > > Edgent binaries are not distributed via maven. To simplify consumer use > cases, it would be better to see these binaries in a java based repository > manager. > When doing this, it would also be good to remove the heavy binary > distribution in favor of a simpler maven staging repository with the binaries > in it, but it may make sense to split out that work after this is in. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (EDGENT-418) Think LICENSE/NOTICE in binary release .jar & .war are wrong
[ https://issues.apache.org/jira/browse/EDGENT-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16191815#comment-16191815 ] Dale LaBossiere commented on EDGENT-418: The war's license/notice content is being addressed as part of the maven tooling work PR-309. > Think LICENSE/NOTICE in binary release .jar & .war are wrong > > > Key: EDGENT-418 > URL: https://issues.apache.org/jira/browse/EDGENT-418 > Project: Edgent > Issue Type: Bug > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Critical > > An email thread on LICENSE/NOTICE in a .war on general@incubator got me > thinking/checking re Edgent. > The Edgent binary release bundle (.tgz) has a custom/appropriate LICENSE and > NOTICE file. > The Edgent binary release .jar/.war artifacts only have pretty much stock > LICENSE & NOTICE files in them. That seems incorrect. (it's not clear to me > if we can just use the same binary-bundle's LICENSE/NOTICE in each .jar/.war > or if each one has to have customization for that particular artifact. I > hope it's the former (common ones for all binary artifacts). > Today these artifacts are only released as part of the binary-bundle so at > least it has the correct info at the top level. But in the hopefully near > future we will also be publishing on maven-central and then it seems even > more important to get .jar/.war contents correct. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (EDGENT-418) Think LICENSE/NOTICE in binary release .jar & .war are wrong
[ https://issues.apache.org/jira/browse/EDGENT-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere reassigned EDGENT-418: -- Assignee: Dale LaBossiere > Think LICENSE/NOTICE in binary release .jar & .war are wrong > > > Key: EDGENT-418 > URL: https://issues.apache.org/jira/browse/EDGENT-418 > Project: Edgent > Issue Type: Bug > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Critical > > An email thread on LICENSE/NOTICE in a .war on general@incubator got me > thinking/checking re Edgent. > The Edgent binary release bundle (.tgz) has a custom/appropriate LICENSE and > NOTICE file. > The Edgent binary release .jar/.war artifacts only have pretty much stock > LICENSE & NOTICE files in them. That seems incorrect. (it's not clear to me > if we can just use the same binary-bundle's LICENSE/NOTICE in each .jar/.war > or if each one has to have customization for that particular artifact. I > hope it's the former (common ones for all binary artifacts). > Today these artifacts are only released as part of the binary-bundle so at > least it has the correct info at the top level. But in the hopefully near > future we will also be publishing on maven-central and then it seems even > more important to get .jar/.war contents correct. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (EDGENT-431) cleanup some console code hygiene warnings reported by IntelliJ/SonarQube
[ https://issues.apache.org/jira/browse/EDGENT-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere reassigned EDGENT-431: -- Assignee: Christofer Dutz (was: Dale LaBossiere) > cleanup some console code hygiene warnings reported by IntelliJ/SonarQube > - > > Key: EDGENT-431 > URL: https://issues.apache.org/jira/browse/EDGENT-431 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Christofer Dutz >Priority: Minor > > JobUtil, MetricsGson, MetricsUtil > Part of PR-309 (maven conversion) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (EDGENT-431) cleanup some console code hygiene warnings reported by IntelliJ/SonarQube
[ https://issues.apache.org/jira/browse/EDGENT-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale LaBossiere reassigned EDGENT-431: -- Assignee: Dale LaBossiere (was: Christofer Dutz) > cleanup some console code hygiene warnings reported by IntelliJ/SonarQube > - > > Key: EDGENT-431 > URL: https://issues.apache.org/jira/browse/EDGENT-431 > Project: Edgent > Issue Type: Task > Components: Miscellaneous >Reporter: Dale LaBossiere >Assignee: Dale LaBossiere >Priority: Minor > > JobUtil, MetricsGson, MetricsUtil > Part of PR-309 (maven conversion) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (EDGENT-431) cleanup some console code hygiene warnings reported by IntelliJ/SonarQube
Dale LaBossiere created EDGENT-431: -- Summary: cleanup some console code hygiene warnings reported by IntelliJ/SonarQube Key: EDGENT-431 URL: https://issues.apache.org/jira/browse/EDGENT-431 Project: Edgent Issue Type: Task Components: Miscellaneous Reporter: Dale LaBossiere Assignee: Christofer Dutz Priority: Minor JobUtil, MetricsGson, MetricsUtil Part of PR-309 (maven conversion) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (EDGENT-430) The way TWindow works
[
https://issues.apache.org/jira/browse/EDGENT-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171655#comment-16171655
]
Dale LaBossiere commented on EDGENT-430:
Thanks for the encouragement :-)
Sounds like you're using `continuous/sliding` style window aggregations (via
`TWindow.aggregate()`) but should be using `batch` style aggregations (via
`TWindow.batch()`) in order to get the "trigger aggregations / produce result
tuple every 10sec" behavior it sounds like you're asking for?
> The way TWindow works
> -
>
> Key: EDGENT-430
> URL: https://issues.apache.org/jira/browse/EDGENT-430
> Project: Edgent
> Issue Type: Improvement
>Affects Versions: Apache Edgent 1.1.0
>Reporter: Unai P. Mendizabal
>Priority: Minor
>
> I've trying Edgent out lately and I can say that I see some potential to it.
> Keep it up!
> Anyway, I've been trying the TWindow and its aggregate method and I found out
> the TWindow is constantly being created. For example, I have this line of
> code:
> {code:java}
> TWindow window = tempReadings.last(10, TimeUnit.SECONDS,
> Functions.unpartitioned());
> {code}
> This is non-stopingly filling the TWindow with the readings received within
> the 10 last seconds. I can see that it's logical, but I think it would be way
> more useful if it "created" a new TWindow with all the readings from the last
> 10 seconds. This way, I could aggregate all those readings and send them to
> the MQTT broker every 10 seconds, instead of with every new reading (this is,
> every 100ms), which I think fits better with the purpose of Edgent.
> That's it, thanks!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
