Hi All, Thank you all for the vast amount of replies, I like the idea of having an option to define an environment either in the global space or in a space linked to a project. I think following this approach would not break the current implementation either. It would be a new feature (adding the global space) to the current code.
Another thing we all agree on is that when linking to projects the name has to be unique in the project space, when making a global environment it has to be unique in both the global and the project space. The dropdown can then show all available environments in the global and current project space. Let's keep this one open for a little while longer and then attach actions to it. Cheers, Hans On Tue, 2 Nov 2021 at 18:04, Ricardo Gouvea <[email protected]> wrote: > My vote is to 1 too > > Em ter., 2 de nov. de 2021 às 14:00, Sergio Ramazzina (SERASOFT) < > [email protected]> escreveu: > > > Hi hoppers, > > > > I personally very much agree with Bart's proposal on making this > > behavior configurable so that it can be used and implemented the way we > > prefer. > > > > I also agree that this could add additional complexity but this will not > > be a big problem if everything will be well designed and also (the > > major plus) it adds the missing flexibility to accomplish everyone's > > needs on this topic. > > > > So +1 in my opinion on having it configurabable. > > > > Cheers > > > > Sergio > > > > Il 02/11/2021 17:52, Bart Maertens ha scritto: > > > Hi All, > > > > > > Even though I agree with the concept of having environments as > > independent > > > and standalone objects, my personal experience is that environments are > > > linked to projects in almost all cases. > > > > > > We'll probably have a couple of opinions here, so why not make this > > > configurable? > > > > > > We could have a default global option that either sets environments as > > > standalone or linked to the project they were created in. > > > > > > On an individual environment level, we could add another option to > > overrule > > > the global default for a specific environment. > > > > > > For example, if a user's default is to link environments to projects, > > this > > > option would show a checkbox that is checked (default). The default can > > be > > > overruled (uncheck the checkbox) to make this environment available > > > independent of projects. > > > > > > This would add some additional complexity and verbosity to > > hop-config.json, > > > but you're not supposed to modify that file by hand if you don't know > > > what you're doing anyway. > > > > > > Regards, > > > Bart > > > > > > > > > On Tue, Nov 2, 2021 at 3:37 PM Ricardo Gouvea <[email protected]> > > wrote: > > > > > >> Hi Hans, > > >> > > >> My experience suggests that projects be disconnected from projects, I > > agree > > >> with your justification. > > >> > > >> Cheers, > > >> > > >> Em ter., 2 de nov. de 2021 às 05:19, Hans Van Akelyen < > > >> [email protected]> escreveu: > > >> > > >>> Hi Hop enthusiasts, developers and philosophers > > >>> > > >>> I have had an interesting discussion with Sergio on Jira ticket > > HOP-3471 > > >>> [1] but we would like to get a bit of a broader consensus. > > >>> > > >>> So the main question is: do we see an environment as something linked > > to > > >> a > > >>> single project or are they objects that can be reused for several > > >> projects? > > >>> Both approaches have pro's and con's but we need to agree on this as > it > > >>> would change user experience and maybe how they are stored. > > >>> > > >>> Currently an environment is a semi-standalone object, it is not > linked > > >> to a > > >>> project in the hop-project.json but it is linked to a project in the > > >>> hop-config.json. In the GUI all environments are shown, not only the > > >>> environments linked to a project. When using hop-run I *think* you > can > > >>> point to an environment that is not linked to the project in the > > >>> hop-config.json. > > >>> > > >>> My personal preference would be to unlink them completely and have > > >>> environments that could be used by multiple projects. This gives > > greater > > >>> flexibility when you would want to divide your projects on a lower > > level. > > >>> con would be that you would always see all available environments > > defined > > >>> in your hop-config.json. > > >>> > > >>> I would love for some opinions on the matter so it can be set in > stone > > >> once > > >>> and for all. And we can update our docs to reflect this decision > > [2][3]. > > >>> > > >>> Cheers, > > >>> Hans > > >>> > > >>> > > >>> [1] https://issues.apache.org/jira/browse/HOP-3471 > > >>> [2] > > >>> > > >>> > > >> > > > https://hop.apache.org/manual/latest/projects/projects-environments.html#top > > >>> [3] > > >> > https://hop.apache.org/manual/latest/projects/index.html#_environments > > >> > > >> -- > > >> > > >> > > >> > > >> <https://www.openin.com.br> > > >> > > >> Patrocinadora Oficial do > > >> > > >> Pentaho Day 2019 > > >> > > >> Ricardo Gouvêa > > >> > > >> CEO > > >> > > >> [email protected] > > >> > > >> Mobile: +55 11 9 9638-9238 > > >> > > >> > > >> Openin - Your Partner in Data > > >> > > >> www.openin.com.br > > >> > > >> [image: Openin no Linkedin] [image: Openin no Facebook] > > >> <https://www.facebook.com/Openinbr/> [image: Openin no Instagram] > > >> <https://www.instagram.com/openinbr/> [image: Openin no Twitter] > > >> <https://twitter.com/OpeninBigData> [image: Openin no Youtube] > > >> <https://www.youtube.com/openinbigdata> > > >> > > > > > -- > > > > <https://www.openin.com.br> > > Patrocinadora Oficial do > > Pentaho Day 2019 > > Ricardo Gouvêa > > CEO > > [email protected] > > Mobile: +55 11 9 9638-9238 > > > Openin - Your Partner in Data > > www.openin.com.br > > [image: Openin no Linkedin] [image: Openin no Facebook] > <https://www.facebook.com/Openinbr/> [image: Openin no Instagram] > <https://www.instagram.com/openinbr/> [image: Openin no Twitter] > <https://twitter.com/OpeninBigData> [image: Openin no Youtube] > <https://www.youtube.com/openinbigdata> >
