Has multiple repositories been considered? A project may request as many as
they want/need...

On Tue, Oct 15, 2019 at 4:07 PM 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

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

Reply via email to