Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

[Dale LaBossiere]

Hi Vino, thanks for the clarification.

One last question :-). Is there ever a situation when it’s desirable/possible 
for a Producer and Consumer to share a single RabbetMQ connection?  e.g., a low 
throughput device wanting to minimize connections?  If so, the separate 
Producer and Consumer split doesn't support that case.

> On Mar 22, 2018, at 9:39 PM, vino yang <yanghua1...@gmail.com> wrote:
> 
> Hi Dale,
> 
> When I wroted the RabbitMQ connector I followed the Kafka Connector's style
> (and I also looked the MQTT connectors). And I chose the Kafka connector as
> the implementation template. The reason is the two classes
> (RabbitmqProducer and RabbitmqConsumer) should not share one rabbitmq's
> connection and channel (implemented in RabbitmqConnector). The two classes
> maybe use in one topology (as consumer and producer) and split the inner
> connection and channel would be better.
> 
> 2018-03-23 2:28 GMT+08:00 Dale LaBossiere <dlab...@apache.org>:
> 
>> I see the new RabbitMQ connector followed the same API scheme as the Kafka
>> connector.  i.e., adding Rabbitmq{Consumer,Producer} for the source/sink
>> respectively.  It looks like it could have followed the MqttStreams
>> approach instead.
>> 
>> @yanghua, is there a reason you chose to offer 
>> o.a.e.connectors.rabbitmq.Rabbitmq{Consumer,Producer}
>> instead of just RabbitmqStreams?
>> 
>> — Dale
>> 
>>> On Mar 22, 2018, at 1:11 PM, Dale LaBossiere <dml.apa...@gmail.com>
>> wrote:
>>> 
>>> Hi Chris.  Hopefully the background provided some useful context.  But
>> like I said, I don’t feel strongly about some renaming if folks agree
>> that’s the right think to do.
>>> 
>>> — Dale
>>> 
>>>> On Mar 22, 2018, at 12:56 PM, Christofer Dutz <
>> christofer.d...@c-ware.de> wrote:
>>>> It was just something I had to explain every time I showed the code for
>> the currently by far most interesting use-case for my plc4x pocs at the
>> moment (pumping data from a PLC to a Kafka topic) . So I thought, that if I
>> have to explain it every time, cause people are confused, then probably we
>> should talk about making things more clear.
>>> 
>> 
>> 

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

[Dale LaBossiere]

I see the new RabbitMQ connector followed the same API scheme as the Kafka 
connector.  i.e., adding Rabbitmq{Consumer,Producer} for the source/sink 
respectively.  It looks like it could have followed the MqttStreams approach 
instead.

@yanghua, is there a reason you chose to offer 
o.a.e.connectors.rabbitmq.Rabbitmq{Consumer,Producer} instead of just 
RabbitmqStreams?

— Dale

> On Mar 22, 2018, at 1:11 PM, Dale LaBossiere <dml.apa...@gmail.com> wrote:
> 
> Hi Chris.  Hopefully the background provided some useful context.  But like I 
> said, I don’t feel strongly about some renaming if folks agree that’s the 
> right think to do.
> 
> — Dale
> 
>> On Mar 22, 2018, at 12:56 PM, Christofer Dutz <christofer.d...@c-ware.de> 
>> wrote:
>> It was just something I had to explain every time I showed the code for the 
>> currently by far most interesting use-case for my plc4x pocs at the moment 
>> (pumping data from a PLC to a Kafka topic) . So I thought, that if I have to 
>> explain it every time, cause people are confused, then probably we should 
>> talk about making things more clear.
> 

Re: Rename "iotp" to "iot-ibm" or similar?

[Dale LaBossiere]

Yeah, “iotp” isn’t very clear/helpful.  I’ve often used “wiotp” when referring 
to “Watson IoT Platform”.
FWIW, wiotp's API’s base package name is com.ibm.iotf (IoT Framework) and 
Edgent’s connector was originally named “iotf”.  Then renamed when they changed 
the name, but not package name, to “IoT Platform”.

+1 on a good naming scheme :-)

Adding “ibm” and/or “watson” to the [package] name seems like a reasonable idea.

Don’t forget about the “iotp" samples, website doc, recipes, and backward 
compatibility :-(  Probably have to deprecate but retain the old names.

— Dale

> On Mar 20, 2018, at 5:10 AM, Christofer Dutz  
> wrote:
> 
> Hi,
> 
> Well on our company in-house conference last Thursday to Sunday I had one 
> session on "implementing IoT Platform adapters for Apache Edgent" and I got 
> some people together and we started to work on an AWS IoT Connector. Seems 
> that the concepts of the iot module can be implemented 1-to-1 with AWS. 
> 
> So this will be the thing I'll be working on actively. I think supporting as 
> many IoT Platforms as possible will help Edgents adoption. Probably 
> Mindsphere which is probably very interesting for PLC4X+Edgent solutions will 
> stay a fantasy as I'm not willing to pay the 10k€/developer/year just to be 
> able to access their libs (Not even mentioning that this totally disqualifies 
> it for being added to an Apache project).
> 
> So probably Googles platform will follow 
> 
> But I still want to rename the "iotp" module to something like "iot-watson" 
> or "iot-ibm-watson"
> 
> 
> Chris
> 
> 
> 
> Am 12.03.18, 03:37 schrieb "vino yang" :
> 
>+1 , I think we also could support to EdgexFoundry in the future.
> 
>2018-03-11 20:00 GMT+08:00 Christofer Dutz :
> 
>> Hi all,
>> 
>> I am currently thinking of adding modules to support other IoT Platforms:
>> 
>>  *   Google IoT
>>  *   AWS IoT
>>  *   Siemens MindSphere
>> 
>> For that the “iotp” sort of doesn’t quite fit as it’s not just “one” IoT
>> platform.
>> So would you be ok with renaming that to something like: “iot-ibm” or
>> similar?
>> 
>> Then we’d have:
>> 
>>  *   Iot-ibm
>>  *   Iot-aws
>>  *   Iot-google
>>  *   Iot-mindsphere/siemens
>> 
>> Chris
>> 
> 
> 

Re: [disscuss] make TStream support groupBy operator?

[Dale LaBossiere]

Also see the SensorsAggregates sample [1].

If this info addresses your question wrt groupBy maybe that’s an indicator that 
more doc is needed to note this.  e.g., something in one or more of the TStream 
class javadoc, TStream.last(), TWindow, FAQ [2] and/or The Power of Edgent [3]. 
 Your thoughts?  Maybe you could contribute some additional clarifying info?

— Dale

[1] 
https://github.com/apache/incubator-edgent-samples/blob/develop/topology/src/main/java/org/apache/edgent/samples/topology/SensorsAggregates.java
 
<https://github.com/apache/incubator-edgent-samples/blob/develop/topology/src/main/java/org/apache/edgent/samples/topology/SensorsAggregates.java>
[2] http://edgent.apache.org/docs/faq <http://edgent.apache.org/docs/faq>
[3] http://edgent.apache.org/docs/power-of-edgent.html 
<http://edgent.apache.org/docs/power-of-edgent.html>

> On Mar 22, 2018, at 1:06 PM, Dale LaBossiere <dml.apa...@gmail.com> wrote:
> 
> Hi,  (I’ve been in my first month of retirement, yeah it would be helpful if 
> other original Edgent developers chimed in)
> 
> Edgent provides count or time based Windows of tuples.  A window inherently 
> supports multiple independently managed partitions by a key.   Continuous or 
> batch aggregations can be performed on each partition.
> 
> See TStream.last() and TWindow.  Additionally, see edgent.analytics.math3.* 
> in particular the javadoc for edgent.analytics.math3.Aggregations.
> 
> Hope that helps.
> 
> — Dale
> 
>> On Mar 20, 2018, at 5:28 AM, vino yang <yanghua1...@gmail.com> wrote:
>> 
>> Hi Chris,
>> 
>> My background is BigData (MapReduce, Spark, Flink, Kafka Stream) those data
>> processing frameworks all provide the groupBy / keyBy operation and
>> aggregation operator. It comes from traditional RDBMS. Edgent like a single
>> JVM's Flink / Kafka Stream works on edges(gateway or IoT).
>> They are similar with each other in some ways.
>> 
>> Vino yang.
>> Thanks!
>> 
>> 2018-03-20 17:05 GMT+08:00 Christofer Dutz <christofer.d...@c-ware.de>:
>> 
>>> Hi Vino,
>>> 
>>> unfortunately I can't contribute any opinion on this as I don't yet
>>> understand the consequences.
>>> I know that in an asynchronous event processing system some operations
>>> that might be useful have to be sacrificed for the sake of asynchonisity.
>>> 
>>> For me Kafka Stream sort of feeling like the cloud-brother of Edgent, it
>>> does seem to support groupBy.
>>> 
>>> Would be really cool if some of the formerly active people could at least
>>> leave some comments on questions like this. You don't have to actually work
>>> on things, but giving us new guys some guidance would be awesome.
>>> 
>>> I don't want to ruin thing you built over years, just because I'm not that
>>> into the topic ... yet.
>>> 
>>> Chris
>>> 
>>> 
>>> 
>>> 
>>> Am 16.03.18, 13:02 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
>>> 
>>>   I'm currently at a conference, so I can't be as responsive as I used
>>> to be ... All will be back to normal next Tuesday ;-)
>>> 
>>>   Chris
>>> 
>>>   Outlook for Android<https://aka.ms/ghei36> herunterladen
>>> 
>>>   
>>>   From: vino yang <yanghua1...@gmail.com>
>>>   Sent: Friday, March 16, 2018 2:26:10 AM
>>>   To: dev@edgent.apache.org
>>>   Subject: Re: [disscuss] make TStream support groupBy operator?
>>> 
>>>   Hi all,
>>> 
>>>   Anyone can give some opinion? Chris ? I think we should support some
>>> reduce
>>>   operation(aggregation function, such as max / avg / min sum) for both
>>>   stream and windowed stream, these features based on the keyBy or
>>> groupBy
>>>   operation.
>>> 
>>>   Vino yang
>>>   Thanks!
>>> 
>>>   2018-03-13 12:52 GMT+08:00 vino yang <yanghua1...@gmail.com>:
>>> 
>>>> Hi guys,
>>>> 
>>>> Does Edgent current support groupBy operator?
>>>> 
>>>> Vino yang
>>>> Thanks.
>>>> 
>>> 
>>> 
>>> 
> 

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

[Dale LaBossiere]

Hi Chris.  Hopefully the background provided some useful context.  But like I 
said, I don’t feel strongly about some renaming if folks agree that’s the right 
think to do.

— Dale

> On Mar 22, 2018, at 12:56 PM, Christofer Dutz  
> wrote:
> It was just something I had to explain every time I showed the code for the 
> currently by far most interesting use-case for my plc4x pocs at the moment 
> (pumping data from a PLC to a Kafka topic) . So I thought, that if I have to 
> explain it every time, cause people are confused, then probably we should 
> talk about making things more clear.

Re: [disscuss] make TStream support groupBy operator?

[Dale LaBossiere]

Hi,  (I’ve been in my first month of retirement, yeah it would be helpful if 
other original Edgent developers chimed in)

Edgent provides count or time based Windows of tuples.  A window inherently 
supports multiple independently managed partitions by a key.   Continuous or 
batch aggregations can be performed on each partition.

See TStream.last() and TWindow.  Additionally, see edgent.analytics.math3.* in 
particular the javadoc for edgent.analytics.math3.Aggregations.

Hope that helps.

— Dale

> On Mar 20, 2018, at 5:28 AM, vino yang  wrote:
> 
> Hi Chris,
> 
> My background is BigData (MapReduce, Spark, Flink, Kafka Stream) those data
> processing frameworks all provide the groupBy / keyBy operation and
> aggregation operator. It comes from traditional RDBMS. Edgent like a single
> JVM's Flink / Kafka Stream works on edges(gateway or IoT).
> They are similar with each other in some ways.
> 
> Vino yang.
> Thanks!
> 
> 2018-03-20 17:05 GMT+08:00 Christofer Dutz :
> 
>> Hi Vino,
>> 
>> unfortunately I can't contribute any opinion on this as I don't yet
>> understand the consequences.
>> I know that in an asynchronous event processing system some operations
>> that might be useful have to be sacrificed for the sake of asynchonisity.
>> 
>> For me Kafka Stream sort of feeling like the cloud-brother of Edgent, it
>> does seem to support groupBy.
>> 
>> Would be really cool if some of the formerly active people could at least
>> leave some comments on questions like this. You don't have to actually work
>> on things, but giving us new guys some guidance would be awesome.
>> 
>> I don't want to ruin thing you built over years, just because I'm not that
>> into the topic ... yet.
>> 
>> Chris
>> 
>> 
>> 
>> 
>> Am 16.03.18, 13:02 schrieb "Christofer Dutz" :
>> 
>>I'm currently at a conference, so I can't be as responsive as I used
>> to be ... All will be back to normal next Tuesday ;-)
>> 
>>Chris
>> 
>>Outlook for Android herunterladen
>> 
>>
>>From: vino yang 
>>Sent: Friday, March 16, 2018 2:26:10 AM
>>To: dev@edgent.apache.org
>>Subject: Re: [disscuss] make TStream support groupBy operator?
>> 
>>Hi all,
>> 
>>Anyone can give some opinion? Chris ? I think we should support some
>> reduce
>>operation(aggregation function, such as max / avg / min sum) for both
>>stream and windowed stream, these features based on the keyBy or
>> groupBy
>>operation.
>> 
>>Vino yang
>>Thanks!
>> 
>>2018-03-13 12:52 GMT+08:00 vino yang :
>> 
>>> Hi guys,
>>> 
>>> Does Edgent current support groupBy operator?
>>> 
>>> Vino yang
>>> Thanks.
>>> 
>> 
>> 
>> 

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

[Dale LaBossiere]

A bit of background…

The Kafka connector is two classes instead of a single KafkaStreams connector 
(with publish(),subscribe()) because at least a while ago, don’t know if this 
is still the case, Kafka had two completely separate classes for a “consumer” 
and a “producer" each with very different config setup params. By comparison 
MQTT has a single MqttClient class (with publish()/subscribe()).

At the time, the decision was to name the Edgent Kafka classes similar to the 
underlying Kafka API classes.  Hence KafkaConsumer (~wrapping Kafka’s 
ConsumerConnector) and KafkaProducer (~wrapping Kafka’s KafkaProducer).  While 
not exposed today, it’s conceivable that some day one could create an Edgent 
Kafka connector instance by providing a Kafka API class directly instead of 
just a config map - e.g., supplying a Kafka KafkaProducer as an arg to the 
Edgent KafkaProducer connector's constructor.  So having the names align seems 
like goodness.

I don’t think the Edgent connectors should be trying to make it unnecessary for 
a user to understand or to mask the underlying system’s API… just make it 
usable, easily usable for a simple/common cases, in an Edgent topology context 
(worrying about when to make an actually external connection, recovering from 
broken connections / reconnecting, handling common tuple types).

As for the specific suggestions, I think simply switching the names of Edgent’s 
KafkaConsumer and KafkaProducer is a bad idea :-)

Offering KafkaSource and KafkaSink is OK I guess (though probably retaining the 
current names for a release or three).  Though I’ll note the Edgent API uses 
“source” and “sink” as verbs, which take a Supplier and a Consumer fn as args 
respectively.  Note Consumer used in the context with sink.

Alternatively there’s KafkaSubscriber and KafkaPublisher.  While clearer than 
Consumer/Producer, I don’t know if they’re any better than Source/Sink.

In the end I guess I don’t feel strongly about it all… though wonder if it’s 
really worth the effort in changing.  At least the Edgent connector’s javadoc 
is pretty good / clear for the classes and their use... I think :-)

— Dale


> On Mar 20, 2018, at 9:59 PM, vino yang  wrote:
> 
> Hi Chris,
> 
> All data processing framework could think it as a *pipeline . *The Edgent's
> point of view, there could be two endpoints :
> 
> 
>   - source : means data injection;
>   - sink : means data export;
> 
> There are many frameworks use this conventional naming rule, such as Apache
> Flume, Apache Flink, Apache Spark(structured streaming) .
> 
> I think "KafkaConsumer" could be replaced with "KafkaSource" and
> "KafkaProducer" could be named "KafkaSink".
> 
> And middle of the pipeline is the transformation of the data, there are
> many operators to transform data ,such as map, flatmap, filter, reduce...
> and so on.
> 
> Vino yang.
> Thanks.
> 
> 2018-03-20 20:51 GMT+08:00 Christofer Dutz :
> 
>> Hi,
>> 
>> have been using the Kafka integration quite often in the past and one
>> thing I always have to explain when demonstrating code and which seems to
>> confuse everyone seeing the code:
>> 
>> I would expect a KafkaConsumer to consume Edgent messages and publish them
>> to Kafka and would expect a KafkaProducer to produce Edgent events.
>> 
>> Unfortunately it seems to be the other way around. This seems a little
>> unintuitive. Judging from the continued confusion when demonstrating code
>> eventually it’s worth considering to rename these (swap their names).
>> Eventually even rename them to “KafkaSource” (Edgent Source that consumes
>> Kafka messages and produces Edgent events) and “KafkaConsumer” (Consumes
>> Edgent Events and produces Kafka messages). After all the Classes are in
>> the Edgent namespace and come from the Edgent libs, so the fixed point when
>> inspecting these should be clear. Also I bet no one would be confused if we
>> called something that produces Kafka messages a consumer as there should
>> never be code that handles this from a Kafka point of view AND uses Edgent
>> at the same time.
>> 
>> Chris
>> 
>> 
>> 

life event

[Dale LaBossiere]

All,

My first day of retirement starts tomorrow!  At this time it’s unclear what my 
level of participation in Edgent and PLC4X will become.  We’ll just have to see 
how it goes.

I’m encouraged by the synergy between Edgent and PLC4X.  Chris is a great 
promoter and contributor so I’m optimistic that interest in both communities 
grows.

In the short term for Edgent I think it would be good to push out another 
release.   Hmm… perhaps a good short term background task for me. And I’m 
interested in enhancing the PLC4X / Edgent integration to support batch PLC 
requests.

In any case, just wanted to share what’s up on my end.

— Dale

Re: High res Edgent logo?

[Dale LaBossiere]

FWIW it was Queenie who provided the assistance/reference not me :-)


> On Feb 21, 2018, at 2:14 PM, Christofer Dutz  
> wrote:
> 
> Hi Dale,
> 
> unfortunately this seems to be too small (
> 
> I'll check with our companies designers, if they could vectorize the image.
> 
> Chris
> 
> Am 21.02.18, 18:50 schrieb "Queenie Ma" :
> 
>Hi Chris,
> 
>We store the logos in the Edgent Wiki, but I don’t think we have anything
>more high resolution that what is available there.
> 
>https://cwiki.apache.org/confluence/display/EDGENT/Apache+Edgent+Logo
> 
>--
>Queenie
> 
>On Wed, Feb 21, 2018 at 7:33 AM, Christofer Dutz 
> 
>wrote:
> 
>> Hi,
>> 
>> for my articles I need a higher resolution logo for Edgent … unfortunately
>> I can’t find any … Vector Graphic would be awesome too 
>> Unfortunately I need it pretty quickly (2 days max). Hope someone can help
>> me with this.
>> 
>> Chris
>> 
> 
> 

[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral

[Dale LaBossiere (JIRA)]

[ 
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)

Re: release:prepare fails due to the new edgent-deployment-filter-maven-plugin

[Dale LaBossiere]

Thanks Chris.

I’ve rerun the process and all of the test files are now eliminated from the 
staged repo.  yay!

+1 on starting the vote to release the plugin.

Followup questions:
- are we in agreement that the edgent-parent source-release files in the repo 
should NOT be present? (to clarify, those files are not the ones in the 
official source release repo in dist.apache.org/repos/dist 
).
- if so, can the plugin, or some other tweak, eliminate them from the repo?

Thanks,
— Dale


> On Feb 21, 2018, at 6:24 AM, Christofer Dutz  
> wrote:
> ...
> so I updated the plugin to no longer deploy the test-jar asc files and I 
> re-deployed the plugin. 
> So now all still existing problems should no longer be a problem.
> 
> So if you've tested the plugin and now no problems remain, I thing we could 
> start a vote on releasing the plugin and hopefully never have to think about 
> it again ;-)

Re: release:prepare fails due to the new edgent-deployment-filter-maven-plugin

[Dale LaBossiere]

more bad news…
Travis checking for a PR also fails.
[ERROR] Plugin 
org.apache.edgent.plugins:edgent-deployment-filter-maven-plugin:1.0.0-SNAPSHOT 
or one of its dependencies could not be resolved: Could not find artifact 
org.apache.edgent.plugins:edgent-deployment-filter-maven-plugin:jar:1.0.0-SNAPSHOT
 in apache-plugins-snapshots 
(https://repository.apache.org/content/repositories/snapshots) -> [Help 
1]

> On Feb 20, 2018, at 2:46 PM, Dale LaBossiere <dml.apa...@gmail.com> wrote:
> 
> Thanks Chris.  Good news, bad news :-)   
> 
> -DignoreSnapshots=true got me through it.
> The *--tests.jar  files are no longer present in the snapshot.  Yay!
> 
> These unwanted files are still present:
> …/*--tests.jar.asc   # i.e., the signature file for the no longer 
> present tests.jar
> edgent-parent/…/edgent-parent--source-release.*
> 
> See the orgapacheedgent-1006 staging repo at 
> https://repository.apache.org/#stagingRepositories 
> <https://repository.apache.org/#stagingRepositories>
> 
> I say release the plugin ASAP :-)
> 
> — Dale
> 
>> On Feb 20, 2018, at 11:05 AM, Christofer Dutz <christofer.d...@c-ware.de 
>> <mailto:christofer.d...@c-ware.de>> wrote:
>> 
>> Hi Dale,
>> 
>> We need to release the plugin first. Otherwise we will not be able to do a 
>> release.
>> 
>> If you agree it's stable and doing its job, we should think about doing that.
>> 
>> We could use a timestamped snapshot and set the 
>> http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#<http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots>allowTimestampedSnapshots<http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots>
>>  
>> <http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#<http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots>allowTimestampedSnapshots<http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots>>
>>  option for testing.
>> 
>> Chris
>> 
>> Outlook for Android<https://aka.ms/ghei36 <https://aka.ms/ghei36>> 
>> herunterladen
>> 
>> 
>> From: Dale LaBossiere <dml.apa...@gmail.com <mailto:dml.apa...@gmail.com>>
>> Sent: Tuesday, February 20, 2018 4:49:09 PM
>> To: dev@edgent.apache.org <mailto:dev@edgent.apache.org>
>> Subject: release:prepare fails due to the new 
>> edgent-deployment-filter-maven-plugin
>> 
>> Hi Chris,
>> 
>> I updated my workspace to the latest develop bits and am trying to run 
>> through the release process to verify the doc etc.
>> 
>> I’m running into a problem with the new plugin.  What’s the scoop?  Is this 
>> the flow and one just needs to ask to resolve it to 1.0.0?
>> 
>> $ mvn release:prepare...
>> ...
>> [INFO] 
>> 
>> [INFO] Building Apache Edgent 1.3.0-SNAPSHOT
>> [INFO] 
>> 
>> ...
>> [INFO] --- maven-release-plugin:2.5.3:prepare (default-cli) @ edgent-parent 
>> ---
>> [INFO] Verifying that there are no local modifications...
>> [INFO]   ignoring changes on: **/pom.xml.releaseBackup, **/pom.xml.next, 
>> **/pom.xml.tag, **/pom.xml.branch, **/release.properties, **/pom.xml.backup
>> [INFO] Executing: /bin/sh -c cd /Users/dlaboss/git/mgmt-edgent-9.10.0 && git 
>> rev-parse --show-toplevel
>> [INFO] Working directory: /Users/dlaboss/git/mgmt-edgent-9.10.0
>> [INFO] Executing: /bin/sh -c cd /Users/dlaboss/git/mgmt-edgent-9.10.0 && git 
>> status --porcelain .
>> [INFO] Working directory: /Users/dlaboss/git/mgmt-edgent-9.10.0
>> [INFO] Checking dependencies and plugins for snapshots ...
>> There are still some remaining snapshot dependencies.
>> : Do you want to resolve them now? (yes/no) no: : yes
>> Dependency type to resolve,: specify the selection number ( 0:All 1:Project 
>> Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 0
>> Dependency 'org.apache.edgent.plugins:edgent-deployment-filter-maven-plugin' 
>> is a snapshot (1.0.0-SNAPSHOT)
>> : Which release version should it be set to? 1.0.0: :
> 

[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral

[Dale LaBossiere (JIRA)]

[ 
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)

Re: release:prepare fails due to the new edgent-deployment-filter-maven-plugin

[Dale LaBossiere]

Thanks Chris.  Good news, bad news :-)   

-DignoreSnapshots=true got me through it.
The *--tests.jar  files are no longer present in the snapshot.  Yay!

These unwanted files are still present:
…/*--tests.jar.asc   # i.e., the signature file for the no longer 
present tests.jar
edgent-parent/…/edgent-parent--source-release.*

See the orgapacheedgent-1006 staging repo at 
https://repository.apache.org/#stagingRepositories 
<https://repository.apache.org/#stagingRepositories>

I say release the plugin ASAP :-)

— Dale

> On Feb 20, 2018, at 11:05 AM, Christofer Dutz <christofer.d...@c-ware.de> 
> wrote:
> 
> Hi Dale,
> 
> We need to release the plugin first. Otherwise we will not be able to do a 
> release.
> 
> If you agree it's stable and doing its job, we should think about doing that.
> 
> We could use a timestamped snapshot and set the 
> http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#<http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots>allowTimestampedSnapshots<http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#allowTimestampedSnapshots>
>  option for testing.
> 
> Chris
> 
> Outlook for Android<https://aka.ms/ghei36> herunterladen
> 
> 
> From: Dale LaBossiere <dml.apa...@gmail.com>
> Sent: Tuesday, February 20, 2018 4:49:09 PM
> To: dev@edgent.apache.org
> Subject: release:prepare fails due to the new 
> edgent-deployment-filter-maven-plugin
> 
> Hi Chris,
> 
> I updated my workspace to the latest develop bits and am trying to run 
> through the release process to verify the doc etc.
> 
> I’m running into a problem with the new plugin.  What’s the scoop?  Is this 
> the flow and one just needs to ask to resolve it to 1.0.0?
> 
> $ mvn release:prepare...
> ...
> [INFO] 
> 
> [INFO] Building Apache Edgent 1.3.0-SNAPSHOT
> [INFO] 
> 
> ...
> [INFO] --- maven-release-plugin:2.5.3:prepare (default-cli) @ edgent-parent 
> ---
> [INFO] Verifying that there are no local modifications...
> [INFO]   ignoring changes on: **/pom.xml.releaseBackup, **/pom.xml.next, 
> **/pom.xml.tag, **/pom.xml.branch, **/release.properties, **/pom.xml.backup
> [INFO] Executing: /bin/sh -c cd /Users/dlaboss/git/mgmt-edgent-9.10.0 && git 
> rev-parse --show-toplevel
> [INFO] Working directory: /Users/dlaboss/git/mgmt-edgent-9.10.0
> [INFO] Executing: /bin/sh -c cd /Users/dlaboss/git/mgmt-edgent-9.10.0 && git 
> status --porcelain .
> [INFO] Working directory: /Users/dlaboss/git/mgmt-edgent-9.10.0
> [INFO] Checking dependencies and plugins for snapshots ...
> There are still some remaining snapshot dependencies.
> : Do you want to resolve them now? (yes/no) no: : yes
> Dependency type to resolve,: specify the selection number ( 0:All 1:Project 
> Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 0
> Dependency 'org.apache.edgent.plugins:edgent-deployment-filter-maven-plugin' 
> is a snapshot (1.0.0-SNAPSHOT)
> : Which release version should it be set to? 1.0.0: :

Re: Problem running some examples with non US locales

[Dale LaBossiere]

Just to close off this thread…  +1 on “Precision.round()” especially that the 
component already depends on commons-math3.
I know you already delivered the fix :-)
Thanks,
— Dale


> On Feb 14, 2018, at 4:13 PM, Christofer Dutz  
> wrote:
> 
> What would you think about eating some more Apache Dogfood?
> 
> 
>org.apache.commons
>commons-math3
>3.6.1
> 
> 
> Then we could use: 
> 
> Precision.round(PI, 3);
> 
> Chris
> 
> 
> Am 14.02.18, 22:09 schrieb "Christofer Dutz" :
> 
>Hi,
> 
>I’m currently working though some of the examples and encountered a 
> problem:
> 
>Code like this:
>nextValue = Double.valueOf(df.format(nextValue));
> 
>Seems to not work correctly in Germany as we have a “,” as decimal 
> separator and “.” as grouping character.
>This results numbers like “10,3” being passed into Double.valueOf which 
> causes exceptions.
> 
>If I change it to this:
> 
>try {
>nextValue = df.parse(df.format(nextValue)).doubleValue();
>} catch (ParseException e) {
>// Ignore ...
>}
> 
>It seems to do what the original codes intention was.
> 
>What would be the cleanest way to solve this problem? I seem to be seeing 
> this pattern quite a lot and the try/catch solution sounds quite annoying 
> with all this try-catch handling.
> 
>Chris
> 
> 
> 
> 

release:prepare fails due to the new edgent-deployment-filter-maven-plugin

[Dale LaBossiere]

Hi Chris,

I updated my workspace to the latest develop bits and am trying to run through 
the release process to verify the doc etc.

I’m running into a problem with the new plugin.  What’s the scoop?  Is this the 
flow and one just needs to ask to resolve it to 1.0.0?

$ mvn release:prepare...
...
[INFO] 
[INFO] Building Apache Edgent 1.3.0-SNAPSHOT
[INFO] 
...
[INFO] --- maven-release-plugin:2.5.3:prepare (default-cli) @ edgent-parent ---
[INFO] Verifying that there are no local modifications...
[INFO]   ignoring changes on: **/pom.xml.releaseBackup, **/pom.xml.next, 
**/pom.xml.tag, **/pom.xml.branch, **/release.properties, **/pom.xml.backup
[INFO] Executing: /bin/sh -c cd /Users/dlaboss/git/mgmt-edgent-9.10.0 && git 
rev-parse --show-toplevel
[INFO] Working directory: /Users/dlaboss/git/mgmt-edgent-9.10.0
[INFO] Executing: /bin/sh -c cd /Users/dlaboss/git/mgmt-edgent-9.10.0 && git 
status --porcelain .
[INFO] Working directory: /Users/dlaboss/git/mgmt-edgent-9.10.0
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.
: Do you want to resolve them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project 
Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 0
Dependency 'org.apache.edgent.plugins:edgent-deployment-filter-maven-plugin' is 
a snapshot (1.0.0-SNAPSHOT)
: Which release version should it be set to? 1.0.0: : 

Re: My first article about Apache Edgent was accepted :-)

[Dale LaBossiere]

Nice!

> On Feb 18, 2018, at 7:10 AM, Christofer Dutz  
> wrote:
> 
> Hi all,
> 
> I just got notified, that the article I submitted for an IT Magazines IoT 
> Special Edition (JavaSPEKTRUM) was accepted and is currently being prepared 
> for being printed. I also added all information needed to come back to this 
> list … will definitely do a dev-list subscription count before it’s released. 
> It’s mainly focused on Edgent with a little bit (about 25%) about Apache 
> PLC4X.
> 
> A second Article for another Magazine IoT Special Edition is also submitted 
> and will follow a few weeks after that. That however will be the other way 
> around 75% about PLC4X and 25% about Edgent …
> 
> Keep your fingers crossed ☺ Hopefully both will help get some life back to 
> this list and specially spread the Word about both projects (Most people I 
> talk to have never heard of both) …
> 
> Chris

[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral

[Dale LaBossiere (JIRA)]

[ 
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)

Re: [DRAFT] January Podling Report

[Dale LaBossiere]

I merged info from the two drafts and will submit the following.
Feel free to update the submission as I’m out the rest of the week.
— Dale

===

Edgent

Apache Edgent is a programming SDK and micro-kernel style runtime
that can be embedded in gateways and small footprint edge devices enabling
local, real-time, analytics on the continuous streams of data coming
from equipment, vehicles, systems, appliances, devices and sensors of
all kinds (for example, Raspberry Pis or smart phones). Working in
conjunction with centralized analytic systems, Apache Edgent provides
efficient and timely analytics across the whole IoT ecosystem: from the
center to the edge.

Edgent has been incubating since 2016-02-29.

Three most important issues to address in the move towards graduation:

  1. Create and expand a diverse community of contributors and committers
 around the Edgent project.
  2. Attracting at least another independent committer/ppmc member.
  3. Finding further real world users of Edgent

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

  Community growth and participation continues to be an issue. One of the 
  two active committer/PPMC members is retiring at the end of February
  and the level of their continuing participation is unclear.
  But synergy with Apache PLC4X is encouraging.

How has the community developed since the last report?

  * Apache PLC4X is very interested in and promoting Apache Edgent as
part of their overall story.  An initial Edgent connector was created
and contributed to PLC4X.  Christofer Dutz demonstrated Edgent
working together with PLC4X at the IoT Hessen Meetup at end of
December and at Nortec Hamburg (Industrial fair).
  * Total, we have 72 subscribers to our mailing list, a reduction
of 1 since the last report.

How has the project developed since the last report?

  * Apache Edgent 1.2.0 was released.  The release is the culmination
of the conversion to Maven and includes a number of enhancements and
bug fixes. Binaries are now available from Nexus and Maven Central
to make it easier to use Edgent.
  * Edgent Samples are now available via the new GitHub repository
apache/incubator-edgent-samples.
  * According to JIRA, 8 new issues were added and 23 issues were resolved
in the last 90 days
  * 62 commits were made in the last 90 days.
  
How would you assess the podling's maturity?

  Edgent is making slow but consistent progress towards graduation. While we
  don't yet meet the diversity requirements, we put emphasis on community
  growth through outreach which will ultimately pave the way for additional
  committers and contributors.

  Additionally, before we graduate it is important that we find users
  outside of IBM. As most Edgent committers are employed by IBM, external
  stakeholders help ensure long term contribution to the project.

  [ ] Initial setup
  [ ] Working towards first release
  [X] Community building
  [ ] Nearing graduation
  [ ] Other:

Date of last release:

  2017-12-14  Apache Edgent 1.2.0

When were the last committers or PPMC members elected?

  In August 2017, we added Christofer Dutz as a new committer
  and PPMC member.


Signed-off-by:

  [ ](edgent) Daniel Debrunner
 Comments:
  [ ](edgent) Luciano Resende
 Comments:
  [ ](edgent) Justin Mclean
 Comments:
  [ ](edgent) John D. Ament
 Comments:

IPMC/Shepherd notes:


=

Re: [DRAFT] January Podling Report

[Dale LaBossiere]

Hmm… I sent a draft on Jan 30th and was planning on submitting it today.
https://lists.apache.org/thread.html/c23ae4d7536e911b10668de205e435bb171c529d96df4a536fd1ddcc@%3Cdev.edgent.apache.org%3E
But no worries.  Maybe just merge some of the info into yours.
— Dale

> On Feb 5, 2018, at 6:33 AM, Christofer Dutz  wrote:
> 
> Hi all,
> 
> So I whipped up a report … hope I got the most important things in there … I 
> added things since November as this seems to have been our last report.
> 
> 
> 
> Edgent
> 
> Apache Edgent is a programming SDK and micro-kernel style runtime
> that can be embedded in gateways and small footprint edge devices enabling
> local, real-time, analytics on the continuous streams of data coming
> from equipment, vehicles, systems, appliances, devices and sensors of
> all kinds (for example, Raspberry Pis or smart phones). Working in
> conjunction with centralized analytic systems, Apache Edgent provides
> efficient and timely analytics across the whole IoT ecosystem: from the
> center to the edge.
> 
> Edgent has been incubating since 2016-02-29.
> 
> Three most important issues to address in the move towards graduation:
> 
>  1. Create and expand a diverse community of contributors and committers
> around the Edgent project.
>  2. Attracting at least another independent committer/ppmc member.
>  3. Finding further real world users of Edgent
> 
> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> aware of?
> 
> The new incubating project: Apache PLC4X has bound quite a bit of the active
> Edgent contributors for now. So right now we haven’t been as active as in the 
> months
> before. This is due to the fact that the affected contributors have been 
> working
> on an Edgent integration module for PLC4X. As these activities will require 
> less
> attention in the future we are hoping the adoption of PLC4X & Edgent to 
> increase
> the user- and eventually contributor-base.
> 
> How has the community developed since the last report?
> 
> 
>  *   Christofer Dutz demonstrated Apache Edgent working together with Apache 
> PLC4X at the IoT Hessen Meetup end of December
>  *   Christofer Dutz demonstrated Apache Edgent working together with Apache 
> PLC4X at Nortec Hamburg (Industrial fair)
>  *   …
> 
> How has the project developed since the last report?
> 
> 
>  *   Released Apache Edgent 1.2.0 as first Maven built version
>  *   A lot of effort has been put into ensuring the stability of the 
> test-results (There were some timing related failures in the past)
>  *   We have been working on simplifying the build and release process 
> (Especially reducing the number of manual operations)
>  *   Two contributors/committers have been very active in creating an 
> integration module for Apache PLC4X
>  *   …
> 
> 
> How would you assess the podling's maturity?
> 
>  Edgent is making slow but consistent progress towards graduation. While we
>  don't yet meet the diversity requirements, we put emphasis on community
>  growth through outreach which will ultimately pave the way for additional
>  committers and contributors. Especially in combination with Apache PLC4X we
>  are hoping to help grow the community of both projects.
> 
>  Additionally, before we graduate it is important that we find users
>  outside of IBM. As most Edgent committers are employed by IBM, external
>  stakeholders help ensure long term contribution to the project.
> 
>  [ ] Initial setup
>  [ ] Working towards first release
>  [X] Community building
>  [ ] Nearing graduation
>  [ ] Other:
> 
> Date of last release:
> 
> 2017-12-14 Apache Edgent 1.2.0
> 
> When were the last committers or PPMC members elected?
> 
>  In August 2017, we added Christofer Dutz as a new committer
>  and PPMC member.
> 
> 

[jira] [Resolved] (EDGENT-445) Console testOverridePortNumber() fails in Jenkins

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

[ 
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 (JIRA)]

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)

[DRAFT] January Podling Report Edgent

[Dale LaBossiere]

Comments?

===
Edgent

Apache Edgent is a programming SDK and micro-kernel style runtime
that can be embedded in gateways and small footprint edge devices enabling
local, real-time, analytics on the continuous streams of data coming
from equipment, vehicles, systems, appliances, devices and sensors of
all kinds (for example, Raspberry Pis or smart phones). Working in
conjunction with centralized analytic systems, Apache Edgent provides
efficient and timely analytics across the whole IoT ecosystem: from the
center to the edge.

Edgent has been incubating since 2016-02-29.

Three most important issues to address in the move towards graduation:

  1. Create and expand a diverse community of contributors and committers
 around the Edgent project.
  2. Attracting at least another independent committer/ppmc member.
  3. Finding further real world users of Edgent

Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
aware of?

  Community participation, implying interest in Edgent, continues
  to be an issue.  One of the two active committer/PPMC members is
  retiring at the end of February and the level of their continuing
  participation is unclear.

How has the community developed since the last report?

  * Apache PLC4X is interested in and promoting Apache Edgent as part
of their overall story.  An Edgent connector was created and
contributed to PLC4X.
  * Total, we have 72 subscribers to our mailing list, a reduction
of 1 since the last report.

How has the project developed since the last report?

  * Apache Edgent 1.2.0 was released.  The release is the culmination
of the conversion to Maven and includes a number of enhancements and
bug fixes. Binaries are now available from Nexus and Maven Central
to make it easier to use Edgent.
  * Edgent Samples are now available via the new GitHub repository
apache/incubator-edgent-samples
  * According to JIRA, 8 new issues were added and 23 issues were resolved
in the last 90 days
  * 62 commits were made in the last 90 days.
  
How would you assess the podling's maturity?

  Edgent is making slow but consistent progress towards graduation. While we
  don't yet meet the diversity requirements, we put emphasis on community
  growth through outreach which will ultimately pave the way for additional
  committers and contributors.

  Additionally, before we graduate it is important that we find users
  outside of IBM. As most Edgent committers are employed by IBM, external
  stakeholders help ensure long term contribution to the project.

  [ ] Initial setup
  [ ] Working towards first release
  [X] Community building
  [ ] Nearing graduation
  [ ] Other:

Date of last release:

  2017-12-14  Apache Edgent 1.2.0

When were the last committers or PPMC members elected?

  In August 2017, we added Christofer Dutz as a new committer
  and PPMC member.


Signed-off-by:

  [ ](edgent) Daniel Debrunner
 Comments:
  [ ](edgent) Luciano Resende
 Comments:
  [ ](edgent) Justin Mclean
 Comments:
  [ ](edgent) John D. Ament
 Comments:

IPMC/Shepherd notes:


=

[jira] [Created] (EDGENT-444) Improve how to create aggregated javadoc

[Dale LaBossiere (JIRA)]

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)

Re: reproducible release process

[Dale LaBossiere]

Hi Chris,

Regarding EDGENT-440 and the numerous undesired staged artifacts,

When you manually deleted some staged artifacts (presumably via the browser 
UI?), did you also have to update the metadata files or such?

A while ago you mentioned creating a script/tool to automate this cleanup (in 
preference to trying to do more pom/config wacking).  What were your thoughts 
on that?  Any pointers, etc?

Thanks,
— Dale

> On Jan 16, 2018, at 12:53 AM, Christofer Dutz <christofer.d...@c-ware.de> 
> wrote:
> 
> Hi Dale,
> 
> Sorry für the late response.
> Yes you are correct. Naveen doesn't provide any means for the merging. I did 
> use the simple  commands you did without any fast forward. Don't know if 
> Apache's git would have accepted that anyway.
> 
> Chris
> 
> Outlook for Android<https://aka.ms/ghei36> herunterladen
> 
> 
> 
> Von: Dale LaBossiere
> Gesendet: Mittwoch, 10. Januar, 19:50
> Betreff: Re: reproducible release process
> An: dev@edgent.apache.org
> 
> 
> Now that release:perform worked… Assuming the RC vote passes and the nexus 
> staging repository is “closed”... It looks like the maven-release-plugin 
> doesn’t provide any merging of the release to appropriate locations. What 
> were the exact cmds you used to merge the release to master, to create: 
> commit 1832130 Merge tag ‘edgent-1.2.0’ git checkout master git pull # ensure 
> master is up to date git merge edgent-1.2.0 -m “Merge tag 'edgent-1.2.0’” # 
> did you use —ff-only? should we / not? — Dale
> 

[jira] [Commented] (EDGENT-440) Adjust "release" processing so only desired artifacts are uploaded to Nexus/MavenCentral

[Dale LaBossiere (JIRA)]

[ 
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

[Dale LaBossiere (JIRA)]

[ 
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)

Re: reproducible release process

[Dale LaBossiere]

Now that release:perform worked…

Assuming the RC vote passes and the nexus staging repository is “closed”...

It looks like the maven-release-plugin doesn’t provide any merging of the 
release to appropriate locations.
What were the exact cmds you used to merge the release to master, to create:

commit 1832130Merge tag ‘edgent-1.2.0’

git checkout master
git pull  # ensure master is up to date
git merge edgent-1.2.0 -m “Merge tag 'edgent-1.2.0’”   # did you 
use —ff-only? should we / not?

— Dale

Re: reproducible release process

[Dale LaBossiere]

when I run the mvn release:perform, it fails when trying to upload to nexus:

Failed to execute goal 
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on 
project edgent-parent: Failed to deploy artifacts: Could not transfer artifact 
org.apache.edgent:edgent-parent:pom:9.9.0 from/to apache.releases.https 
(https://repository.apache.org/service/local/staging/deploy/maven2): Failed to 
transfer file: 
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/edgent/edgent-parent/9.9.0/edgent-parent-9.9.0.pom.
 Return code is: 401

I tried added a server decl to my .m2/settings.xml but it didn’t help.  I was 
guessing at the server id based on the repository id “apache-release” in the 
pom.  I also tried an id of “apache.releases.https” but that didn’t help.  I 
can log into https://repository.apache.org with that id/pw.

  apache-release
  dlaboss  
  my-encrypted-password  


What’s the correct thing to do?

FYI I'm updating releasing.adoc as I go so no need for you to do that.

Thanks,
— Dale

> On Jan 4, 2018, at 2:25 AM, Christofer Dutz <christofer.d...@c-ware.de> wrote:
> 
> Hi Dale,
> 
> that’s unfortunate that you had that many problems … I have to admit that the 
> branch operation directly pushes was new to me … the prepare operation 
> shouldn’t and the perform should only checkout. BUT I do know that for all 
> the data in the scm management block of the pom is important. So, you should 
> have forked, updated the scm information to your fork and then executed the 
> operations. 
> 
> Regarding the questions, the plugin asks: 
> “new working copy version” refers to the version all poms will have after the 
> release. 
> 
> The main duties of the release:branch and release:prepare is to update the 
> version information. In all cases will the originating branch’s version be 
> updated to the new working copy version. Branch will create a branch without 
> updating any version information and prepare will update all versions to the 
> release version (without SNAPSHOT) and tag that in git before updating it 
> again to the “new working copy version”.
> 
> I thought these versions were self-explanatory, maybe I should elaborate a 
> little more on these.
> 
> Chris
> 
> 
> Am 03.01.18, 23:06 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
> 
>Hmm… 
> 
>per the releasing.adoc, I ran the release:branch step in a new clone of 
> the GitHub mirror repo (I neglected to clone the ASF repo) and it actually 
> auto-pushed 3 items to the ASF repo :-((when release:branch completed, 
> there were still two commits pending/not-yet-pushed as expected) 
> 
>I also neglected to “git checkout develop” so these auto-pushed commits 
> were to the master branch (though they netted to a no-op change) :-(
> 
>Lastly even after cleaning up (below) release/9.9 is still showing up in 
> the Branch pulldown of on the GitHub repo :-(  Filed 
> https://issues.apache.org/jira/browse/INFRA-15777 
> <https://issues.apache.org/jira/browse/INFRA-15777>
> 
>When I tried again with a fresh ASF repo clone and on the develop branch, 
> release:branch is prompting and I’m not sure what to reply with - don’t 
> understand what the “new working copy version” terminology is really 
> identifying.  Did you run with more -D options?   I’m guessing it’s asking 
> about what to advance the develop branch version to (for the next release), 
> and when you were doing the 1.2.0 release I’m guessing that you must have 
> replied/specified 1.3.0-SNAPSHOT?
> 
>@Dales-MacBook-Pro:604> git status
>On branch develop
>Your branch is up-to-date with 'origin/develop'.
>nothing to commit, working tree clean
>@Dales-MacBook-Pro:605> mvn release:branch -P 
> platform-android,platform-java7,distribution -DbranchName=release/9.9 
> -DautoVersionSubmodules=true
>…
>What is the new working copy version for "Apache Edgent"? 
> (org.apache.edgent:edgent-parent) 1.3.1-SNAPSHOT: :   
> 
> 
> 
>FYI, from my first botched release:branch run:
> 
>These 3 auto-pushed changes were now on master:
>   - commit of pom.xml on master (yikes) to change the scm-tag from 
> edgent-1.2.0 => release/9.9
>   - created the release/9.9 branch
>   - commit of pom.xml on master to undo the prior commit (scm-tag back to 
> edgent-1.2.0)
> 
>To cleanup I:
>   - deleted the release/9.9 branch locally and in the asf repo
>   Sadly, asf repo’s GitHub mirror still shows “release/9.9” in 
> its branch pulldown.
>   - “git reset —hard HEAD^^” followed by a “git push —force” to 
> essentially remove the above two commits on ma

FYI, GitHub mirror default branch changed to "develop"

[Dale LaBossiere]

It was changed via [1].  Presumably now when a pull request is created it will 
default to “develop” as the destination.
The insights page on GitHub now reports more useful commit info for 
“Contributors”.

> [1] https://issues.apache.org/jira/browse/INFRA-15780 
> 
— Dale

Re: reproducible release process

[Dale LaBossiere]

Hmm… 

per the releasing.adoc, I ran the release:branch step in a new clone of the 
GitHub mirror repo (I neglected to clone the ASF repo) and it actually 
auto-pushed 3 items to the ASF repo :-((when release:branch completed, 
there were still two commits pending/not-yet-pushed as expected) 

I also neglected to “git checkout develop” so these auto-pushed commits were to 
the master branch (though they netted to a no-op change) :-(

Lastly even after cleaning up (below) release/9.9 is still showing up in the 
Branch pulldown of on the GitHub repo :-(  Filed 
https://issues.apache.org/jira/browse/INFRA-15777 
<https://issues.apache.org/jira/browse/INFRA-15777>

When I tried again with a fresh ASF repo clone and on the develop branch, 
release:branch is prompting and I’m not sure what to reply with - don’t 
understand what the “new working copy version” terminology is really 
identifying.  Did you run with more -D options?   I’m guessing it’s asking 
about what to advance the develop branch version to (for the next release), and 
when you were doing the 1.2.0 release I’m guessing that you must have 
replied/specified 1.3.0-SNAPSHOT?

@Dales-MacBook-Pro:604> git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
nothing to commit, working tree clean
@Dales-MacBook-Pro:605> mvn release:branch -P 
platform-android,platform-java7,distribution -DbranchName=release/9.9 
-DautoVersionSubmodules=true
…
What is the new working copy version for "Apache Edgent"? 
(org.apache.edgent:edgent-parent) 1.3.1-SNAPSHOT: :   



FYI, from my first botched release:branch run:

These 3 auto-pushed changes were now on master:
- commit of pom.xml on master (yikes) to change the scm-tag from 
edgent-1.2.0 => release/9.9
- created the release/9.9 branch
- commit of pom.xml on master to undo the prior commit (scm-tag back to 
edgent-1.2.0)

To cleanup I:
- deleted the release/9.9 branch locally and in the asf repo
Sadly, asf repo’s GitHub mirror still shows “release/9.9” in 
its branch pulldown.
- “git reset —hard HEAD^^” followed by a “git push —force” to 
essentially remove the above two commits on master


> On Jan 3, 2018, at 2:20 PM, Christofer Dutz <christofer.d...@c-ware.de> wrote:
> 
> Hi Dale,
> 
> I think I did write down all the steps involving Maven in the document:
> 
> src/site/asciidoc/releasing.adoc
> 
> The merge with the other RM doc is that the release-perform will create the 
> source tar/zip we vote on in “target/checkout/target/***.tar.gz” and the 
> corresponding zip. The files should follow the exact naming convention used 
> to deploy it on the staging svn.
> 
> In the last release, I manually created the directory structure and checked 
> in the files. After that I used the existing scripts to deploy the voted-on 
> release to prod.
> 
> But it’s always good for others to try it too … and yes … it will do all the 
> steps without pushing (it will however create a Maven staging repo). The 
> staging repo is simply removed by a simple click and with the git repo, a 
> simple forced git reset should do the trick.
> 
> If you run into any problems, I’ll try to help as soon as possible.
> 
> Chris
> 
> 
> 
> 
> 
> 
> Am 03.01.18, 18:26 schrieb "Dale LaBossiere" <dlab...@apache.org>:
> 
>Hi Chris, 
> 
>At a high level, we need to ensure someone can reproduce what you just 
> went through for 1.2.0.
> 
>It feels like I should try going through the process for a, fictitious at 
> the moment, 1.3.0 release.  i.e., going all the way up to staging the release 
> in dist.apache.org and in Nexus (“Closing the staging repository”), then 
> cleaning that all up like it never happened (“Actions if the vote failed”, 
> plus removing the release/1.3 branch).  Does that make sense?  
> 
>As long as I don’t “git push” the created branch and pom-version-change 
> commits, is cleanup as easy as just destroying my repo-clone?
> 
>Looking at src/site/asciidoc/releasing.adoc, it looks pretty complete, 
> but...
> 
>In the vote-passed case, where’s the step / cmds to merge the release to 
> master?
> 
>In the vote-failed case, presumably the “fixes” are make on the release 
> branch, and the eventual “Prepare” redo with the same args does what’s 
> needed.  But where’s the step / (cherrypick?) cmds to get the fixes to the 
> develop branch? (imagine there are numerous commits for the fixes)
> 
>I’m also unclear on the flow for a bug fix release like 1.2.1.  Just make 
> the changes on the release/1.2 branch and BEGIN the process with “mvn 
> release:prepare … -tag edgent-1.2.1 -DdevelopmentVersion=1.2.2-SNAPSHOT 
> -DreleaseVersion=1.2.1”?  And again steps / (cherrypick?) cmds to get the 

reproducible release process

[Dale LaBossiere]

Hi Chris, 

At a high level, we need to ensure someone can reproduce what you just went 
through for 1.2.0.

It feels like I should try going through the process for a, fictitious at the 
moment, 1.3.0 release.  i.e., going all the way up to staging the release in 
dist.apache.org and in Nexus (“Closing the staging repository”), then cleaning 
that all up like it never happened (“Actions if the vote failed”, plus removing 
the release/1.3 branch).  Does that make sense?  

As long as I don’t “git push” the created branch and pom-version-change 
commits, is cleanup as easy as just destroying my repo-clone?

Looking at src/site/asciidoc/releasing.adoc, it looks pretty complete, but...

In the vote-passed case, where’s the step / cmds to merge the release to master?

In the vote-failed case, presumably the “fixes” are make on the release branch, 
and the eventual “Prepare” redo with the same args does what’s needed.  But 
where’s the step / (cherrypick?) cmds to get the fixes to the develop branch? 
(imagine there are numerous commits for the fixes)

I’m also unclear on the flow for a bug fix release like 1.2.1.  Just make the 
changes on the release/1.2 branch and BEGIN the process with “mvn 
release:prepare … -tag edgent-1.2.1 -DdevelopmentVersion=1.2.2-SNAPSHOT 
-DreleaseVersion=1.2.1”?  And again steps / (cherrypick?) cmds to get the 1.2.1 
fixes to the develop branch.

Once I can get through this I’ll update the RM-guide.  At least initially I’ll 
leave releasing.adoc as is (covering what it covers) and just update the 
RM-guide accordingly and link to it.  I don’t want to duplicate info and I 
don’t want to merge it into a single doc — unless you agree that migrating 
releasing.adoc content to the wiki (and removing releasing.adoc) is OK :-) 

— Dale

Re: [ANNOUNCE] Apache Edgent 1.2.0-incubating release

[Dale LaBossiere]

Thanks.  I’ve created the 1.2.0 and 1.3.0 releases on Jira and updated the 
issues (assigned fixed-in versions, transitioned many to “closed”).
Per the RM-guide (and apache policy) I also removed the superseded 
1.1.0-incubating from dist.apache.org.

> On Jan 2, 2018, at 12:02 PM, Christofer Dutz  
> wrote:
> 
> And I did take the liberty to fix the wiki … 
> 
> if you copied the announce list email from 
> https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager%27s+Guide 
> the mail got sent to annou...@anache.org ;-)
> 
> That’s fixed now :-)
> 
> Chris
> 
> 
> Am 02.01.18, 17:56 schrieb "Christofer Dutz" :
> 
>The Apache Edgent project is pleased to announce release 1.2.0-incubating!
> 
>Apache Edgent is a stream processing programming model and lightweight
>micro-kernel style runtime to execute analytics at devices on the edge or
>at the
>gateway.
> 
>Since the release of Apache Edgent 1.1.0 we have worked greatly on 
> improving
>the build. Not only in order to make it easier to release Edgent it also
>simplifies
>onboarding of new committers as well as using Apache Edgent. As an
>additional
>result of this effort now almost all artifacts are available as Java 8 but
>also as
>Java 7 and Android versions.
> 
>This is the first release of Apache Edgent to be built with Maven and 
> hereby
>provide all Edgent artifacts via the usual Maven distribution mechanisms.
> 
>Besides the build system changes, we have added a number of bug fixes and
>enhancements.
> 
>Starting with Apache Edgent 1.2.0 the samples have also been moved to a
>separate GIT repository [1]
> 
>Visit the Apache Edgent website [2] for general information or
>the downloads page [3] for release notes and download information.
> 
>Regards,
>The Apache Edgent team
> 
>[1] https://github.com/apache/incubator-edgent-samples.git
>[2] https://edgent.apache.org/
>[3] https://edgent.apache.org/docs/downloads.html
> 
> 

[jira] [Closed] (EDGENT-398) intermittent test failure Execution failed for task ':connectors:wsclient-javax.websocket:test'

[Dale LaBossiere (JIRA)]

 [ 
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.

Re: Buffering on the edge (network issues)

[Dale LaBossiere]

Related: for MQTT Connector see 
https://issues.apache.org/jira/browse/EDGENT-384 
<https://issues.apache.org/jira/browse/EDGENT-384>

Also forgot to mention PlumbingStreams.isolate()

pressureReliever(), isolate(), events(), and Windows all use in-memory 
buffering.

> On Jan 2, 2018, at 12:38 PM, Dale LaBossiere <dml.apa...@gmail.com> wrote:
> 
> Hi,
> 
> An Edgent stream is very light weight, it doesn’t have any inherent buffering 
> per-se.  The simple model is that the “next tuple” isn’t processed until 
> processing of the current tuple is complete — accepted by all its downstream 
> streams - ultimately by a “sink”.  i.e., downstream streams exert back 
> pressure on overall processing / upstream processing.
> 
> Window streams (used for aggregation) include buffering.
> PlumbingStreams.pressureReliever() [1] can be used to isolate upstream 
> processing from downstream streams (by adding a buffer).
> Use of Topology.events() [2], directly or more typically by a connector, adds 
> a buffer.
> 
> Individual connectors (typically the underlying 3rd party client library, 
> e.g., MQTT, Kafka) influence the behavior based on whether or not they 
> provide any internal buffering.  MQTT, and Edgent’s MQTT connector exposes 
> quality of service and persistence provider controls.
> 
> [1] 
> http://edgent.apache.org/javadoc/latest/org/apache/edgent/topology/plumbing/PlumbingStreams.html#pressureReliever-org.apache.edgent.topology.TStream-org.apache.edgent.function.Function-int-
>  
> <http://edgent.apache.org/javadoc/latest/org/apache/edgent/topology/plumbing/PlumbingStreams.html#pressureReliever-org.apache.edgent.topology.TStream-org.apache.edgent.function.Function-int->
> [2] 
> http://edgent.apache.org/javadoc/latest/org/apache/edgent/topology/Topology.html#events-org.apache.edgent.function.Consumer-
>  
> <http://edgent.apache.org/javadoc/latest/org/apache/edgent/topology/Topology.html#events-org.apache.edgent.function.Consumer->
> 
> Hope that helps,
> — Dale
> 
>> On Dec 29, 2017, at 4:41 PM, Otis Gospodnetić <otis.gospodne...@gmail.com 
>> <mailto:otis.gospodne...@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> I tried looking through the API and examples to see if there is Edgent has
>> any built-in buffering capabilities for when the sink cannot be reached for
>> whatever reason.  I couldn't find anything like that. Is that something
>> that one would have to write for each (new or custom) connector or is that
>> a part of the framework and I just missed it?
>> 
>> If I missed it, how is buffering implemented?
>> In-memory or on persistent media or some hybrid?
>> Can one define the max buffer capacity in terms of either number of items
>> or bytes?
>> If so, are the oldest items in the buffer dropped when the max capacity (or
>> their age) is reached?
>> 
>> Thanks,
>> Otis
>> --
>> Monitoring - Log Management - Alerting - Anomaly Detection
>> Solr & Elasticsearch Consulting Support Training - http://sematext.com/ 
>> <http://sematext.com/>
> 

[jira] [Closed] (EDGENT-242) desensitize IotProviderTest for timing

[Dale LaBossiere (JIRA)]

 [ 
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>

[Dale LaBossiere (JIRA)]

 [ 
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()

[Dale LaBossiere (JIRA)]

 [ 
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()

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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()

[Dale LaBossiere (JIRA)]

 [ 
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()

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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<JsonObject,JsonElement>}}.  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

[Dale LaBossiere (JIRA)]

 [ 
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<JsonObject,JsonElement>}}.  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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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?

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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()

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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"

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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

[Dale LaBossiere (JIRA)]

 [ 
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)

Re: Buffering on the edge (network issues)

[Dale LaBossiere]

Hi,

An Edgent stream is very light weight, it doesn’t have any inherent buffering 
per-se.  The simple model is that the “next tuple” isn’t processed until 
processing of the current tuple is complete — accepted by all its downstream 
streams - ultimately by a “sink”.  i.e., downstream streams exert back pressure 
on overall processing / upstream processing.

Window streams (used for aggregation) include buffering.
PlumbingStreams.pressureReliever() [1] can be used to isolate upstream 
processing from downstream streams (by adding a buffer).
Use of Topology.events() [2], directly or more typically by a connector, adds a 
buffer.

Individual connectors (typically the underlying 3rd party client library, e.g., 
MQTT, Kafka) influence the behavior based on whether or not they provide any 
internal buffering.  MQTT, and Edgent’s MQTT connector exposes quality of 
service and persistence provider controls.

[1] 
http://edgent.apache.org/javadoc/latest/org/apache/edgent/topology/plumbing/PlumbingStreams.html#pressureReliever-org.apache.edgent.topology.TStream-org.apache.edgent.function.Function-int-
 

[2] 
http://edgent.apache.org/javadoc/latest/org/apache/edgent/topology/Topology.html#events-org.apache.edgent.function.Consumer-
 


Hope that helps,
— Dale

> On Dec 29, 2017, at 4:41 PM, Otis Gospodnetić  
> wrote:
> 
> Hi,
> 
> I tried looking through the API and examples to see if there is Edgent has
> any built-in buffering capabilities for when the sink cannot be reached for
> whatever reason.  I couldn't find anything like that. Is that something
> that one would have to write for each (new or custom) connector or is that
> a part of the framework and I just missed it?
> 
> If I missed it, how is buffering implemented?
> In-memory or on persistent media or some hybrid?
> Can one define the max buffer capacity in terms of either number of items
> or bytes?
> If so, are the oldest items in the buffer dropped when the max capacity (or
> their age) is reached?
> 
> Thanks,
> Otis
> --
> Monitoring - Log Management - Alerting - Anomaly Detection
> Solr & Elasticsearch Consulting Support Training - http://sematext.com/

Re: [DRAFT] [ANNOUNCE] Apache Edgent 1.2.0-incubating release

[Dale LaBossiere]

Looks good. Thanks!

— Dale

> On Dec 28, 2017, at 9:00 AM, Christofer Dutz <christofer.d...@c-ware.de> 
> wrote:
> 
> Oh gee … I completely forgot about this … so here another go at it ;-)
> 
> 
> ---
> 
> The Apache Edgent project is pleased to announce release 1.2.0-incubating!
> 
> Apache Edgent is a stream processing programming model and lightweight 
> micro-kernel style runtime to execute analytics at devices on the edge or at 
> the 
> gateway.
> 
> Since the release of Apache Edgent 1.1.0 we have worked greatly on improving
> the build. Not only in order to make it easier to release Edgent it also 
> simplifies
> onboarding of new committers as well as using Apache Edgent. As an additional 
> result of this effort now almost all artifacts are available as Java 8 but 
> also as 
> Java 7 and Android versions.
> 
> This is the first release of Apache Edgent to be built with Maven and hereby
> provide all Edgent artifacts via the usual Maven distribution mechanisms.
> 
> But besides the build system changes, we have added a number of bug fixes and
> enhancements.
> 
> Starting with Apache Edgent 1.2.0 the samples have also been moved to a 
> separate GIT repository [1]
> 
> Visit the Apache Edgent website [2] for general information or
> the downloads page [3] for release notes and download information.
> 
> Regards,
> The Apache Edgent team
> 
> [1] https://github.com/apache/incubator-edgent-samples.git
> [2] https://edgent.apache.org/
> [3] https://edgent.apache.org/docs/downloads.html
> 
> 
> 
> 
> Am 18.12.17, 18:44 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
> 
>> On Dec 18, 2017, at 4:44 AM, Christofer Dutz <christofer.d...@c-ware.de> 
>> wrote:
>> Any comments to this? Or should I post this version?
> 
>It’s not bad but I’m trying to figure out how it might be improved:
>- add a statement capturing the theme of the release - to make it easier 
> to get started / create apps
>- also note the release includes a number of bug fixes and enhancements
>- maybe leave out the source-bundle-only comment
>- not sure how much to elaborate in the announcement text itself (e.g., 
> sample restructuring, template, packaging tools?)
>- not sure how important it is to say here that build tooling has been 
> changed to Maven
> 
>Maybe replace:
> 
>>   This is the first release of Apache Edgent to be built with Maven and 
>> hereby
>>   provide all Edgent artifacts via the usual Maven distribution mechanisms.
>> 
>>   The release includes only source bundles.
> 
> 
>With something like:
> 
>Release 1.2.0-incubating makes it easier for users to create Edgent 
> applications:
>- The release’s binary artifacts are now distributed via the usual Maven 
> distribution mechanisms
>- The samples were restructured and an application template project and 
> some application packaging tools have been added
>- There are bug fixes and other enhancements
> 
>Just at thought.  You’re the RM so you can decide :-)
> 
>— Dale
> 
> 
>> On Dec 18, 2017, at 4:44 AM, Christofer Dutz <christofer.d...@c-ware.de> 
>> wrote:
>> 
>> Any comments to this? Or should I post this version?
>> 
>> Chris
>> 
>> Am 14.12.17, 15:13 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
>> 
>>   The Apache Edgent project is pleased to announce release 1.2.0-incubating!
>> 
>>   Apache Edgent is a stream processing programming model and
>>   lightweight micro-kernel style runtime to execute analytics
>>   at devices on the edge or at the gateway.
>> 
>>   This is the first release of Apache Edgent to be built with Maven and 
>> hereby
>>   provide all Edgent artifacts via the usual Maven distribution mechanisms.
>> 
>>   The release includes only source bundles.
>> 
>>   Visit the Apache Edgent website [1] for general information or
>>   the downloads page [2] for release notes and download information.
>> 
>>   Regards,
>>   The Apache Edgent team
>> 
>>   [1] https://edgent.apache.org/
>>   [2] https://edgent.apache.org/docs/downloads.html
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 

Re: Edgent website update for 1.2.0

[Dale LaBossiere]

The live website now contains the 1.2.0 javadoc.

— Dale

> On Dec 15, 2017, at 3:14 PM, Dale LaBossiere <dlab...@apache.org> wrote:
> 
> FYI, the website updates for 1.2.0 are now live.
> 
> I’ll update the javadoc once that’s figured out.
> 
> In summary there are many updates:
> - updated Getting Started Guide
> - updated Downloads page
> - a new The Power of Edgent page
> - updated FAQ
> - a new Quickstart with Edgent Samples page
> - a new Edgent Application Development page
> 
> — Dale
> 
>> On Dec 14, 2017, at 3:27 PM, Dale LaBossiere <dlab...@apache.org> wrote:
>> 
>> Chris, thanks for pushing out the release!
>> 
>> I’m ready to update the website with PR-97 [1]
>> 
>> One thing that’s missing is the updated Javadoc.
>> I know it won’t work but for reference here’s the old process related to 
>> getting the releases javadoc onto the website [2]
>> And here’s what that javadoc looks like [3]
>> I can’t see to locate the analogous javadoc “index”/tree under the top level 
>> target after “mvn site:site site:stage”.  What’s the scoop?
>> 
>> [1] https://github.com/apache/incubator-edgent-website/pull/97 
>> <https://github.com/apache/incubator-edgent-website/pull/97>
>> [2] https://cwiki.apache.org/confluence/display/EDGENT/Updating+Javadocs 
>> <https://cwiki.apache.org/confluence/display/EDGENT/Updating+Javadocs>
>> [3] http://edgent.apache.org/javadoc/latest/index.html 
>> <http://edgent.apache.org/javadoc/latest/index.html>
>> 
>> — Dale
> 

Re: [DRAFT] [ANNOUNCE] Apache Edgent 1.2.0-incubating release

[Dale LaBossiere]

> On Dec 18, 2017, at 4:44 AM, Christofer Dutz  
> wrote:
> Any comments to this? Or should I post this version?

It’s not bad but I’m trying to figure out how it might be improved:
- add a statement capturing the theme of the release - to make it easier to get 
started / create apps
- also note the release includes a number of bug fixes and enhancements
- maybe leave out the source-bundle-only comment
- not sure how much to elaborate in the announcement text itself (e.g., sample 
restructuring, template, packaging tools?)
- not sure how important it is to say here that build tooling has been changed 
to Maven

Maybe replace:

>This is the first release of Apache Edgent to be built with Maven and 
> hereby
>provide all Edgent artifacts via the usual Maven distribution mechanisms.
> 
>The release includes only source bundles.


With something like:

Release 1.2.0-incubating makes it easier for users to create Edgent 
applications:
- The release’s binary artifacts are now distributed via the usual Maven 
distribution mechanisms
- The samples were restructured and an application template project and some 
application packaging tools have been added
- There are bug fixes and other enhancements

Just at thought.  You’re the RM so you can decide :-)

— Dale


> On Dec 18, 2017, at 4:44 AM, Christofer Dutz  
> wrote:
> 
> Any comments to this? Or should I post this version?
> 
> Chris
> 
> Am 14.12.17, 15:13 schrieb "Christofer Dutz" :
> 
>The Apache Edgent project is pleased to announce release 1.2.0-incubating!
> 
>Apache Edgent is a stream processing programming model and
>lightweight micro-kernel style runtime to execute analytics
>at devices on the edge or at the gateway.
> 
>This is the first release of Apache Edgent to be built with Maven and 
> hereby
>provide all Edgent artifacts via the usual Maven distribution mechanisms.
> 
>The release includes only source bundles.
> 
>Visit the Apache Edgent website [1] for general information or
>the downloads page [2] for release notes and download information.
> 
>Regards,
>The Apache Edgent team
> 
>[1] https://edgent.apache.org/
>[2] https://edgent.apache.org/docs/downloads.html
> 
> 
> 
> 
> 
> 

Edgent website update for 1.2.0

[Dale LaBossiere]

Chris, thanks for pushing out the release!

I’m ready to update the website with PR-97 [1]

One thing that’s missing is the updated Javadoc.
I know it won’t work but for reference here’s the old process related to 
getting the releases javadoc onto the website [2]
And here’s what that javadoc looks like [3]
I can’t see to locate the analogous javadoc “index”/tree under the top level 
target after “mvn site:site site:stage”.  What’s the scoop?

[1] https://github.com/apache/incubator-edgent-website/pull/97 

[2] https://cwiki.apache.org/confluence/display/EDGENT/Updating+Javadocs 

[3] http://edgent.apache.org/javadoc/latest/index.html 


— Dale

[jira] [Commented] (EDGENT-442) j7 connectors/websocket-jetty jar lacks META-INF/LICENSE,etc

[Dale LaBossiere (JIRA)]

[ 
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

[Dale LaBossiere (JIRA)]

[ 
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

[Dale LaBossiere (JIRA)]

[ 
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 (JIRA)]

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

[Dale LaBossiere (JIRA)]

[ 
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 (JIRA)]

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

[Dale LaBossiere (JIRA)]

[ 
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

[Dale LaBossiere (JIRA)]

 [ 
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)