+1 to that :-)
Am 16.10.19, 13:41 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
Sorry, some appendum.
I +1 Chris proposal but I see that in a (hopefully not too far) future
communities gather for separate languages they should ofc choose the build tool
of their choice (use make and deal with it... __).
But I agree with Chris that as long as the "core" or "java" team manages
"everything" it will be maven, as this is what we prefer.
Julian
Am 16.10.19, 13:17 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
Clear +1 from my side for this approach.
Am 16.10.19, 10:41 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
Hi Julian,
I suggest not to have a "with-java" profile anymore and no
"with-sandbox".
Java will probably always be the leading language (at least for the
near future).
Perhaps it would really be better to split out the other languages
as soon as they are ready to leave the sandbox, but to stick with Maven builds
for them.
(Don't want to make it too difficult for the CI and
Release-Managers)
Chris
Am 16.10.19, 10:12 schrieb "Julian Feinauer"
<j.feina...@pragmaticminds.de>:
Hi Chris,
I agree with you and perhaps another way to gain traction is to
"finish" java "kind of" and then move together to another language.
And regarding the suggestion, why not.
So you suggest to jave "with-java" as the default and the
others as "add on" profiles, right?
Julian
Am 16.10.19, 10:09 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
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
