date:20171206

Github user queeniema commented on a diff in the pull request:


https://github.com/apache/incubator-edgent-website/pull/97#discussion_r155388008
  
--- Diff: site/docs/power-of-edgent.md ---
@@ -0,0 +1,417 @@
+---
+title: The Power of Apache Edgent
+---
+
+Edgent is designed to accellerate your development of event driven 
flow-graph
+style analytic applications running on edge devices.  This is achieved by
+Edgent's combination of API, connectors, basic analytics, utilities, and 
openness!
+
+Let's have some fun with a shallow but broad view into what you
+can do in a few of lines of code... an introduction to Edgent's 
capabilities via
+a series of terse code fragments.
+
+See the [Getting Started Guide](edgent-getting-started) for a step by step 
introduction,
+and information about full samples and recipies.
+
+Let's start with a complete application that periodically samples a sensor
+and publishes its values to an Enterprise IoT Hub in less than 10 lines of 
code
+
+```java
+public class ImpressiveEdgentExample {
+  public static void main(String[] args) {
+DirectProvider provider = new DirectProvider();
+Topology top = provider.newTopology();
+
+IotDevice iotConnector = IotpDevice.quickstart(top, 
"edgent-intro-device-2");
+// open 
https://quickstart.internetofthings.ibmcloud.com/#/device/edgent-intro-device-2
+
+// ingest -> transform -> publish
+TStream readings = top.poll(new SimulatedTemperatureSensor(), 
1, TimeUnit.SECONDS);
+TStream events = 
readings.map(JsonFunctions.valueOfNumber("temp"));
+iotConnector.events(events, "readingEvents", QoS.FIRE_AND_FORGET);
+
+provider.submit(top);
+  }
+}
+```
+
+Ok, that was 11 lines and it omitted the imports, but there are only 7 
lines in main()!
+
+That leveraged the [IotpDevice]({{ site.docsurl 
}}/index.html?org/apache/{{ site.data.project.unix_name 
}}/connectors/iotp/IotpDevice.html)
+connector to the 
+IBM Watson IoT Platform and the platform's Quickstart feature. 
+The value of its Quickstart feature is no account or device 
+preregistration and the ability to open a browser to see the
+data being published.  Great to quickly get started.
+
+Hopefully that had enough of a wow factor to encourage you
+to keep reading!
+
+### Connectors, Ingest and Sink
+
+Edgent Applications need to create streams of data from external entities,
+termed ingest, and sink streams of data to external entities.  
+There are primitives for those operations and a collection of
+connectors to common external entities,
+more Connectors contributions are welcome!
+
+Connectors are just code that make it easier for an Edgent application
+to integrate with an external entity.  They use Edgent ingest primitives
+like (`Topology.poll()`, `Topology.events()`, etc), and `TStream.sink()`
+like any other Edgent code.  A connector may provide `Supplier` and 
+`Consumer` functions, for ingest and sink respectively, that an 
+application can use directly with the Edgent API.
+
+OK... fewer words, more code!
+
+You've already seen publishing using the `IotpDevice` connector.
+
+Want to receive [IotDevice]({{ site.docsurl }}/index.html?org/apache/{{ 
site.data.project.unix_name }}/connectors/iot/IotDevice.html) device commands? 
Simple!
+
+```java
+TStream cmds = iotConnector.commands();
+cmds.sink(cmd -> System.out.println("I should handle received cmd: 
"+cmd));
+
+or
+TStream xzyCmds = iotConnector.command("xyzCmds");
+```
+
+There's an [IotGateway]({{ site.docsurl }}/index.html?org/apache/{{ 
site.data.project.unix_name }}/connectors/iot/IotGateway.html) device model too.
+
+Don't want no stinkin `IotDevice` model and just
+want to pub/sub to an MQTT server?  No worries! Use the [MqttStreams]({{ 
site.docsurl }}/index.html?org/apache/{{ site.data.project.unix_name 
}}/connectors/mqtt/MqttStreams.html) connector
+
+```java
+//IotDevice iotConnector = IotpDevice.quickstart(top, 
"edgent-intro-device-2");
+MqttStreams iotConnector = new MqttStreams(top, 
"ssl://myMqttServer:8883", "my-device-client-id");
+
+...
+
+//iotConnector.events(events, "readingEvents", QoS.FIRE_AND_FORGET);
+iotConnector.publish(events, "readingEvents", QoS.FIRE_AND_FORGET, 
false);
+
+TStream xyzTopicMsgs = iotConnector.subscribe("xyzTopic");
+```
+
+Want to connect to Kafka?  Use the [KafkaProducer]({{ site.docsurl 
}}/index.html?org/apache/{{ site.data.project.unix_name 
}}/connectors/kafka/KafkaProducer.html) and [KafkaConsumer]({{ site.docsurl 
}}/index.html?org/apache/{{ site.data.project.unix_name

[GitHub] incubator-edgent-website pull request #97: [WIP] changes for Edgent PR-309 (...

Github user queeniema commented on a diff in the pull request:


https://github.com/apache/incubator-edgent-website/pull/97#discussion_r155387989
  
--- Diff: site/docs/power-of-edgent.md ---
@@ -0,0 +1,417 @@
+---
+title: The Power of Apache Edgent
+---
+
+Edgent is designed to accellerate your development of event driven 
flow-graph
--- End diff --

nit: "acce**l**lerate" --> "accelerate"


---

[GitHub] incubator-edgent-website pull request #97: [WIP] changes for Edgent PR-309 (...

Github user queeniema commented on a diff in the pull request:


https://github.com/apache/incubator-edgent-website/pull/97#discussion_r155386576
  
--- Diff: site/docs/faq.md ---
@@ -4,51 +4,74 @@ title: FAQ
 
 ## What is Apache Edgent?
 
-Edgent provides APIs and a lightweight runtime to analyze streaming data 
at the edge.
+Edgent provides APIs and a lightweight runtime enabling you to easily 
create event-driven flow-graph style applications to analyze streaming data at 
the edge.
+ Check out [The Power of Edgent](power-of-edgent) to help you guickly gain 
an appreciation of how Edgent can help you.
 
 ## What do you mean by the edge?
 
 The edge includes devices, gateways, equipment, vehicles, systems, 
appliances and sensors of all kinds as part of the Internet of Things.
 
-## How is Apache Edgent used?
+It's easy for for Edgent applications to connect to other entities such as 
an enterprise IoT hub.
 
-Edgent can be used at the edge of the Internet of Things, for example, to 
analyze data on devices, engines, connected cars, etc. Edgent could be on the 
device itself, or a gateway device collecting data from local devices. You can 
write an edge application on Edgent and connect it to a Cloud service, such as 
the IBM Watson IoT Platform. It can also be used for enterprise data collection 
and analysis; for example log collectors, application data, and data center 
analytics.
+While Edgent's design center is executing on constrained edge devices, 
Edgent applications can run on any system meeting minimal requirements such as 
a Java runtime.
 
 ## How are applications developed?
 
-Applications are developed using a functional flow API to define 
operations on data streams that are executed as a graph of "oplets" in a 
lightweight embeddable runtime. The SDK provides capabilities like windowing, 
aggregation and connectors with an extensible model for the community to expand 
its capabilities.
+Applications are developed using a functional flow API to define 
operations on data streams that are executed as a flow graph in a lightweight 
embeddable runtime. Edgent provides capabilities like windowing, aggregation 
and connectors with an extensible model for the community to expand its 
capabilities. Check out [The Power of Edgent](power-of-edgent)!
 
-## What APIs does Apache Edgent support?
+You can develop Edgent applications using an IDE of your choice. 
 
-Currently, Edgent supports APIs for Java and Android. Support for 
additional languages, such as Python, is likely as more developers get 
involved. Please consider joining the Edgent open source development community 
to accelerate the contributions of additional APIs.
+Generally, mechanisms for deploying an Edgent Application to a device are 
beyond the scope of Edgent; they are often device specific or may be defined by 
an enterprise IoT system.  To deploy an Edgent application to a device like a 
Raspberry Pi, you could just FTP the application to the device and modify the 
device to start the application upon startup or on command.   See [Edgent 
Application Development](application-development).
+
+## What environments does Apache Edgent support?
+
+Currently, Edgent provides APIs and runtime for Java and Android. Support 
for additional languages, such as Python, is likely as more developers get 
involved. Please consider joining the Edgent open source development community 
to accelerate the contributions of additional APIs.
 
 ## What type of analytics can be done with Apache Edgent?
 
-Edgent provides windowing, aggregation and simple filtering. It uses 
Apache Common Math to provide simple analytics aimed at device sensors. Edgent 
is also extensible, so you can call existing libraries from within your Edgent 
application. In the future, Edgent will include more analytics, either exposing 
more functionality from Apache Common Math, other libraries or hand-coded 
analytics.
+The core Edgent APIs makes it easy to incorporate any analytics you want 
into the stream processing graph. Its trivial to create windows and trigger 
aggregation functions you supply. It's trivial to specify whatever filtering 
and transformation functions you want to supply. The functions you supply can 
use existing libraries.
+
+Edgent comes with some initial analytics for aggregation and filtering 
that you may find useful. It uses Apache Common Math to provide simple 
analytics aimed at device sensors. In the future, Edgent will include more 
analytics, either exposing more functionality from Apache Common Math, other 
libraries or hand-coded analytics.
 
 ## What connectors does Apache Edgent support?
 
-Edgent supports connectors for MQTT, HTTP, JDBC, File, Apache Kafka and 
IBM Watson IoT Platform. Edgent is extensible; you can add the connector of 
your choice.
+Edgent

[GitHub] incubator-edgent-website pull request #97: [WIP] changes for Edgent PR-309 (...

Github user queeniema commented on a diff in the pull request:


https://github.com/apache/incubator-edgent-website/pull/97#discussion_r155386261
  
--- Diff: site/docs/faq.md ---
@@ -4,51 +4,74 @@ title: FAQ
 
 ## What is Apache Edgent?
 
-Edgent provides APIs and a lightweight runtime to analyze streaming data 
at the edge.
+Edgent provides APIs and a lightweight runtime enabling you to easily 
create event-driven flow-graph style applications to analyze streaming data at 
the edge.
+ Check out [The Power of Edgent](power-of-edgent) to help you guickly gain 
an appreciation of how Edgent can help you.
 
 ## What do you mean by the edge?
 
 The edge includes devices, gateways, equipment, vehicles, systems, 
appliances and sensors of all kinds as part of the Internet of Things.
 
-## How is Apache Edgent used?
+It's easy for for Edgent applications to connect to other entities such as 
an enterprise IoT hub.
 
-Edgent can be used at the edge of the Internet of Things, for example, to 
analyze data on devices, engines, connected cars, etc. Edgent could be on the 
device itself, or a gateway device collecting data from local devices. You can 
write an edge application on Edgent and connect it to a Cloud service, such as 
the IBM Watson IoT Platform. It can also be used for enterprise data collection 
and analysis; for example log collectors, application data, and data center 
analytics.
+While Edgent's design center is executing on constrained edge devices, 
Edgent applications can run on any system meeting minimal requirements such as 
a Java runtime.
 
 ## How are applications developed?
 
-Applications are developed using a functional flow API to define 
operations on data streams that are executed as a graph of "oplets" in a 
lightweight embeddable runtime. The SDK provides capabilities like windowing, 
aggregation and connectors with an extensible model for the community to expand 
its capabilities.
+Applications are developed using a functional flow API to define 
operations on data streams that are executed as a flow graph in a lightweight 
embeddable runtime. Edgent provides capabilities like windowing, aggregation 
and connectors with an extensible model for the community to expand its 
capabilities. Check out [The Power of Edgent](power-of-edgent)!
 
-## What APIs does Apache Edgent support?
+You can develop Edgent applications using an IDE of your choice. 
 
-Currently, Edgent supports APIs for Java and Android. Support for 
additional languages, such as Python, is likely as more developers get 
involved. Please consider joining the Edgent open source development community 
to accelerate the contributions of additional APIs.
+Generally, mechanisms for deploying an Edgent Application to a device are 
beyond the scope of Edgent; they are often device specific or may be defined by 
an enterprise IoT system.  To deploy an Edgent application to a device like a 
Raspberry Pi, you could just FTP the application to the device and modify the 
device to start the application upon startup or on command.   See [Edgent 
Application Development](application-development).
+
+## What environments does Apache Edgent support?
+
+Currently, Edgent provides APIs and runtime for Java and Android. Support 
for additional languages, such as Python, is likely as more developers get 
involved. Please consider joining the Edgent open source development community 
to accelerate the contributions of additional APIs.
 
 ## What type of analytics can be done with Apache Edgent?
 
-Edgent provides windowing, aggregation and simple filtering. It uses 
Apache Common Math to provide simple analytics aimed at device sensors. Edgent 
is also extensible, so you can call existing libraries from within your Edgent 
application. In the future, Edgent will include more analytics, either exposing 
more functionality from Apache Common Math, other libraries or hand-coded 
analytics.
+The core Edgent APIs makes it easy to incorporate any analytics you want 
into the stream processing graph. Its trivial to create windows and trigger 
aggregation functions you supply. It's trivial to specify whatever filtering 
and transformation functions you want to supply. The functions you supply can 
use existing libraries.
--- End diff --

nits: 
- "The core Edgent APIs make**s**" --> "The core Edgent APIs make"
- "Its trivial" --> "It's trivial"


---

[GitHub] incubator-edgent-website pull request #97: [WIP] changes for Edgent PR-309 (...

Github user queeniema commented on a diff in the pull request:


https://github.com/apache/incubator-edgent-website/pull/97#discussion_r155386271
  
--- Diff: site/docs/faq.md ---
@@ -4,51 +4,74 @@ title: FAQ
 
 ## What is Apache Edgent?
 
-Edgent provides APIs and a lightweight runtime to analyze streaming data 
at the edge.
+Edgent provides APIs and a lightweight runtime enabling you to easily 
create event-driven flow-graph style applications to analyze streaming data at 
the edge.
+ Check out [The Power of Edgent](power-of-edgent) to help you guickly gain 
an appreciation of how Edgent can help you.
 
 ## What do you mean by the edge?
 
 The edge includes devices, gateways, equipment, vehicles, systems, 
appliances and sensors of all kinds as part of the Internet of Things.
 
-## How is Apache Edgent used?
+It's easy for for Edgent applications to connect to other entities such as 
an enterprise IoT hub.
 
-Edgent can be used at the edge of the Internet of Things, for example, to 
analyze data on devices, engines, connected cars, etc. Edgent could be on the 
device itself, or a gateway device collecting data from local devices. You can 
write an edge application on Edgent and connect it to a Cloud service, such as 
the IBM Watson IoT Platform. It can also be used for enterprise data collection 
and analysis; for example log collectors, application data, and data center 
analytics.
+While Edgent's design center is executing on constrained edge devices, 
Edgent applications can run on any system meeting minimal requirements such as 
a Java runtime.
 
 ## How are applications developed?
 
-Applications are developed using a functional flow API to define 
operations on data streams that are executed as a graph of "oplets" in a 
lightweight embeddable runtime. The SDK provides capabilities like windowing, 
aggregation and connectors with an extensible model for the community to expand 
its capabilities.
+Applications are developed using a functional flow API to define 
operations on data streams that are executed as a flow graph in a lightweight 
embeddable runtime. Edgent provides capabilities like windowing, aggregation 
and connectors with an extensible model for the community to expand its 
capabilities. Check out [The Power of Edgent](power-of-edgent)!
 
-## What APIs does Apache Edgent support?
+You can develop Edgent applications using an IDE of your choice. 
 
-Currently, Edgent supports APIs for Java and Android. Support for 
additional languages, such as Python, is likely as more developers get 
involved. Please consider joining the Edgent open source development community 
to accelerate the contributions of additional APIs.
+Generally, mechanisms for deploying an Edgent Application to a device are 
beyond the scope of Edgent; they are often device specific or may be defined by 
an enterprise IoT system.  To deploy an Edgent application to a device like a 
Raspberry Pi, you could just FTP the application to the device and modify the 
device to start the application upon startup or on command.   See [Edgent 
Application Development](application-development).
+
+## What environments does Apache Edgent support?
+
+Currently, Edgent provides APIs and runtime for Java and Android. Support 
for additional languages, such as Python, is likely as more developers get 
involved. Please consider joining the Edgent open source development community 
to accelerate the contributions of additional APIs.
 
 ## What type of analytics can be done with Apache Edgent?
 
-Edgent provides windowing, aggregation and simple filtering. It uses 
Apache Common Math to provide simple analytics aimed at device sensors. Edgent 
is also extensible, so you can call existing libraries from within your Edgent 
application. In the future, Edgent will include more analytics, either exposing 
more functionality from Apache Common Math, other libraries or hand-coded 
analytics.
+The core Edgent APIs makes it easy to incorporate any analytics you want 
into the stream processing graph. Its trivial to create windows and trigger 
aggregation functions you supply. It's trivial to specify whatever filtering 
and transformation functions you want to supply. The functions you supply can 
use existing libraries.
+
+Edgent comes with some initial analytics for aggregation and filtering 
that you may find useful. It uses Apache Common Math to provide simple 
analytics aimed at device sensors. In the future, Edgent will include more 
analytics, either exposing more functionality from Apache Common Math, other 
libraries or hand-coded analytics.
 
 ## What connectors does Apache Edgent support?
 
-Edgent supports connectors for MQTT, HTTP, JDBC, File, Apache Kafka and 
IBM Watson IoT Platform. Edgent is extensible; you can add the connector of 
your choice.
+Edgent

[GitHub] incubator-edgent-website pull request #97: [WIP] changes for Edgent PR-309 (...

Github user queeniema commented on a diff in the pull request:


https://github.com/apache/incubator-edgent-website/pull/97#discussion_r155386244
  
--- Diff: site/docs/faq.md ---
@@ -4,51 +4,74 @@ title: FAQ
 
 ## What is Apache Edgent?
 
-Edgent provides APIs and a lightweight runtime to analyze streaming data 
at the edge.
+Edgent provides APIs and a lightweight runtime enabling you to easily 
create event-driven flow-graph style applications to analyze streaming data at 
the edge.
+ Check out [The Power of Edgent](power-of-edgent) to help you guickly gain 
an appreciation of how Edgent can help you.
 
 ## What do you mean by the edge?
 
 The edge includes devices, gateways, equipment, vehicles, systems, 
appliances and sensors of all kinds as part of the Internet of Things.
 
-## How is Apache Edgent used?
+It's easy for for Edgent applications to connect to other entities such as 
an enterprise IoT hub.
 
-Edgent can be used at the edge of the Internet of Things, for example, to 
analyze data on devices, engines, connected cars, etc. Edgent could be on the 
device itself, or a gateway device collecting data from local devices. You can 
write an edge application on Edgent and connect it to a Cloud service, such as 
the IBM Watson IoT Platform. It can also be used for enterprise data collection 
and analysis; for example log collectors, application data, and data center 
analytics.
+While Edgent's design center is executing on constrained edge devices, 
Edgent applications can run on any system meeting minimal requirements such as 
a Java runtime.
 
 ## How are applications developed?
 
-Applications are developed using a functional flow API to define 
operations on data streams that are executed as a graph of "oplets" in a 
lightweight embeddable runtime. The SDK provides capabilities like windowing, 
aggregation and connectors with an extensible model for the community to expand 
its capabilities.
+Applications are developed using a functional flow API to define 
operations on data streams that are executed as a flow graph in a lightweight 
embeddable runtime. Edgent provides capabilities like windowing, aggregation 
and connectors with an extensible model for the community to expand its 
capabilities. Check out [The Power of Edgent](power-of-edgent)!
 
-## What APIs does Apache Edgent support?
+You can develop Edgent applications using an IDE of your choice. 
 
-Currently, Edgent supports APIs for Java and Android. Support for 
additional languages, such as Python, is likely as more developers get 
involved. Please consider joining the Edgent open source development community 
to accelerate the contributions of additional APIs.
+Generally, mechanisms for deploying an Edgent Application to a device are 
beyond the scope of Edgent; they are often device specific or may be defined by 
an enterprise IoT system.  To deploy an Edgent application to a device like a 
Raspberry Pi, you could just FTP the application to the device and modify the 
device to start the application upon startup or on command.   See [Edgent 
Application Development](application-development).
--- End diff --

nit: "Edgent **A**pplication" --> "Edgent **a**pplication"


---

[GitHub] incubator-edgent pull request #329: expect staged .zip too and .sha512

2017-12-06 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-edgent/pull/329


---

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

Agreed on all points regarding the zip.  

Since you offered, I updated the scripts to require it and the sha512 noted 
below :-)
The verification includes verifying the tar.gz and zip contents are the same.

On another topic, [1] says the suffix MUST be sha512 for a SHA 512 sum (which 
in fact is what the file contains)
apache-edgent-1.2.0-incubating-source-release.tar.gz.sha1

So that needs be changed in the staging area in addition to staging the zip and 
its sums/sig.

Thanks!
— Dale

[1] http://www.apache.org/dev/release-distribution#sigs-and-sums

> On Dec 6, 2017, at 2:35 PM, Christofer Dutz  wrote:
> ...
> I just had a look at what the script was looking for. If releasing tar and 
> zip i think we would have to do the checking for both types. I can add the 
> other zip easily. But in that Case i would suggest adding that to the script 
> and add one check to make sure the content is identical. Would be good If we 
> could be sure we need to detail-check only one.
> ...
> From: Dale LaBossiere 
> ...
> -Papache-release also generates a zip.  I had expected we’d be releasing that 
> too but it isn’t staged.
> At this time I’m fine if we just continue 1.2.0 with only the tar.gz but if 
> you also want to stage the zip that's fine too.
> 
> I just need to know which way we’re going because I need to adjust the 
> “downloads” website page accordingly.

[GitHub] incubator-edgent pull request #329: expect staged .zip too and .sha512

2017-12-06 Thread dlaboss

GitHub user dlaboss opened a pull request:

https://github.com/apache/incubator-edgent/pull/329

expect staged .zip too and .sha512



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dlaboss/incubator-edgent 
include-zip-and-sha512

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-edgent/pull/329.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #329






---

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

2017-12-06 Thread Justin Mclean

Hi,

> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm No 
> expert on that. My key should be valid judging from the number of Apaches 
> that signed it. Eventually there is no path of trust and you need to import 
> it manually.

The warning is fine - it just means that Chis is not in Dale’s web of trust. 
I’d assume Dale has not gone to an ASF key signing party.

The important part is that it is a good signature and it’s signed by an 
apache.org email.

Thanks,
Justin

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

Hi Dale,

I just had a look at what the script was looking for. If releasing tar and zip 
i think we would have to do the checking for both types. I can add the other 
zip easily. But in that Case i would suggest adding that to the script and add 
one check to make sure the content is identical. Would be good If we could be 
sure we need to detail-check only one.

Chris

Outlook for Android herunterladen


From: Dale LaBossiere 
Sent: Wednesday, December 6, 2017 7:28:11 PM
To: dev@edgent.apache.org
Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

I’ll pull of that trust thread, thx.

Another question re RC1:

-Papache-release also generates a zip.  I had expected we’d be releasing that 
too but it isn’t staged.
At this time I’m fine if we just continue 1.2.0 with only the tar.gz but if you 
also want to stage the zip that's fine too.

I just need to know which way we’re going because I need to adjust the 
“downloads” website page accordingly.

— Dale

> On Dec 6, 2017, at 11:46 AM, Christofer Dutz  
> wrote:
>
> I think in the gpg GUI Tool you also have to explicitly "trust" a Key. 
> Otherwise its Just a Key.
>
> Chris
>
> Outlook for Android herunterladen
>
> 
> From: Dale LaBossiere 
> Sent: Wednesday, December 6, 2017 5:31:03 PM
> To: dev@edgent.apache.org
> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
>
> I hear your pain :-)
>
> FWIW, I did import your key using the (possibly incomplete?) directions 
> reported by the script.
> That’s why I was wondering if you saw the same thing for 1.2.0 and 1.1.0.
>
> I did what it told me to below when it failed the 1st time I ran it.
> buildTools/download_edgent_asf.sh —validate 1.2.0 1
> ...
> If the following bundle gpg signature checks fail, you may need to
> import the project's list of signing keys to your keyring
>$ gpg downloaded-edgent-1.2.0rc1/KEYS# show the included keys
>$ gpg --import downloaded-edgent-1.2.0rc1/KEYS
> …
>
>
>> On Dec 6, 2017, at 11:24 AM, Christofer Dutz  
>> wrote:
>>
>> Hi Dale,
>>
>> I'm still on the task of manually deleting Things. Will continue tomorrow. 
>> Have to manually delete at least 4 Files for every artifact one at a time :-(
>>
>> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm 
>> No expert on that. My key should be valid judging from the number of Apaches 
>> that signed it. Eventually there is no path of trust and you need to import 
>> it manually.
>>
>> Chris
>>
>> Outlook for Android herunterladen
>>
>> 
>> From: Dale LaBossiere 
>> Sent: Wednesday, December 6, 2017 5:08:27 PM
>> To: dev@edgent.apache.org
>> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
>>
>> Thx re the nexus content.
>>
>> I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I 
>> don’t
>> get when downloading/validating 1.1.0.
>> Might your KEY changes have an issue or you didn’t “published” your key or 
>> such?
>> Or maybe it’s just that with 1.1.0 I’m just validating something that I 
>> signed
>> to it doesn’t complain for me?
>>
>> Do you get the WARNING below when you
>> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
>>
>> Do you get the WARNING if for 1.1.0?
>> Using the *master* branch for the script:
>> buildTools/download_edgent_asf.sh  —validate 1.1.0
>>
>> When I run
>> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
>> ...
>> Verifying the source bundle signatures...
>> + /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
>> 1.2.0-incubating/rc1
>>
>> Checking 
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz 
>> MD5 OK
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz 
>> SHA OK
>> gpg: assuming signed data in 
>> '1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
>> gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
>> gpg: Good signature from "Christofer Dutz (Apache Comitter) 
>> " [unknown]
>> gpg: aka "[jpeg image of size 272202]" [unknown]
>> gpg: WARNING: This key is not certified with a trusted signature!
>> gpg:  There is no indication that the signature belongs to the owner.
>> Primary key fingerprint: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9
>>
>> — Dale
>>
>>> On Dec 6, 2017, at 10:44 AM, Christofer Dutz  
>>> wrote:
>>>
>>> Hi Dale,
>>>
>>> I guess I updated the KEY manually and it seems to be ok the way it is now.
>>>
>>> Regarding stuff in Nexus, we should remove before hitting the “release” 
>>> button:
>>> -

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

I’ll pull of that trust thread, thx.

Another question re RC1:

-Papache-release also generates a zip.  I had expected we’d be releasing that 
too but it isn’t staged.
At this time I’m fine if we just continue 1.2.0 with only the tar.gz but if you 
also want to stage the zip that's fine too.

I just need to know which way we’re going because I need to adjust the 
“downloads” website page accordingly.

— Dale

> On Dec 6, 2017, at 11:46 AM, Christofer Dutz  
> wrote:
> 
> I think in the gpg GUI Tool you also have to explicitly "trust" a Key. 
> Otherwise its Just a Key.
> 
> Chris
> 
> Outlook for Android herunterladen
> 
> 
> From: Dale LaBossiere 
> Sent: Wednesday, December 6, 2017 5:31:03 PM
> To: dev@edgent.apache.org
> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
> 
> I hear your pain :-)
> 
> FWIW, I did import your key using the (possibly incomplete?) directions 
> reported by the script.
> That’s why I was wondering if you saw the same thing for 1.2.0 and 1.1.0.
> 
> I did what it told me to below when it failed the 1st time I ran it.
> buildTools/download_edgent_asf.sh —validate 1.2.0 1
> ...
> If the following bundle gpg signature checks fail, you may need to
> import the project's list of signing keys to your keyring
>$ gpg downloaded-edgent-1.2.0rc1/KEYS# show the included keys
>$ gpg --import downloaded-edgent-1.2.0rc1/KEYS
> …
> 
> 
>> On Dec 6, 2017, at 11:24 AM, Christofer Dutz  
>> wrote:
>> 
>> Hi Dale,
>> 
>> I'm still on the task of manually deleting Things. Will continue tomorrow. 
>> Have to manually delete at least 4 Files for every artifact one at a time :-(
>> 
>> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm 
>> No expert on that. My key should be valid judging from the number of Apaches 
>> that signed it. Eventually there is no path of trust and you need to import 
>> it manually.
>> 
>> Chris
>> 
>> Outlook for Android herunterladen
>> 
>> 
>> From: Dale LaBossiere 
>> Sent: Wednesday, December 6, 2017 5:08:27 PM
>> To: dev@edgent.apache.org
>> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
>> 
>> Thx re the nexus content.
>> 
>> I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I 
>> don’t
>> get when downloading/validating 1.1.0.
>> Might your KEY changes have an issue or you didn’t “published” your key or 
>> such?
>> Or maybe it’s just that with 1.1.0 I’m just validating something that I 
>> signed
>> to it doesn’t complain for me?
>> 
>> Do you get the WARNING below when you
>> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
>> 
>> Do you get the WARNING if for 1.1.0?
>> Using the *master* branch for the script:
>> buildTools/download_edgent_asf.sh  —validate 1.1.0
>> 
>> When I run
>> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
>> ...
>> Verifying the source bundle signatures...
>> + /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
>> 1.2.0-incubating/rc1
>> 
>> Checking 
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz 
>> MD5 OK
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz 
>> SHA OK
>> gpg: assuming signed data in 
>> '1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
>> gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
>> gpg: Good signature from "Christofer Dutz (Apache Comitter) 
>> " [unknown]
>> gpg: aka "[jpeg image of size 272202]" [unknown]
>> gpg: WARNING: This key is not certified with a trusted signature!
>> gpg:  There is no indication that the signature belongs to the owner.
>> Primary key fingerprint: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9
>> 
>> — Dale
>> 
>>> On Dec 6, 2017, at 10:44 AM, Christofer Dutz  
>>> wrote:
>>> 
>>> Hi Dale,
>>> 
>>> I guess I updated the KEY manually and it seems to be ok the way it is now.
>>> 
>>> Regarding stuff in Nexus, we should remove before hitting the “release” 
>>> button:
>>> - Intermediate poms are important as they are defined as “parent” of other 
>>> artifacts. Maven downloads them in order to know the entire modules pom, if 
>>> we omit the intermediate poms, all is broken. This is especially true for 
>>> the edgent-parent pom.
>>> - Yes, we should remove:
>>> o Distributions
>>> o Test-Jars
>>> o Source-Release archives
>>> (I’ll see if I can manually remove them otherwise, I would drop the staging 
>>> repo … re-do the staging of the maven artifacts and then manually delete 
>>> them before closing the repo)
>>> - First thing we should then do in develop for 1.3.0 is to fine tune the

[GitHub] incubator-edgent pull request #328: Fix JAVA_SUPPORT.md markdown

2017-12-06 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-edgent/pull/328


---

[GitHub] incubator-edgent pull request #328: Fix JAVA_SUPPORT.md markdown

2017-12-06 Thread dlaboss

GitHub user dlaboss opened a pull request:

https://github.com/apache/incubator-edgent/pull/328

Fix JAVA_SUPPORT.md markdown

fix `` portion of jar name not getting rendered

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dlaboss/incubator-edgent java-support-markdown

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-edgent/pull/328.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #328


commit 7ccda01b76fd8427d87108e863a3e8a5e8ddfa5e
Author: Dale LaBossiere 
Date:   2017-12-06T16:48:58Z

Fix JAVA_SUPPORT.md markdown




---

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

I think in the gpg GUI Tool you also have to explicitly "trust" a Key. 
Otherwise its Just a Key.

Chris

Outlook for Android herunterladen


From: Dale LaBossiere 
Sent: Wednesday, December 6, 2017 5:31:03 PM
To: dev@edgent.apache.org
Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

I hear your pain :-)

FWIW, I did import your key using the (possibly incomplete?) directions 
reported by the script.
That’s why I was wondering if you saw the same thing for 1.2.0 and 1.1.0.

I did what it told me to below when it failed the 1st time I ran it.
buildTools/download_edgent_asf.sh —validate 1.2.0 1
...
If the following bundle gpg signature checks fail, you may need to
import the project's list of signing keys to your keyring
$ gpg downloaded-edgent-1.2.0rc1/KEYS# show the included keys
$ gpg --import downloaded-edgent-1.2.0rc1/KEYS
…


> On Dec 6, 2017, at 11:24 AM, Christofer Dutz  
> wrote:
>
> Hi Dale,
>
> I'm still on the task of manually deleting Things. Will continue tomorrow. 
> Have to manually delete at least 4 Files for every artifact one at a time :-(
>
> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm No 
> expert on that. My key should be valid judging from the number of Apaches 
> that signed it. Eventually there is no path of trust and you need to import 
> it manually.
>
> Chris
>
> Outlook for Android herunterladen
>
> 
> From: Dale LaBossiere 
> Sent: Wednesday, December 6, 2017 5:08:27 PM
> To: dev@edgent.apache.org
> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
>
> Thx re the nexus content.
>
> I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I 
> don’t
> get when downloading/validating 1.1.0.
> Might your KEY changes have an issue or you didn’t “published” your key or 
> such?
> Or maybe it’s just that with 1.1.0 I’m just validating something that I signed
> to it doesn’t complain for me?
>
> Do you get the WARNING below when you
> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
>
> Do you get the WARNING if for 1.1.0?
> Using the *master* branch for the script:
> buildTools/download_edgent_asf.sh  —validate 1.1.0
>
> When I run
> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
> ...
> Verifying the source bundle signatures...
> + /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
> 1.2.0-incubating/rc1
>
> Checking 
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz MD5 
> OK
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz SHA 
> OK
> gpg: assuming signed data in 
> '1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
> gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
> gpg: Good signature from "Christofer Dutz (Apache Comitter) 
> " [unknown]
> gpg: aka "[jpeg image of size 272202]" [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the owner.
> Primary key fingerprint: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9
>
> — Dale
>
>> On Dec 6, 2017, at 10:44 AM, Christofer Dutz  
>> wrote:
>>
>> Hi Dale,
>>
>> I guess I updated the KEY manually and it seems to be ok the way it is now.
>>
>> Regarding stuff in Nexus, we should remove before hitting the “release” 
>> button:
>> - Intermediate poms are important as they are defined as “parent” of other 
>> artifacts. Maven downloads them in order to know the entire modules pom, if 
>> we omit the intermediate poms, all is broken. This is especially true for 
>> the edgent-parent pom.
>> - Yes, we should remove:
>> o Distributions
>> o Test-Jars
>> o Source-Release archives
>> (I’ll see if I can manually remove them otherwise, I would drop the staging 
>> repo … re-do the staging of the maven artifacts and then manually delete 
>> them before closing the repo)
>> - First thing we should then do in develop for 1.3.0 is to fine tune the 
>> maven-deploy-plugin to only deploy stuff we want it to.
>>
>> Chris
>>
>>
>>
>> Am 06.12.17, 16:32 schrieb "Dale LaBossiere" :
>>
>>
>>   Re the KEYS, please update the file in the incubator-edgent source repo.
>>
>>   FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing 
>> the release”
>>   process is supposed to *move* the exact staged/voted artifacts to the 
>> release area.
>>   I see the our buildTools/publish_release.sh script doesn’t bother to 
>> delete the
>>   residual staged  dir.
>>
>>   In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS 
>> in the
>>   “release” area (from

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

I hear your pain :-)

FWIW, I did import your key using the (possibly incomplete?) directions 
reported by the script.
That’s why I was wondering if you saw the same thing for 1.2.0 and 1.1.0.

I did what it told me to below when it failed the 1st time I ran it.
buildTools/download_edgent_asf.sh —validate 1.2.0 1
...
If the following bundle gpg signature checks fail, you may need to
import the project's list of signing keys to your keyring
$ gpg downloaded-edgent-1.2.0rc1/KEYS# show the included keys
$ gpg --import downloaded-edgent-1.2.0rc1/KEYS
…


> On Dec 6, 2017, at 11:24 AM, Christofer Dutz  
> wrote:
> 
> Hi Dale,
> 
> I'm still on the task of manually deleting Things. Will continue tomorrow. 
> Have to manually delete at least 4 Files for every artifact one at a time :-(
> 
> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm No 
> expert on that. My key should be valid judging from the number of Apaches 
> that signed it. Eventually there is no path of trust and you need to import 
> it manually.
> 
> Chris
> 
> Outlook for Android herunterladen
> 
> 
> From: Dale LaBossiere 
> Sent: Wednesday, December 6, 2017 5:08:27 PM
> To: dev@edgent.apache.org
> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
> 
> Thx re the nexus content.
> 
> I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I 
> don’t
> get when downloading/validating 1.1.0.
> Might your KEY changes have an issue or you didn’t “published” your key or 
> such?
> Or maybe it’s just that with 1.1.0 I’m just validating something that I signed
> to it doesn’t complain for me?
> 
> Do you get the WARNING below when you
> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
> 
> Do you get the WARNING if for 1.1.0?
> Using the *master* branch for the script:
> buildTools/download_edgent_asf.sh  —validate 1.1.0
> 
> When I run
> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
> ...
> Verifying the source bundle signatures...
> + /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
> 1.2.0-incubating/rc1
> 
> Checking 
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz MD5 
> OK
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz SHA 
> OK
> gpg: assuming signed data in 
> '1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
> gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
> gpg: Good signature from "Christofer Dutz (Apache Comitter) 
> " [unknown]
> gpg: aka "[jpeg image of size 272202]" [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the owner.
> Primary key fingerprint: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9
> 
> — Dale
> 
>> On Dec 6, 2017, at 10:44 AM, Christofer Dutz  
>> wrote:
>> 
>> Hi Dale,
>> 
>> I guess I updated the KEY manually and it seems to be ok the way it is now.
>> 
>> Regarding stuff in Nexus, we should remove before hitting the “release” 
>> button:
>> - Intermediate poms are important as they are defined as “parent” of other 
>> artifacts. Maven downloads them in order to know the entire modules pom, if 
>> we omit the intermediate poms, all is broken. This is especially true for 
>> the edgent-parent pom.
>> - Yes, we should remove:
>> o Distributions
>> o Test-Jars
>> o Source-Release archives
>> (I’ll see if I can manually remove them otherwise, I would drop the staging 
>> repo … re-do the staging of the maven artifacts and then manually delete 
>> them before closing the repo)
>> - First thing we should then do in develop for 1.3.0 is to fine tune the 
>> maven-deploy-plugin to only deploy stuff we want it to.
>> 
>> Chris
>> 
>> 
>> 
>> Am 06.12.17, 16:32 schrieb "Dale LaBossiere" :
>> 
>> 
>>   Re the KEYS, please update the file in the incubator-edgent source repo.
>> 
>>   FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing 
>> the release”
>>   process is supposed to *move* the exact staged/voted artifacts to the 
>> release area.
>>   I see the our buildTools/publish_release.sh script doesn’t bother to 
>> delete the
>>   residual staged  dir.
>> 
>>   In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS 
>> in the
>>   “release” area (from the “dev” area) so that will be taken care of 
>> automatically if the script is used.
>>   It looks like it should work without any changes.
>> 
>>   Agreed, no need to cancel the RC1 vote at this moment since as you note,
>>   the RC1 source content hasn’t changed.  And generally, updating the 
>> poms,etc
>>   for “what’s released” is OK to not include in

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

Hi Dale,

I'm still on the task of manually deleting Things. Will continue tomorrow. Have 
to manually delete at least 4 Files for every artifact one at a time :-(

Regarding the pgp issue i guess you have to Import my Key somehow. But i'm No 
expert on that. My key should be valid judging from the number of Apaches that 
signed it. Eventually there is no path of trust and you need to import it 
manually.

Chris

Outlook for Android herunterladen

From: Dale LaBossiere 
Sent: Wednesday, December 6, 2017 5:08:27 PM
To: dev@edgent.apache.org
Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

Thx re the nexus content.

I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I don’t
get when downloading/validating 1.1.0.
Might your KEY changes have an issue or you didn’t “published” your key or such?
Or maybe it’s just that with 1.1.0 I’m just validating something that I signed
to it doesn’t complain for me?

Do you get the WARNING below when you
buildTools/download_edgent_asf.sh  —validate 1.2.0 1

Do you get the WARNING if for 1.1.0?
Using the *master* branch for the script:
buildTools/download_edgent_asf.sh  —validate 1.1.0

When I run
buildTools/download_edgent_asf.sh  —validate 1.2.0 1
...
Verifying the source bundle signatures...
+ /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
1.2.0-incubating/rc1

Checking 
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz MD5 OK
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz SHA OK
gpg: assuming signed data in 
'1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
gpg: Good signature from "Christofer Dutz (Apache Comitter) " 
[unknown]
gpg: aka "[jpeg image of size 272202]" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9

— Dale

> On Dec 6, 2017, at 10:44 AM, Christofer Dutz  
> wrote:
>
> Hi Dale,
>
> I guess I updated the KEY manually and it seems to be ok the way it is now.
>
> Regarding stuff in Nexus, we should remove before hitting the “release” 
> button:
> - Intermediate poms are important as they are defined as “parent” of other 
> artifacts. Maven downloads them in order to know the entire modules pom, if 
> we omit the intermediate poms, all is broken. This is especially true for the 
> edgent-parent pom.
> - Yes, we should remove:
> o Distributions
> o Test-Jars
> o Source-Release archives
> (I’ll see if I can manually remove them otherwise, I would drop the staging 
> repo … re-do the staging of the maven artifacts and then manually delete them 
> before closing the repo)
> - First thing we should then do in develop for 1.3.0 is to fine tune the 
> maven-deploy-plugin to only deploy stuff we want it to.
>
> Chris
>
>
>
> Am 06.12.17, 16:32 schrieb "Dale LaBossiere" :
>
>
>Re the KEYS, please update the file in the incubator-edgent source repo.
>
>FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing 
> the release”
>process is supposed to *move* the exact staged/voted artifacts to the 
> release area.
>I see the our buildTools/publish_release.sh script doesn’t bother to 
> delete the
>residual staged  dir.
>
>In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS 
> in the
>“release” area (from the “dev” area) so that will be taken care of 
> automatically if the script is used.
>It looks like it should work without any changes.
>
>Agreed, no need to cancel the RC1 vote at this moment since as you note,
>the RC1 source content hasn’t changed.  And generally, updating the 
> poms,etc
>for “what’s released” is OK to not include in the 1.2.0 source release.  
> But...
>
>I think some things MUST get removed from Nexus for 1.2.0.  Do you agree?
>  - edgent-distribution (for j8,j7,android)
>  - edgent-parent/*source-release* - or edgent-parent in its entirety?  
> (for j8,j7,android)
>  - …/*-1.2.0-tests.*   (for j8,j7,android)
>  - edgent-test* (for j8,j7)
>  - what about “pom-only” intermediate dirs - will those show up in MC? 
> Are they useful?
>- edgent-analytics
>- edgent-android
>- edgent-api
>...
>
>
>> On Dec 6, 2017, at 4:00 AM, Christofer Dutz  
>> wrote:
>>
>> Hi Dale,
>>
>> So, I updated the scripts, deployed the RC in the correct area (I wonder why 
>> the other 1.0.0 and 1.1.0 areas are empty. Unfortunately, I had to test 
>> myself to the right solution by running

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

Thx re the nexus content.

I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I don’t
get when downloading/validating 1.1.0.
Might your KEY changes have an issue or you didn’t “published” your key or such?
Or maybe it’s just that with 1.1.0 I’m just validating something that I signed
to it doesn’t complain for me?

Do you get the WARNING below when you
buildTools/download_edgent_asf.sh  —validate 1.2.0 1

Do you get the WARNING if for 1.1.0?
Using the *master* branch for the script:
buildTools/download_edgent_asf.sh  —validate 1.1.0

When I run
buildTools/download_edgent_asf.sh  —validate 1.2.0 1
...
Verifying the source bundle signatures...
+ /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
1.2.0-incubating/rc1

Checking 
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz MD5 OK
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz SHA OK
gpg: assuming signed data in 
'1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
gpg: Good signature from "Christofer Dutz (Apache Comitter) " 
[unknown]
gpg: aka "[jpeg image of size 272202]" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9

— Dale

> On Dec 6, 2017, at 10:44 AM, Christofer Dutz  
> wrote:
> 
> Hi Dale,
> 
> I guess I updated the KEY manually and it seems to be ok the way it is now.
> 
> Regarding stuff in Nexus, we should remove before hitting the “release” 
> button:
> - Intermediate poms are important as they are defined as “parent” of other 
> artifacts. Maven downloads them in order to know the entire modules pom, if 
> we omit the intermediate poms, all is broken. This is especially true for the 
> edgent-parent pom.
> - Yes, we should remove:
> o Distributions
> o Test-Jars
> o Source-Release archives
> (I’ll see if I can manually remove them otherwise, I would drop the staging 
> repo … re-do the staging of the maven artifacts and then manually delete them 
> before closing the repo)
> - First thing we should then do in develop for 1.3.0 is to fine tune the 
> maven-deploy-plugin to only deploy stuff we want it to.
> 
> Chris
> 
> 
> 
> Am 06.12.17, 16:32 schrieb "Dale LaBossiere" :
> 
> 
>Re the KEYS, please update the file in the incubator-edgent source repo.
> 
>FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing 
> the release”
>process is supposed to *move* the exact staged/voted artifacts to the 
> release area.
>I see the our buildTools/publish_release.sh script doesn’t bother to 
> delete the
>residual staged  dir.
> 
>In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS 
> in the
>“release” area (from the “dev” area) so that will be taken care of 
> automatically if the script is used.
>It looks like it should work without any changes.
> 
>Agreed, no need to cancel the RC1 vote at this moment since as you note, 
>the RC1 source content hasn’t changed.  And generally, updating the 
> poms,etc
>for “what’s released” is OK to not include in the 1.2.0 source release.  
> But...
> 
>I think some things MUST get removed from Nexus for 1.2.0.  Do you agree?
>  - edgent-distribution (for j8,j7,android)
>  - edgent-parent/*source-release* - or edgent-parent in its entirety?  
> (for j8,j7,android)
>  - …/*-1.2.0-tests.*   (for j8,j7,android)
>  - edgent-test* (for j8,j7)
>  - what about “pom-only” intermediate dirs - will those show up in MC? 
> Are they useful?
>- edgent-analytics
>- edgent-android
>- edgent-api
>...
> 
> 
>> On Dec 6, 2017, at 4:00 AM, Christofer Dutz  
>> wrote:
>> 
>> Hi Dale,
>> 
>> So, I updated the scripts, deployed the RC in the correct area (I wonder why 
>> the other 1.0.0 and 1.1.0 areas are empty. Unfortunately, I had to test 
>> myself to the right solution by running the scripts and fine tuning my 
>> deployment and the scripts. But now I think we have a working solution. As 
>> nothing had to be changed with the source-bundle itself, I don’t think we 
>> need to cancel the RC and create a new one. What do you others think?
>> 
>> Chris
>> 
>> 
>> Am 06.12.17, 09:10 schrieb "Christofer Dutz" :
>> 
>>   HI Dale,
>> 
>>   as I mentioned in the other DISCUSS thread I already noticed this 
>> shortcoming. 
>>   I think the following path should be ok for us to follow:
>> 
>>   1. I manually add my pgp key to the list in KEYS in SVN
>>   2. I manually add the files created by the assembly plugin to SVN
>>   3.

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

Hi Dale,

I guess I updated the KEY manually and it seems to be ok the way it is now.

Regarding stuff in Nexus, we should remove before hitting the “release” button:
- Intermediate poms are important as they are defined as “parent” of other 
artifacts. Maven downloads them in order to know the entire modules pom, if we 
omit the intermediate poms, all is broken. This is especially true for the 
edgent-parent pom.
- Yes, we should remove:
o Distributions
o Test-Jars
o Source-Release archives
(I’ll see if I can manually remove them otherwise, I would drop the staging 
repo … re-do the staging of the maven artifacts and then manually delete them 
before closing the repo)
- First thing we should then do in develop for 1.3.0 is to fine tune the 
maven-deploy-plugin to only deploy stuff we want it to.

Chris



Am 06.12.17, 16:32 schrieb "Dale LaBossiere" :


Re the KEYS, please update the file in the incubator-edgent source repo.

FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing 
the release”
process is supposed to *move* the exact staged/voted artifacts to the 
release area.
I see the our buildTools/publish_release.sh script doesn’t bother to delete 
the
residual staged  dir.

In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS 
in the
“release” area (from the “dev” area) so that will be taken care of 
automatically if the script is used.
It looks like it should work without any changes.

Agreed, no need to cancel the RC1 vote at this moment since as you note, 
the RC1 source content hasn’t changed.  And generally, updating the poms,etc
for “what’s released” is OK to not include in the 1.2.0 source release.  
But...

I think some things MUST get removed from Nexus for 1.2.0.  Do you agree?
  - edgent-distribution (for j8,j7,android)
  - edgent-parent/*source-release* - or edgent-parent in its entirety?  
(for j8,j7,android)
  - …/*-1.2.0-tests.*   (for j8,j7,android)
  - edgent-test* (for j8,j7)
  - what about “pom-only” intermediate dirs - will those show up in MC? Are 
they useful?
- edgent-analytics
- edgent-android
- edgent-api
...


> On Dec 6, 2017, at 4:00 AM, Christofer Dutz  
wrote:
> 
> Hi Dale,
> 
> So, I updated the scripts, deployed the RC in the correct area (I wonder 
why the other 1.0.0 and 1.1.0 areas are empty. Unfortunately, I had to test 
myself to the right solution by running the scripts and fine tuning my 
deployment and the scripts. But now I think we have a working solution. As 
nothing had to be changed with the source-bundle itself, I don’t think we need 
to cancel the RC and create a new one. What do you others think?
> 
> Chris
> 
> 
> Am 06.12.17, 09:10 schrieb "Christofer Dutz" :
> 
>HI Dale,
> 
>as I mentioned in the other DISCUSS thread I already noticed this 
shortcoming. 
>I think the following path should be ok for us to follow:
> 
>1. I manually add my pgp key to the list in KEYS in SVN
>2. I manually add the files created by the assembly plugin to SVN
>3. We continue the voting
>4. In develop I try to automate the deployment of RCs for the next 
version
>5. We decide what to deploy and what not to and add exclusions to the 
poms for next time
> 
>You think that’s a valid approach?
> 
>Chris
> 
> 
> 
>Am 06.12.17, 00:09 schrieb "Dale LaBossiere" :
> 
>Chris, thanks for moving the release/RC along!
> 
>I’ve kicked off this DISCUSS thread because I'm unable to tell if 
the
>staged RC is good to go or not and I didn’t want to pollute the 
RC1 Vote thread.
> 
>Since this is a new process for the project and the nexus / maven 
release flow
>is new to me I’m confused and have to ask some questions before I 
can assess
>if the RC contents are ok.
> 
>I, and others, definitely can’t follow the directions in the 
VOTE's [6] 
>even reading between the lines and omitting the RM and “binary” 
parts of it :-)
> 
>Here’s where I’m stumbling:
> 
>- I’m of the belief that the traditional normally mandated ASF 
*source* release staging and
>  release areas must continued to be used for the release’s 
aggregate source bundle(s)
>  https://dist.apache.org/repos/dist/dev/incubator/edgent 

>  https://dist.apache.org/repos/dist/release/incubator/edgent 

> 
>  There isn’t anything staged in the “dev” area for 1.2.0.
>  If you look at the

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1


Re the KEYS, please update the file in the incubator-edgent source repo.

FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing the 
release”
process is supposed to *move* the exact staged/voted artifacts to the release 
area.
I see the our buildTools/publish_release.sh script doesn’t bother to delete the
residual staged  dir.

In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS in the
“release” area (from the “dev” area) so that will be taken care of 
automatically if the script is used.
It looks like it should work without any changes.

Agreed, no need to cancel the RC1 vote at this moment since as you note, 
the RC1 source content hasn’t changed.  And generally, updating the poms,etc
for “what’s released” is OK to not include in the 1.2.0 source release.  But...

I think some things MUST get removed from Nexus for 1.2.0.  Do you agree?
  - edgent-distribution (for j8,j7,android)
  - edgent-parent/*source-release* - or edgent-parent in its entirety?  (for 
j8,j7,android)
  - …/*-1.2.0-tests.*   (for j8,j7,android)
  - edgent-test* (for j8,j7)
  - what about “pom-only” intermediate dirs - will those show up in MC? Are 
they useful?
- edgent-analytics
- edgent-android
- edgent-api
...


> On Dec 6, 2017, at 4:00 AM, Christofer Dutz  wrote:
> 
> Hi Dale,
> 
> So, I updated the scripts, deployed the RC in the correct area (I wonder why 
> the other 1.0.0 and 1.1.0 areas are empty. Unfortunately, I had to test 
> myself to the right solution by running the scripts and fine tuning my 
> deployment and the scripts. But now I think we have a working solution. As 
> nothing had to be changed with the source-bundle itself, I don’t think we 
> need to cancel the RC and create a new one. What do you others think?
> 
> Chris
> 
> 
> Am 06.12.17, 09:10 schrieb "Christofer Dutz" :
> 
>HI Dale,
> 
>as I mentioned in the other DISCUSS thread I already noticed this 
> shortcoming. 
>I think the following path should be ok for us to follow:
> 
>1. I manually add my pgp key to the list in KEYS in SVN
>2. I manually add the files created by the assembly plugin to SVN
>3. We continue the voting
>4. In develop I try to automate the deployment of RCs for the next version
>5. We decide what to deploy and what not to and add exclusions to the poms 
> for next time
> 
>You think that’s a valid approach?
> 
>Chris
> 
> 
> 
>Am 06.12.17, 00:09 schrieb "Dale LaBossiere" :
> 
>Chris, thanks for moving the release/RC along!
> 
>I’ve kicked off this DISCUSS thread because I'm unable to tell if the
>staged RC is good to go or not and I didn’t want to pollute the RC1 
> Vote thread.
> 
>Since this is a new process for the project and the nexus / maven 
> release flow
>is new to me I’m confused and have to ask some questions before I can 
> assess
>if the RC contents are ok.
> 
>I, and others, definitely can’t follow the directions in the VOTE's 
> [6] 
>even reading between the lines and omitting the RM and “binary” parts 
> of it :-)
> 
>Here’s where I’m stumbling:
> 
>- I’m of the belief that the traditional normally mandated ASF 
> *source* release staging and
>  release areas must continued to be used for the release’s aggregate 
> source bundle(s)
>  https://dist.apache.org/repos/dist/dev/incubator/edgent 
> 
>  https://dist.apache.org/repos/dist/release/incubator/edgent 
> 
> 
>  There isn’t anything staged in the “dev” area for 1.2.0.
>  If you look at the “release” area you’ll see what the expected 
> contents/layout are
>  (of course omitting the “binaries” dir for 1.2.0).
> 
>  FWIW, there seems to be inconsistency among what additional files
>  TLPs have - e.g., beam,nifi,camel only have the bundle, kafka 
> includes RELEASE_NOTES,
>  flex (which original edgent process derived from) has LICENSE, 
> README, ….
>  I guess we can follow the lean-and-mean ones if we want to :-)
> 
>  That said, that layout, and form of bundle name, is what the [6] 
> referenced
>  download-edgent-asf.sh tool expects so it simply won’t work.
>  I’m happy to fix the script, if appropriate, once I understand 
> things.
> 
>  Note: I see aggregate source release bundles *are* present in the 
> nexus dir:
>
> https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>  
> 
>  That said, the form of their names 
> (edgent-parent-1.2.0-source-releaase…) isn’t what's expected / required.
>

Re: [DISCUSS] Apache Edgent (Incubating) 1.2.0 RC1

Seems my mail hadn’t updated before I sent this reply.  I see you’ve done some 
things regarding the nexus content, so ignore that part of the following until 
I get up to date :-)

> On Dec 6, 2017, at 9:23 AM, Dale LaBossiere  wrote:
> 
> I’m sure I followed some Apache “release” doc to add to KEYS - it was a long 
> time ago.  I’ll track it down and fwd it.
> 
> It would seem natural for the maven-release-plugin, if that generally 
> supports the Apache release flows,
> to support it, no? Or maybe there’s an additional plugin for that?
> I’ll also poke around, or query, some other projects to see how they’ve dealt 
> with updating this SVN repo.
> If all else fails, I’ll update our tooling in buildTools so it works in our 
> new context.
> 
> Re the VOTE, I suggest we just extend it until we know better where the Nexus 
> repo contents stand.
> 
> On that note, what about my questions/observations on the nexus content?
> 
> — Dale
> 
>> On Dec 5, 2017, at 5:17 PM, Christofer Dutz  
>> wrote:
>> 
>> Looking a little into this, I think I could manually check in the archive to 
>> SVN this time.
>> The problem is, that I would probably have to add my key to the KEYS file at:
>> https://dist.apache.org/repos/dist/dev/incubator/edgent/KEYS
>> 
>> is it ok for me to just add it? Don’t even know if I could … and especially 
>> how to do that … Dale, as you are the only one listed in that file, how did 
>> you get your key added?
>> 
>> Chris
>> 
>> 
>> 
>> 
>> Am 05.12.17, 22:43 schrieb "Christofer Dutz" :
>> 
>>   I might have found a little problem …
>> 
>>   We set the final name and when we build the assembly produces a file 
>> called: apache-edgent-1.2.0-incubating-source-release.zip
>>   Unfortunately, as soon as it is deployed to nexus Maven seems to override 
>> the name and it is available as: edgent-parent-1.2.0-source-release.zip
>> 
>>   I don’t quite know how we can avoid this … how do other maven-built 
>> projects handle this problem? We could manually upload the source-bundles, 
>> built by the build to a non-Maven controlled location and vote on that.
>> 
>>   What do you think?
>> 
>>   Or would it be enough to vote on the bundles in Nexus and as soon as we 
>> upload the released bundles, we rename them and copy them to the dist 
>> section?
>> 
>>   Right now, I don’t quite know if I should vote +1 or -1 … eventually one 
>> of our mentors could help.
>> 
>>   Chris
>> 
>> 
>> 
>

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

Hi Dale,

So, I updated the scripts, deployed the RC in the correct area (I wonder why
the other 1.0.0 and 1.1.0 areas are empty. Unfortunately, I had to test myself
to the right solution by running the scripts and fine tuning my deployment and
the scripts. But now I think we have a working solution. As nothing had to be
changed with the source-bundle itself, I don’t think we need to cancel the RC
and create a new one. What do you others think?

Chris

Am 06.12.17, 09:10 schrieb "Christofer Dutz" :

HI Dale,

as I mentioned in the other DISCUSS thread I already noticed this
shortcoming.
I think the following path should be ok for us to follow:

1. I manually add my pgp key to the list in KEYS in SVN
2. I manually add the files created by the assembly plugin to SVN
3. We continue the voting
4. In develop I try to automate the deployment of RCs for the next version
5. We decide what to deploy and what not to and add exclusions to the poms
for next time

You think that’s a valid approach?

Chris

Am 06.12.17, 00:09 schrieb "Dale LaBossiere" :

Chris, thanks for moving the release/RC along!

I’ve kicked off this DISCUSS thread because I'm unable to tell if the
staged RC is good to go or not and I didn’t want to pollute the RC1
Vote thread.

Since this is a new process for the project and the nexus / maven
release flow
is new to me I’m confused and have to ask some questions before I can
assess
if the RC contents are ok.

I, and others, definitely can’t follow the directions in the VOTE's [6]
even reading between the lines and omitting the RM and “binary” parts
of it :-)

Here’s where I’m stumbling:

- I’m of the belief that the traditional normally mandated ASF *source*
release staging and
release areas must continued to be used for the release’s aggregate
source bundle(s)
https://dist.apache.org/repos/dist/dev/incubator/edgent

https://dist.apache.org/repos/dist/release/incubator/edgent

There isn’t anything staged in the “dev” area for 1.2.0.
If you look at the “release” area you’ll see what the expected
contents/layout are
(of course omitting the “binaries” dir for 1.2.0).

FWIW, there seems to be inconsistency among what additional files
TLPs have - e.g., beam,nifi,camel only have the bundle, kafka
includes RELEASE_NOTES,
flex (which original edgent process derived from) has LICENSE,
README, ….
I guess we can follow the lean-and-mean ones if we want to :-)

That said, that layout, and form of bundle name, is what the [6]
referenced
download-edgent-asf.sh tool expects so it simply won’t work.
I’m happy to fix the script, if appropriate, once I understand things.

Note: I see aggregate source release bundles *are* present in the
nexus dir:

https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/

That said, the form of their names
(edgent-parent-1.2.0-source-releaase…) isn’t what's expected / required.
Also note, those names are different from what -Papache-release
generates in the target dir
(apache-edgent-—incubating-source-release…)

- I’m unclear on what I see staged in nexus will ultimately be released
in nexus and mirrored to maven central,
hence unclear whether the nexus contents are “correct”.

Is everything present in the nexus’s RC staging repo going to get
mirrored to Maven Central
and if so, is that what’s desired?
- there are the aforementioned aggregate edgent-parent source bundles
(with names different from what's mandated - e.g. “incubating” in them)
- there are individual component source jars - I can imagine those
could be useful for associating src with a component
- there are individual component test jars - those seem undesired
- there’s the edgent-test* components - those seem undesired
- there are edgent-distribution components that have
aggregate/transitive “bin” bundles that we’re NOT releasing

Thanks in advance for the clarifications.
— Dale

> On Dec 5, 2017, at 3:40 AM, Christofer Dutz
wrote:
>
> Apache Edgent (Incubating) 1.2.0 has been staged under [4] and it’s
time to vote
> on accepting it for release. All

Re: [VOTE] Apache Edgent (Incubating) 1.2.0 RC1

Ok … little update:

I noticed that I still had to manually deploy the rc to the apache svn 
distribution area. So please use this url instead:
https://dist.apache.org/repos/dist/dev/incubator/edgent/1.2.0-incubating/rc1/

I also updated the download and check scripts to work with the new file-names 
and to skip binary bundles … so please go ahead with the procedure.
Will update the other scripts asap as well as the wiki documentation.

Chris



Am 05.12.17, 09:40 schrieb "Christofer Dutz" :

Apache Edgent (Incubating) 1.2.0 has been staged under [4] and it’s time to 
vote
on accepting it for release.  All Maven artifacts are available under [3].
If approved we will seek final release approval from the IPMC.
Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1
are required to pass.

Per [5] "Before voting +1 [P]PMC members are required to download
the signed source code package, compile it as provided, and test
the resulting executable on their own platform, along with also
verifying that the package meets the requirements of the ASF policy
on releases."

You can achieve the above by following [6].

[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM 
items in [6])
[ ]  -1 reject (explanation required)


Apache Edgent release process documentation:  [1] and [2]. However, this is 
a first test of a Maven based
Release described in the projects Maven site: 
src/site/asciidoc/releasing.adoc if this form of release proves
to be valid we will update [1] and [2] to the latest changes.

[1] 
https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
[2] 
https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
[3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
[4] 
https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
[5] https://www.apache.org/dev/release.html#approving-a-release
[6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1