Re: Understanding the snapshot and release process

2017-06-12 Thread Christofer Dutz 
Hi Dale,

Glad you like that … I was going to address the “checked in IDE settings” thing 
soon ;-)

I am working with IntelliJ without any issues in my Maven setup. Had to rename 
the Gradle build to make IntelliJ chose Maven though.

In my opinion IDE settings shouldn’t be checked in and should rather be added 
to the gitignore list. Don’t know how often we had issues in Flex with checked 
in IDE settings :-(

The warnings are related to the fact that all Apache Maven configurations have 
the “Apache root pom” as top-most parent. A lot Some things are configured 
there. However I’m using different versions of some plugins and re-defining 
them in the edgent-parent. That’s what the first block of warnings are about.

The rest of the blocks are because in order to work correctly the e2m plugin 
has built-in configurations on what to do for which default maven plugin. This 
is how Eclipse knows when to copy resources, compile classes and eventually 
even generate code. However per default not all plugins are handled by the m2e 
plugin. That’s what the second block is about. There is a way to get rid of 
them and eventually even tell Eclipse what to do, but this would need some fine 
tuning. I would like to address that as soon as we’re finished. Otherwise I 
would probably have to re-configure that over and over again. Mabe it would be 
good to tell Eclipse to ignore the plugins it doesn’t know so the errors go 
away and then to fine tune them afterwards.

Chris



Von: Dale LaBossiere 
Antworten an: "dev@edgent.apache.org" 
Datum: Montag, 12. Juni 2017 um 22:43
An: "dev@edgent.apache.org" 
Betreff: Re: Understanding the snapshot and release process

Chris, I started to try to get Eclipse working with the maven PR-309 changes.  
Making some progress.

At a high level, I removed all existing .project and .classpath Eclipse files 
from my local git clone.
Then I created a new Eclipse workspace and did an “Import existing Maven 
Projects”.
Eclipse then created a .project and .classpath from the poms.
Seemingly all good stuff.  And presumably analogous to importing a maven 
project into IntelliJ.

But I have 3 build problems and 66 (mostly pom.xml related) warnings.

What do you make of these warnings in the top-level pom.xml?   Googling seems 
to tell me that the “Overriding managed version” warnings are because the 
top-level pom.xml is overriding the versions for the plugins inherited from the 
parent pom.xml (org.apache:apache:18 ???) ???

[cid:image001.png@01D2E3CF.2BA7FA50]


There are a lot (every project/module I assume) of these:
[cid:image002.png@01D2E3CF.2BA7FA50]

Any thoughts on the 3 errors?
[cid:image003.png@01D2E3CF.2BA7FA50]
the full error msgs are:
[cid:image004.png@01D2E3CF.2BA7FA50]

— Dale

[jira] [Commented] (EDGENT-388) add support for IotpGateway publish over HTTP

2017-06-12 Thread Dale LaBossiere (JIRA) 

[ 
https://issues.apache.org/jira/browse/EDGENT-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16046803#comment-16046803
 ] 

Dale LaBossiere commented on EDGENT-388:


update: see the noted iot-java issue for progress.  support is now present in 
beta form.

> add support for IotpGateway publish over HTTP
> -
>
> Key: EDGENT-388
> URL: https://issues.apache.org/jira/browse/EDGENT-388
> Project: Edgent
>  Issue Type: New Feature
>  Components: Connectors
>Reporter: Dale LaBossiere
>Priority: Minor
>
> It turns out WIoTP doesn't yet support publishing of Gateway device events or 
> its connected device's events over HTTP. See 
> [iot-java/issues/85|https://github.com/ibm-watson-iot/iot-java/issues/85].
> Once it's available update IotpGWConnector to support it (see commented out 
> code) and expose support for it in IotpGateway.  Update IotpGWDeviceSample 
> (see commented out code for useHttp).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (EDGENT-388) add support for IotpGateway publish over HTTP

2017-06-12 Thread Dale LaBossiere (JIRA) 

 [ 
https://issues.apache.org/jira/browse/EDGENT-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale LaBossiere updated EDGENT-388:
---
Description: 
It turns out WIoTP doesn't yet support publishing of Gateway device events or 
its connected device's events over HTTP. See 
[iot-java/issues/85|https://github.com/ibm-watson-iot/iot-java/issues/85].

Once it's available update IotpGWConnector to support it (see commented out 
code) and expose support for it in IotpGateway.  Update IotpGWDeviceSample (see 
commented out code for useHttp).

  was:
It turns out WIoTP doesn't yet support publishing of Gateway device events or 
its connected device's events over HTTP. See 
[iot-java/issues/83|https://github.com/ibm-watson-iot/iot-java/issues/83].

Once it's available update IotpGWConnector to support it (see commented out 
code) and expose support for it in IotpGateway.  Update IotpGWDeviceSample (see 
commented out code for useHttp).


> add support for IotpGateway publish over HTTP
> -
>
> Key: EDGENT-388
> URL: https://issues.apache.org/jira/browse/EDGENT-388
> Project: Edgent
>  Issue Type: New Feature
>  Components: Connectors
>Reporter: Dale LaBossiere
>Priority: Minor
>
> It turns out WIoTP doesn't yet support publishing of Gateway device events or 
> its connected device's events over HTTP. See 
> [iot-java/issues/85|https://github.com/ibm-watson-iot/iot-java/issues/85].
> Once it's available update IotpGWConnector to support it (see commented out 
> code) and expose support for it in IotpGateway.  Update IotpGWDeviceSample 
> (see commented out code for useHttp).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Understanding the snapshot and release process

2017-06-12 Thread Dale LaBossiere 

> On Jun 12, 2017, at 10:23 AM, Christofer Dutz  
> wrote:
> 
> Well “mvn test” would run the maven lifecycle up to the test phase, this 
> includes compiling etc … and compiling doesn’t work with Java7.
Maven doesn’t have the notion of build-avoidance / artifact reuse?
I can imagine that even if it did, it might record the JDK version used to 
generate the artifacts and then not reuse them when the current JDK version is 
different.

> We could probably create some solution to manually load and run the tests 
> inside the test-jars but integrating this into one nice Maven build could be 
> a challenging task, so say the least … but we wouldn’t have to, if you would 
> be ok with the signature-verification option. 
I’m holding out till I better understand maven’s behavior/limitations and what 
other strategies might exist :-)

> 
> Seems not, so I’ll continue digging … but this one will probably take a 
> little longer. 

What do other projects do if for example they build/release to a 
least-common-demonitor, e.g., 1.7, and still want to do actual test 
verification against the higher compatible/supported version, e.g., 1.8?  They 
don’t/can’t use standard maven machinery for that?  They must build some 
parallel test execution / reporting machinery?

— Dale

[jira] [Created] (EDGENT-420) Convert from ASF svn main repo to "real github"

2017-06-12 Thread Dale LaBossiere (JIRA) 
Dale LaBossiere created EDGENT-420:
--

 Summary: Convert from ASF svn main repo to "real github"
 Key: EDGENT-420
 URL: https://issues.apache.org/jira/browse/EDGENT-420
 Project: Edgent
  Issue Type: Task
  Components: Miscellaneous
Reporter: Dale LaBossiere


There was no dissenting option on discussion on dev@.

Is there ASF doc regarding this config / converting?  Ultimately involves INFRA 
JIRAs.

Can cvt src vs website repos independently
- convert incubating-edgent repo to github - OK
- convert JIRAs to github - OK but, how to export/import?  Also, today JIRAs 
cover both src and website repos, website JIRAs would be in website github 
issues.
- convert incubating-edgent-website to github?  Investigate, concern over 
change in scripts, etc for dev/publish



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (EDGENT-419) Remove use of java8 default interface methods by tests

2017-06-12 Thread Dale LaBossiere (JIRA) 

 [ 
https://issues.apache.org/jira/browse/EDGENT-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dale LaBossiere resolved EDGENT-419.

Resolution: Fixed

resolved by https://github.com/apache/incubator-edgent/pull/310

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

Re: Understanding the snapshot and release process

2017-06-12 Thread Christofer Dutz 
Ok … so I’m working on the open issues … I do have one question though … 
Compiling with one java version and then running a different one with the tests 
will be challenging, if not impossible. 
What I did a while ago was to introduce the animal-sniffer plugin. This very 
strictly checks the resulting class files against the signatures for a given 
JDK to ensure the classes would work in that particular JDK. Would this be 
enough for you? It’s what we settled for in the Flex project. In the past we 
did have to re-release stuff because even if we compiled to output 1.7 code, 
the code wasn’t runnable on 1.7. Since introducing the animal-sniffer plugin we 
never had problems like this again. 

Chris


Am 10.06.17, 22:45 schrieb "Christofer Dutz" :

Hi Dale,

Thanks for that … I had noticed the merged pull request … today I pulled in 
the upstream changes and tweaked the build a little. 
Now both the java8 and java7 builds seem to be working. I also made the 
build compile to different target sub-directories so now you can inspect the 
output from both runs without having them interfering. 

Chris


Am 09.06.17, 22:29 schrieb "Dale LaBossiere" :

Hi Chris,  in case you hadn’t noticed the following merged PR (on 
master) eliminates the
use of “default”.  So you should be able to rebase your branch your 
branch and be all set.

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


> On Jun 8, 2017, at 10:40 AM, Christofer Dutz 
 wrote:
> ...problem. The default methods in DirectTestSetup can’t seem to be 
backported if the interface and the implementing class are not in the same 
retrolambda execution. Eventually refactoring the tests to work without default 
methods would be a good idea.

— Dale