[GitHub] [plc4x-build-tools] dependabot[bot] opened a new pull request, #75: chore(deps): bump maven-site-plugin from 4.0.0-M7 to 4.0.0-M8

[via GitHub]

dependabot[bot] opened a new pull request, #75:
URL: https://github.com/apache/plc4x-build-tools/pull/75

   Bumps [maven-site-plugin](https://github.com/apache/maven-site-plugin) from 
4.0.0-M7 to 4.0.0-M8.
   
   Commits
   
   https://github.com/apache/maven-site-plugin/commit/ab0524fc52efe09c1c1d95d1bbe089351cf19936;>ab0524f
 [maven-release-plugin] prepare release maven-site-plugin-4.0.0-M8
   https://github.com/apache/maven-site-plugin/commit/ace21d1787236a9ea7775e364e5685e2b171c23c;>ace21d1
 [MSITE-873] Mark SiteMojo and SiteJarMojo thread-safe
   https://github.com/apache/maven-site-plugin/commit/0e9a300c8a538b78f79161eab06c2d6a2d57f298;>0e9a300
 [MSITE-962] Upgrade to Doxia Sitetools to 2.0.0-M10, Maven Reporting 
Impl/Exe...
   https://github.com/apache/maven-site-plugin/commit/48f4155af2069e61c15399a475a26d2467749347;>48f4155
 [MSITE-964] Fix failure of 'site-jar' IT on Java 17
   https://github.com/apache/maven-site-plugin/commit/d452e4befc21c79b12c1277beab975418bca6bc8;>d452e4b
 [MSITE-963] Delete broken site descriptor files from local repository
   https://github.com/apache/maven-site-plugin/commit/ab07cd2ce6f22a40350f7b964c2fc0466591;>ab0
 [MSITE-961] Separate Fluido Skin version between site generation and 
testing/...
   https://github.com/apache/maven-site-plugin/commit/0c556eafa3ef639bfee6e18a6c9444dc2b2a0501;>0c556ea
 Remove old URLs and Maven versions
   https://github.com/apache/maven-site-plugin/commit/aee2c9727262bbc52206bf208d5c429cffc14bcf;>aee2c97
 [MSITE-959] Incorrect assumption of default locale
   https://github.com/apache/maven-site-plugin/commit/39d5e3635329932ed113c99adfe90d3b2c5940f1;>39d5e36
 [MSITE-958] Rewrite sitemap generator to a rendender
   https://github.com/apache/maven-site-plugin/commit/ca04195938a3632d041ebb5a8d50868790a4fecd;>ca04195
 [MSITE-957] Print generation log message in CategorySummaryDocumentRenderer 
l...
   Additional commits viewable in https://github.com/apache/maven-site-plugin/compare/maven-site-plugin-4.0.0-M7...maven-site-plugin-4.0.0-M8;>compare
 view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=org.apache.maven.plugins:maven-site-plugin=maven=4.0.0-M7=4.0.0-M8)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[PR] Feat/profinet ip set (plc4x)

[via GitHub]

hutcheb opened a new pull request, #927:
URL: https://github.com/apache/plc4x/pull/927

   Implement the Get Set PDU for LLDP.
   Implement the Set IP Address block for LLDP
   Add support for 16-Bit length fields for Pascal Strings, Originally only 
implemented 32-Bit length fields.
   Start to refactor the Network interface.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Please don't merge mspec changes if you haven't built with all languages enabled

[Christofer Dutz]

Hi Cesar,

No worries. I know how things are. I also commented out some tests in order to 
get the ads port implemented and forgot to fix that.

Actually the c Version is not affected as much (I already fixed it), as the c 
driver used way less features in order to be smaller. No worries about that.

Currently working on getting the Java Tests working again. Then I was planning 
on adding some more tests based on you pcaps and then fixing the go version.

Chris


Gesendet von Outlook für Android

From: Cesar Garcia 
Sent: Thursday, May 4, 2023 8:14:02 PM
To: Apache PLC4X 
Subject: Re: Please don't merge mspec changes if you haven't built with all 
languages enabled

greetings to all,

First of all, sorry for the problem caused by the modifications in the
mspec, but I needed to incorporate those modifications to continue with the
improvements of the S7 driver in its Java version.

I see that the best solution is to separate the project as Luck points out,
it would be in the medium term.


Now, as a team, I can support Chris with the C version, for which I would
need your guidance.

Awaiting your comments and guidance.

Best regards,


El jue, 4 de may de 2023, 1:14 a. m., Christofer Dutz <
christofer.d...@c-ware.de> escribió:

> And in general your idea is not bad... About releasing mspecs separately.
> The only fear I have with this, it's that if we don't want or repo to
> become a mess, like that of apache cocoon, we would need to split it up
> into many smaller repos and do a LOT more releases.
>
> Given the current activity here, not sure we want to do that.
>
> Chris
>
> Gesendet von Outlook für Android
> 
> From: Łukasz Dywicki 
> Sent: Wednesday, May 3, 2023 4:56:23 PM
> To: dev@plc4x.apache.org 
> Subject: Re: Please don't merge mspec changes if you haven't built with
> all languages enabled
>
> Hello Chris,
> What you asking for might effectively stop any contributions to protocol
> updates for entire project. There are very few people who can do Java,
> C, Go and eventually Python. I know one of goals of Apache PLC4X is
> supporting variety of languages, but what you suggest  mean that less
> and less people will be able contribute mspec fixes. There will be even
> less of them with each next language we introduce..
> While I understand it is important to keep consistency, reality is we
> have far less people working on C than on Java. Some of languages we
> have code generators and drivers for, did and will fall behind.
> I'd rather opt for keeping mspecs releases separate from drivers so
> plc4j/plc4c and plc4go can pick version they support and stick with it.
> This is the way in which we can avoid troubles with new changes which
> are implemented in one language but not others. What do you think about
> that?
>
> Best,
> Łukasz
>
>
> On 3.05.2023 16:42, Christofer Dutz wrote:
> > Hi all,
> >
> > we’re currently trying to get the S7 driver back working ... even if it
> seems as if it is working (When running the ManualS7Test) ... None of the
> Integration-Tests are running, because all are disabled.
> > This makes quality assurance quite difficult.
> >
> > Also, the fact that the changes broke the C and the Go versions is
> “sub-ideal”.
> >
> > We’ll try to fix the problems, but I guess it’s going to consume a lot
> of time to do so.
> >
> > But in the future ... if you change mspecs for drivers, you might break
> things in other languages, so It’s super important to ensure stuff is
> working in all languages.
> >
> > Also please don’t comment out tests ... I know I found a place where I
> did so too and I promise to not do it again.
> >
> > We really have to pay a bit more attention on not reducing more and more
> of our tests.
> >
> > Chris
> >
> >
> >
>

Re: Please don't merge mspec changes if you haven't built with all languages enabled

[Cesar Garcia]

greetings to all,

First of all, sorry for the problem caused by the modifications in the
mspec, but I needed to incorporate those modifications to continue with the
improvements of the S7 driver in its Java version.

I see that the best solution is to separate the project as Luck points out,
it would be in the medium term.


Now, as a team, I can support Chris with the C version, for which I would
need your guidance.

Awaiting your comments and guidance.

Best regards,


El jue, 4 de may de 2023, 1:14 a. m., Christofer Dutz <
christofer.d...@c-ware.de> escribió:

> And in general your idea is not bad... About releasing mspecs separately.
> The only fear I have with this, it's that if we don't want or repo to
> become a mess, like that of apache cocoon, we would need to split it up
> into many smaller repos and do a LOT more releases.
>
> Given the current activity here, not sure we want to do that.
>
> Chris
>
> Gesendet von Outlook für Android
> 
> From: Łukasz Dywicki 
> Sent: Wednesday, May 3, 2023 4:56:23 PM
> To: dev@plc4x.apache.org 
> Subject: Re: Please don't merge mspec changes if you haven't built with
> all languages enabled
>
> Hello Chris,
> What you asking for might effectively stop any contributions to protocol
> updates for entire project. There are very few people who can do Java,
> C, Go and eventually Python. I know one of goals of Apache PLC4X is
> supporting variety of languages, but what you suggest  mean that less
> and less people will be able contribute mspec fixes. There will be even
> less of them with each next language we introduce..
> While I understand it is important to keep consistency, reality is we
> have far less people working on C than on Java. Some of languages we
> have code generators and drivers for, did and will fall behind.
> I'd rather opt for keeping mspecs releases separate from drivers so
> plc4j/plc4c and plc4go can pick version they support and stick with it.
> This is the way in which we can avoid troubles with new changes which
> are implemented in one language but not others. What do you think about
> that?
>
> Best,
> Łukasz
>
>
> On 3.05.2023 16:42, Christofer Dutz wrote:
> > Hi all,
> >
> > we’re currently trying to get the S7 driver back working ... even if it
> seems as if it is working (When running the ManualS7Test) ... None of the
> Integration-Tests are running, because all are disabled.
> > This makes quality assurance quite difficult.
> >
> > Also, the fact that the changes broke the C and the Go versions is
> “sub-ideal”.
> >
> > We’ll try to fix the problems, but I guess it’s going to consume a lot
> of time to do so.
> >
> > But in the future ... if you change mspecs for drivers, you might break
> things in other languages, so It’s super important to ensure stuff is
> working in all languages.
> >
> > Also please don’t comment out tests ... I know I found a place where I
> did so too and I promise to not do it again.
> >
> > We really have to pay a bit more attention on not reducing more and more
> of our tests.
> >
> > Chris
> >
> >
> >
>

[BUILD-STABLE]: Job 'PLC4X/PLC4X/develop [develop] [1357]'

[Apache Jenkins Server]

BUILD-STABLE: Job 'PLC4X/PLC4X/develop [develop] [1357]':

Is back to normal.

[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [1356]'

[Apache Jenkins Server]

BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [1356]':

Check console output at "https://ci-builds.apache.org/job/PLC4X/job/PLC4X/job/develop/1356/;>PLC4X/PLC4X/develop
 [develop] [1356]"

[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [1354]'

[Apache Jenkins Server]

BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [1354]':

Check console output at "https://ci-builds.apache.org/job/PLC4X/job/PLC4X/job/develop/1354/;>PLC4X/PLC4X/develop
 [develop] [1354]"

[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [1353]'

[Apache Jenkins Server]

BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [1353]':

Check console output at "https://ci-builds.apache.org/job/PLC4X/job/PLC4X/job/develop/1353/;>PLC4X/PLC4X/develop
 [develop] [1353]"

AW: [Opinion] NiFi integration Listener

[Christofer Dutz]

Hi Unai,

currently only protocoly actively supporting subscriptions implement the 
Subscription API.
We were planning on adding a transparent polling emulation of subscriptions for 
protocols, that don’t natively support them, however. But I guess that’s still 
going to take quite some time till we implement that.

Chris



Von: Unai Leria 
Datum: Donnerstag, 4. Mai 2023 um 09:37
An: Otto Fowler , dev 
Betreff: Re: [Opinion] NiFi integration Listener
The idea is that the processor only allows the use of plc4x subscription 
requests. It would only work on drivers that support subscription.
I have made the assumption that the all plc4x subscriptions implementations are 
optimized listeners and are not based only on continuous polling.


De: "Otto Fowler" 
Para: "dev" , "unai leria" 
Enviados: Miércoles, 3 de Mayo 2023 16:38:08
Asunto: Re: [Opinion] NiFi integration Listener

So this would be a plc4x subscription listener not something polling? I don’t 
think that is a bad idea overall, as long as it is true
Unsolicited / subscription / Exception based processing and not polling in a 
background thread.






On May 3, 2023 at 4:36:03 AM, Unai Leria ( [ mailto:unai.le...@zylk.net.invalid 
| unai.le...@zylk.net.invalid ] ) wrote:


Hi Otto!

The idea was to use the processor to support plc4x subscriptions. Maybe the 
"listener" name was not the most appropriate one but I was trying to follow the 
NiFi naming convention.

Sorry for the misunderstanding

Unai

- Mensaje original -
De: "Otto Fowler" < [ mailto:ottobackwa...@gmail.com | ottobackwa...@gmail.com 
] >
Para: "dev" < [ mailto:dev@plc4x.apache.org | dev@plc4x.apache.org ] >, "unai 
leria" < [ mailto:unai.le...@zylk.net | unai.le...@zylk.net ] >
Enviados: Miércoles, 3 de Mayo 2023 3:53:17
Asunto: Re: [Opinion] NiFi integration Listener

On May 2, 2023 at 9:52:08 PM, Otto Fowler ( [ mailto:ottobackwa...@gmail.com | 
ottobackwa...@gmail.com ] ) wrote:

Hi Unai!

So, this listener would listen for exception based or unsolicited messages?
If it is just polling on a background thread, I don’t think how you want to
do something in nifi, and we already have “polling” processors.



On May 2, 2023 at 11:09:33 AM, Unai Leria (unai.le...@zylk.net.invalid)
wrote:

Hi br/> <
I have been taking a look into the possibility of adding a PLC4x Listener
to the NiFi integration. br/> <
Under my research, and following how most of the ListenXXX processors in
the standard-bundle of NiFi are, a good solution would be:


* A processor that starts a thread when it is scheduled.
* That thread connects to the plc and appends the messages received into a
queue. br/> * The processor reads the messages from thiis queue only
running when not empty. br/> <
In particular ListenTCP and ListenUDP would be the closest ones to the
implementation I describe. br/> <
In order to account for inevitable disconnections I suggest including an
additional queue prior to the queue that connects to the processor. Its
function would be to check if the time to the last event is greater than x
amount and reconnect in that case. br/> <
As a proof of concept I already have a working version on
[ 
https://github.com/zylklab/plc4x/tree/feature/nifi-integration-record-listener 
| 
https://github.com/zylklab/plc4x/tree/feature/nifi-integration-record-listener 
] .
br/> <
I would appreciate your opinion on this feature. br/>If you like it I can
create a PR. br/> <
Thanks you for your time! br/> <
Unai Lería br/>

Re: [Opinion] NiFi integration Listener

[Łukasz Dywicki]

Hello Unai and Otto,
There are certain traps with this approach as not all protocols are 
equal in this regard. Currently 
PlcConnection.getMetadata().canSubscribe() determines if driver/protocol 
itself supports subscriptions, however it does not indicate that 
connection as a whole will handle it properly.
Given recent example of S7 updates - S7-1200 does not support 
subscriptions or supports it in very limited. S7-1500 will handle wider 
pool of areas where you can subscribe. Luckily we can attempt to guess 
what sits on other side of connection to dynamically determine if 
subscription is possible.
Pulling example further - with BACnet devices (such driver does not 
exist yet for Java) you have a single "logical connection" but multiple 
devices behind it. Each device behind that connection may or may not 
support subscription (change of values).
ADS on other hand I think have no limitations on what to subscribe, thus 
any field will work.


There are specific relations between driver, protocol and device and our 
ability to tell exactly if plc4x subscriptions will work. Bear in mind 
that while you will be working on a listener.


Cheers,
Łukasz

On 4.05.2023 09:37, Unai Leria wrote:

The idea is that the processor only allows the use of plc4x subscription 
requests. It would only work on drivers that support subscription.
I have made the assumption that the all plc4x subscriptions implementations are 
optimized listeners and are not based only on continuous polling.


De: "Otto Fowler" 
Para: "dev" , "unai leria" 
Enviados: Miércoles, 3 de Mayo 2023 16:38:08
Asunto: Re: [Opinion] NiFi integration Listener

So this would be a plc4x subscription listener not something polling? I don’t 
think that is a bad idea overall, as long as it is true
Unsolicited / subscription / Exception based processing and not polling in a 
background thread.






On May 3, 2023 at 4:36:03 AM, Unai Leria ( [ mailto:unai.le...@zylk.net.invalid 
| unai.le...@zylk.net.invalid ] ) wrote:


Hi Otto!

The idea was to use the processor to support plc4x subscriptions. Maybe the 
"listener" name was not the most appropriate one but I was trying to follow the 
NiFi naming convention.

Sorry for the misunderstanding

Unai

- Mensaje original -
De: "Otto Fowler" < [ mailto:ottobackwa...@gmail.com | ottobackwa...@gmail.com ] 
>
Para: "dev" < [ mailto:dev@plc4x.apache.org | dev@plc4x.apache.org ] >, "unai leria" 
< [ mailto:unai.le...@zylk.net | unai.le...@zylk.net ] >
Enviados: Miércoles, 3 de Mayo 2023 3:53:17
Asunto: Re: [Opinion] NiFi integration Listener

On May 2, 2023 at 9:52:08 PM, Otto Fowler ( [ mailto:ottobackwa...@gmail.com | 
ottobackwa...@gmail.com ] ) wrote:

Hi Unai!

So, this listener would listen for exception based or unsolicited messages?
If it is just polling on a background thread, I don’t think how you want to
do something in nifi, and we already have “polling” processors.



On May 2, 2023 at 11:09:33 AM, Unai Leria (unai.le...@zylk.net.invalid)
wrote:

Hi br/> <
I have been taking a look into the possibility of adding a PLC4x Listener
to the NiFi integration. br/> <
Under my research, and following how most of the ListenXXX processors in
the standard-bundle of NiFi are, a good solution would be:


* A processor that starts a thread when it is scheduled.
* That thread connects to the plc and appends the messages received into a
queue. br/> * The processor reads the messages from thiis queue only
running when not empty. br/> <
In particular ListenTCP and ListenUDP would be the closest ones to the
implementation I describe. br/> <
In order to account for inevitable disconnections I suggest including an
additional queue prior to the queue that connects to the processor. Its
function would be to check if the time to the last event is greater than x
amount and reconnect in that case. br/> <
As a proof of concept I already have a working version on
[ 
https://github.com/zylklab/plc4x/tree/feature/nifi-integration-record-listener 
| 
https://github.com/zylklab/plc4x/tree/feature/nifi-integration-record-listener 
] .
br/> <
I would appreciate your opinion on this feature. br/>If you like it I can
create a PR. br/> <
Thanks you for your time! br/> <
Unai Lería br/>

Re: [PR] build(deps): bump kafka.version from 3.2.0 to 7.4.0-ce (plc4x)

[via GitHub]

sruehl closed pull request #926: build(deps): bump kafka.version from 3.2.0 to 
7.4.0-ce
URL: https://github.com/apache/plc4x/pull/926


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [Opinion] NiFi integration Listener

[Unai Leria]

The idea is that the processor only allows the use of plc4x subscription 
requests. It would only work on drivers that support subscription. 
I have made the assumption that the all plc4x subscriptions implementations are 
optimized listeners and are not based only on continuous polling. 


De: "Otto Fowler"  
Para: "dev" , "unai leria"  
Enviados: Miércoles, 3 de Mayo 2023 16:38:08 
Asunto: Re: [Opinion] NiFi integration Listener 

So this would be a plc4x subscription listener not something polling? I don’t 
think that is a bad idea overall, as long as it is true 
Unsolicited / subscription / Exception based processing and not polling in a 
background thread. 






On May 3, 2023 at 4:36:03 AM, Unai Leria ( [ mailto:unai.le...@zylk.net.invalid 
| unai.le...@zylk.net.invalid ] ) wrote: 


Hi Otto! 

The idea was to use the processor to support plc4x subscriptions. Maybe the 
"listener" name was not the most appropriate one but I was trying to follow the 
NiFi naming convention. 

Sorry for the misunderstanding 

Unai 

- Mensaje original - 
De: "Otto Fowler" < [ mailto:ottobackwa...@gmail.com | ottobackwa...@gmail.com 
] > 
Para: "dev" < [ mailto:dev@plc4x.apache.org | dev@plc4x.apache.org ] >, "unai 
leria" < [ mailto:unai.le...@zylk.net | unai.le...@zylk.net ] > 
Enviados: Miércoles, 3 de Mayo 2023 3:53:17 
Asunto: Re: [Opinion] NiFi integration Listener 

On May 2, 2023 at 9:52:08 PM, Otto Fowler ( [ mailto:ottobackwa...@gmail.com | 
ottobackwa...@gmail.com ] ) wrote: 

Hi Unai! 

So, this listener would listen for exception based or unsolicited messages? 
If it is just polling on a background thread, I don’t think how you want to 
do something in nifi, and we already have “polling” processors. 



On May 2, 2023 at 11:09:33 AM, Unai Leria (unai.le...@zylk.net.invalid) 
wrote: 

Hi br/> < 
I have been taking a look into the possibility of adding a PLC4x Listener 
to the NiFi integration. br/> < 
Under my research, and following how most of the ListenXXX processors in 
the standard-bundle of NiFi are, a good solution would be: 


* A processor that starts a thread when it is scheduled. 
* That thread connects to the plc and appends the messages received into a 
queue. br/> * The processor reads the messages from thiis queue only 
running when not empty. br/> < 
In particular ListenTCP and ListenUDP would be the closest ones to the 
implementation I describe. br/> < 
In order to account for inevitable disconnections I suggest including an 
additional queue prior to the queue that connects to the processor. Its 
function would be to check if the time to the last event is greater than x 
amount and reconnect in that case. br/> < 
As a proof of concept I already have a working version on 
[ 
https://github.com/zylklab/plc4x/tree/feature/nifi-integration-record-listener 
| 
https://github.com/zylklab/plc4x/tree/feature/nifi-integration-record-listener 
] . 
br/> < 
I would appreciate your opinion on this feature. br/>If you like it I can 
create a PR. br/> < 
Thanks you for your time! br/> < 
Unai Lería br/>