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> wrote: > 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
