Enforced use of projects in docker container

[stwalkerster]

Currently we use OpenGrok 1.5.12 via the Docker image with the INDEXER_FLAGS environment variable set to -H -S -G -T 6. I understand based on this comment that our removal of the -P flag is no longer supported within the Docker container-based deployment, which essentially prevents us from upgrading to 1.6 or beyond.

As far as I can tell, this leaves us with a number of options to keep our current configuration which doesn't use projects:

• Maintain our own docker images to remove the -P flag again (probably by trying to retrofit the old shell scripts back in)
• Wait for disabling projects to be supported again in the container.

What is the overall plan for projects going forward - are projects going to be enforced? Is this removal of support limited to Docker? Are we likely to see the re-introduction of support for customising the indexer flags in a later release? I'd like to try and gauge whether it's worth us proceeding down the no-projects path any further, or if we would be better served by taking the leap and trying to figure out how to retrofit projects into our configuration (or repository layout is non-conducive to a sensible usage of projects, which is the main reason we've so far resisted it).

[vladak]

I always wondered how wide spread the project less use case is. This will serve as a sort of litmus test it seems. Why do you use project less setup ?

The project less support in OpenGrok itself is not going anywhere, even though it causes bigger complexity internally.

Possibly adding the support to the Docker start.py script back would not be too problematic and could be done in a clean way (environment variable).

[stwalkerster]

It's got a lot to do with how our development process works now and how it has worked historically. We use Perforce as the main VCS system, and all of our development is done on that Perforce server (syncing the code for OpenGrok is something we manage outside the container at the moment).

We maintain (too many) legacy branches of our software for different clients, and unfortunately the layout of the branches we have historically means there's no easy way to map it into a form where projects would be useful.

Take this vastly simplified example:

├── legacy
│   ├── anUnrelatedTool
│   ├── othersubdir
│   │   └── unrelatedproject
│   ├── subdirectory
│   │   ├── branch1
│   │   │   ├── gui
│   │   │   └── server
│   │   ├── branch2
│   │   │   ├── gui
│   │   │   └── server
│   │   └── branch3
│   │       ├── gui
│   │       └── server
│   └── vaguelyRelatedTool
├── libaries
│   ├── componentA
│   │   ├── main
│   │   ├── release1
│   │   └── release2
│   └── componentB
│       └── main
└── modern
    ├── devbranch1
    │   ├── gui
    │   └── server
    ├── devbranch2
    │   ├── gui
    │   └── server
    ├── release1
    │   ├── gui
    │   └── server
    └── release2
        ├── gui
        └── server

Projects don't seem to make sense here - what would a project actually be? A release or dev branch? A component such as "gui" or "server"? Also, searches across all areas of the repository are fairly common for us, or are easily limited by file path searches (eg: path:gui)

We can re-map directories as part of our checkout step prior to indexing, but then we completely lose the utility of knowing where a search result actually is in the source repository that we have now.

[vladak]

Understood, this makes sense. The fix is in progress.

[ahornace]

I was just thinking about this and what about having the whole p4 repo in one directory which would be considered as one "project"? Something like MyCompany Codebase? We could somehow simplify the UI that if there is just 1 project, then there would be no project selection etc. so the look would be similar.

IMHO dropping the project less setup is the way to go forward.