Re: Serialport comms?

[Christofer Dutz]

Hi Niclas,

I guess the situation with the Serial protocols is identical to the ones for 
the IP-Based drivers. But I think also supporting serial protocols would be a 
valuable addition to PLC4X as still a lot of devices out in the wild only 
support this form of communication.

In the IP space we also see open-source drivers (usually with GPL License) 
which also look like ancient C translated to Java. I think we shouldn't even 
touch these GPL licensed drivers as using them directly would make PLC4X GPL 
and using their code as "inspiration" to implement our own would make PLC4X a 
"derivative work" and hereby GPL too, which we want to prevent at all costs. In 
the IP world we are currently implementing the drivers from scratch based on 
information we can get in a license that allows using that to implement a 
derivative work.

Beckhoff has been extremely kind in providing us with the specs for their 
protocols as well as allowing us to use that to implement our own driver. 
Siemens isn't that forthcoming (till now) ... most alternate source for 
information was usually available with a GPL license and we hereby couldn't use 
that. When implementing the Siemens S7 driver, the part that took most time, 
was to find information with an Apache compatible license and to 
reverse-engineer the missing parts :-/

Well if you could convince the commercial company to donate, that would be 
awesome. Depending on the code-quality we could then either integrate that 
directly or use it to implement a new driver from scratch.

If we can't get anyone to donate anything, we would have to implement the 
driver from scratch. Which I don't think is a too bad thing as this way we can 
directly write code that fits nicely into our existing landscape. 

So my preference would be:

- Get them to donate 
- Implement from the spec
- Use existing open-source driver (if licensing allows it)

Chris
 

Am 12.02.18, 11:16 schrieb "hedh...@gmail.com im Auftrag von Niclas Hedhman" 
:

Hi,
I was thinking about converting some of my protocol implementations to
plc4x, but I have only worked in the serialport space, (e.g Modbus/RTU
rather than Modbus/TCP).

There is a ancient Java specification (Java Comms API), which is not only
literally from last millennium, but rather poor as well.

So, what choices do we have?

* GNU has an implementation, which is rather bad Java code and the C/native
side needed a bit tweaking last time I worked with it.

* The best implementation I know is commercial, but perhaps we can entice a
code donation and/or a Apache Licensed API. I'll investigate that one...

* Our own implementation from scratch, which kind of belongs in Apache APR,
at least the C/native part.


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Serialport comms?

[Niclas Hedhman]

Hi,
I was thinking about converting some of my protocol implementations to
plc4x, but I have only worked in the serialport space, (e.g Modbus/RTU
rather than Modbus/TCP).

There is a ancient Java specification (Java Comms API), which is not only
literally from last millennium, but rather poor as well.

So, what choices do we have?

* GNU has an implementation, which is rather bad Java code and the C/native
side needed a bit tweaking last time I worked with it.

* The best implementation I know is commercial, but perhaps we can entice a
code donation and/or a Apache Licensed API. I'll investigate that one...

* Our own implementation from scratch, which kind of belongs in Apache APR,
at least the C/native part.


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: [DISCUSS] What assertion mechanism to use: JUnit, AssertJ or Hamcrest

[Justin Mclean]

Hi,

> Even if I like the way AssertJ handles exceptions a bit more than the 
> Hamcrest way, I never was particularly fond of never-ending fluent 
> expressions. So I would opt for the Hamcrest version.

No strong view either way as any tests are good to have :-) But I have used 
Hamcrest in the past and that’s what I’m familiar with. Niclas’ change looks 
good to me.

Thanks,
Justin

[DISCUSS] What assertion mechanism to use: JUnit, AssertJ or Hamcrest

[Christofer Dutz]

Hi all,

I think as the discussion moved from the unit-test framework to the framework 
we create the assertions with, this deserves a dedicated discussion.

I think the options on the table are currently: JUnits on-board Assertions, 
AssertJ or Hamcrest.

I too am not very fond of the ordinary Junit assertions and I’ll add Niclas’ 
very helpful input to the topic.

Even if I like the way AssertJ handles exceptions a bit more than the Hamcrest 
way, I never was particularly fond of never-ending fluent expressions. So I 
would opt for the Hamcrest version.

What do you think?

Here’s the link to Niclas’ changeset again: 
https://github.com/niclash/incubator-plc4x/commit/2080c40c02249db5f5ec0cf0b37b0ea0524de922

Chris

Re: Is Junit5 the way to go?

[Christofer Dutz]

Hi Niclas,

thanks for that ... this way I deffiitely can get a better feeling for the 
hamcrest style.
I think we should simply take this to another discussion thread and hear the 
others oppinions.
I know hamcrest for quite some time as the original author of the flexmojos 
plugin liked hamcrest too. 
Haven't used it that much in the past though.

Chris

Am 12.02.18, 06:56 schrieb "hedh...@gmail.com im Auftrag von Niclas Hedhman" 
:

Personally, I find the AssertJ (and practically all other attempts at this)
less powerful and harder to work with, as the DSL is not necessarily
intuitive, well it isn't for me when writing it, although one can guess
what it means when reading it, but perhaps that is the case for Hamcrest
too for other people. Additionally, if you ONLY know JUnit4, then a subset
of Hamcrest is already included inside the JUnit jar file. In essence, both
AssertJ and Hamcrest was a "solution" to the older JUnit assertion
mechanism.

In AssertJ, there seems to be a "bias" towards creating your own Unit Test
Assertion classes, so that the tests reads more nicely. And in Hamcrest,
the "bias" is towards creating a ever-growing library of generic assertions
independent of the unit tests at hand. IMHO, the former can still be done
in Hamcrest, but I have not seen that, and I have also seldom seen anyone
creating their own AssertJ assertion classes.

Across the Java community, more people are comfortable with Hamcrest than
AssertJ, probably due to Junit's inclusion of some of it.

My recommendation is to use JUnit4 + Hamcrest library + creating PLC4X
specific Matchers (if needed).


I spent this morning changing the AssertJ to Hamcrest across all tests. You
want a PR?

https://github.com/niclash/incubator-plc4x/commit/2080c40c02249db5f5ec0cf0b37b0ea0524de922


Cheers
Niclas



On Sun, Feb 11, 2018 at 5:31 PM, Christofer Dutz 
wrote:

> Hi Nicolas,
>
> While I was at it, I press everything to junit 4 and migrated all junit
> Assert statements with assertj assertions. Do you have any opinion to 
these
> two options? Hamcrest vs. AssertJ?
>
> Chris
>
> Outlook for Android herunterladen
>
>
>
> Von: Niclas Hedhman
> Gesendet: Sonntag, 11. Februar, 05:17
> Betreff: Re: Is Junit5 the way to go?
> An: dev@plc4x.apache.org
>
>
> The difference between Junit4 and Junit5 are relatively minor from a
> user's perspective. The real difference is when creating Runners for
> special need systems, such as Spring So, going with JUnit4 for now is not 
a
> bad thing... But, it seems that there is some legacy that should be
> scrapped, because it actually makes a difference. Avoid the
> Assert.isEqual(), Assert.isTrue() and so on, and only use the Hamcrest
> library for conditions, i.e. assertThat. The benefit is that one can use
> (or make) much more complex tests, which are otherwise ugly to write or
> report back what is expected. assertThat( myInteger, equalTo( 15 ) );
> assertThat( myCollection, hasItem( "Niclas" )); assertThat( myCollection,
> hasItems( "Niclas", "Justin", "Chris" )); Arbitrarily complex matchers can
> be made, and give a reasonable error message when failing. If I can find
> some time in the next couple of days, I will take a look and propose
> changes... On Feb 9, 2018 16:35, "Justin Mclean" wrote: > Hi, > > > thanks
> for finding that ... guess when porting all these thousands of >
> statements, I must have missed one or two "replace: ' == ' with >
> ').isEqualTo('” __ > > Yep I can imaging my brain zoning out when doing
> that :-) > > > Well the main reason was probably, that I wanted to replace
> the > "assertTrue(A==B)" with something like "assertEqual(A, B)" as this
> outputs > the "expected" and the actual "value" and hereby provides a
> little more > information than a simple "was false". So I had the option 
of
> converting it > to JUint "Assert.assertEquals" or update it to AssertJ's >
> "Assertions.assertThat().isEqualTo()" which I think is a little more >
> readable > > You know that Junit4 also has a assertThat? It’s has a
> slightly different > signature which what threw me when I first looked at
> the changes. > > Thanks, > Justin
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java