Hi Julian,
it sadens me to admit that, but I guess your assessment is absolutely correct.
I remember having this strange gutt feeling with having plc4py, plc4cpp and
plc4net first class citisens as they aren't usable. Then I was hoping the drive
in the community would make this happen soon.
So I would +1 your suggestion to move all of them into the sandbox (but I'd
leave the artifact and group-id's the way they currently are).
We could then remove the "with-java" profile.
What about the sandbox in general? Right now things in there aren't stable, but
also don't hold up the build.
So we could also remove the "with-sandbox" profile, but leave the other ones
(with-cpp, with-python, ...) to reduce build and setup time.
What do you all think?
Chris
Am 15.10.19, 19:21 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
Hi Chris,
thanks for picking up this discussion and for the three suggestions.
My initial approach would be rather similar to your suggestion 3 BUT with a
crucial addition.
My observation and belief is, that we currently focus nearly 100% on java
(I know that you work on codegen for the other languages but AFAIR there is
nothing in the near future which one would consider "releaseable").
Furthermore the only sustainable community we have is for the java world
- Python was initially done by me and most of the polishing / building was
done by Chris
- C# was initiated by Björn but AFAIR we have no "working" version or
something rather then an API design
- Cpp was driven by Markus Sommer but it went quite quiet about it the last
months, so I don’t know the exact state
So my (very pragmatic) approach would be to remove / move Python, C# and
probably also Cpp to a "sandbox" repo and focus the main build on Java which
would then become an absolute standard maven project and all the "profiles"
thing could go to the sandbox (probably with suggestion 1 or 2).
And as soon as a language "matures" we could acquire a Repo and move it
there.
I know that we want (and should) support many languages but I like the
drive we currently have in java and would prefer to do the refactoring which is
necessary with all the power we get from the generated drivers and THEN start
again with other languages.
Just my 2ct.
Julian
Am 15.10.19, 11:44 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Replying to both posts in one email ...
@Niclas: Yes we had thought of that ... as far as I remember it, it was
considered an option as the project grows. If we split it up now, this would
result in 6 repos (build-tools, protocols, java, c++, c# and python) ... this
would result in every release having to release and vote on at least 5
sub-releases. So I think we decided to keep things in one for now, however if
the to-be RMs have no problems executing such mass-releases and the PMC also
has no problems on verifying and voting on them, it would be an option. However
probably quite a bit of the build would have to be replicated in multiple repos
(Thrift)
@Tim: Guess that would be quite the same as my suggestion nr. 1, I
agree ... by adding it to the groovy it would have the benefit of us not having
to maintain this scripts that must function in multiple environments. I just
totally suck at BASH and BAT scripting ... the Groovy script executed in the
build even has the benefit of being debugable in IntelliJ, which was quite a
big help. But if someone is willing to implement such scripts and maintain them
I wouldn't object.
Chris
Am 15.10.19, 10:46 schrieb "Tim Mitsch"
<t.mit...@pragmaticindustries.de>:
Hey everybody,
First of all it's a very good idea to simply the profile-stuff.
My thoughts to that are that we maybe could add a little
shell-script (Mac/Linux), bat-file (Windows) that guides the user ("Do you want
to build Java-sources? [Yes/No]) and states if all requirements for build of
this profile is supplied by the specific machine of the user. I think that goes
in the direction of Chris suggestion 1)
Furthermore it would be good to supply a "with-all" Profile that
triggers all available profiles.
Best
Tim
Am 15.10.19, 10:07 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
Hi all,
as I have heard complaints that the current way we handle
profiles is too complicated, I would like to discuss alternatives with you all.
Currently if you just run “./mvnw install” it will only build
the protocols. This is probably not what the user wants.
Right now we didn’t want to overwhelm someone just wanting to
build Java, which will probably be the most common case to configure all the
prerequisites for C++ and C#.
So we introduced the “with-xyz” profiles. Now you only need to
provide the tooling needed for the parts you want to build, which reduces the
entry barrier (in my opinion)
On the other hand we didn’t want people working on C++ and C#
to have to run the Java test-suite before committing.
But it seems that having to enable profiles already raises the
barrier too high and people get confused instead of relieved. This was not
planned and therefore we need to react.
Yesterday I did a little brainstorming to what options I could
think of … perhaps you have others or you have feedback to them. Your opinion
would be highly appreciated:
1. If no “with-xyz” profile is activated, a message is
output which tells the user it should enable a profile (This should be very
simple to implement)
2. We make the “with-java” profile “enabled by default” (if
no profile is enabled, this one is automatically enabled, making the naïve
developer just trying “mvn package” scceed)
3. We remove all profiles and ask people to go into “plc4j”
to build the java part, into “sandbox” if they want to build the sandbox (We
could add the suggestion to use “-am” to the build which will “also build” any
outside modules needed by the current selection)
Here my thoughts to the approaches:
1. This shouldn’t have any negative side-effects (I
personally would prefer this … we could even try make it “interactive” where
the user can select the options he wants enabled and it generates a “command
line” the user can use to build what he wants)
2. The problem with enabled by default profiles is that they
get disabled if a profile is explicitly selected. So if a user builds “mvn
package” it would build java. But if he runs “mvn -Pwith-cpp package” it would
only build C++ and no longer java … if you want java and C++ you would need to
do “mvn -Pwith-java,with-cpp package” (Not that intuitive, I think … but an
option)
3. This will cause the “mvn package” type of persons to be
flooded with a list of things to install and the build will take pretty long.
As they will probably always have some prerequisite not installed and the build
will not start with an explanation on why, we could use this opportunity to
also point out that you don’t have to install all prerequisites if you only
want to build part of the project. In this case too we would have to split the
prerequisite check to the individual submodules or people will be left without
guidance when building only “plc4cpp” for example … so we would have the big
check in the root and multiple partial checks in the sub-directories.
I personally would prefer the version 1), but let’s discuss
this.
Perhaps you have other ideas … I would be happy to hear and
discuss them.
Chris
