After attempting the guacamole/{client,server} structure, things seem
rather confusing. I'm not sure I like how this structure feels,
particularly from the perspective of a user who will often have modest
experience with building things from source. Imagine that a user
clones the repository, like they are used to doing, lists its contents
and...
$ cd guacamole/
$ ls
client README.md server
$
Instant confusion. There is no build file in the root of the
repository; merely two solitary directories and a README which the
user must now *gulp* read. The structure works, but I think it's very
alien compared to other projects and past experience. Further, the
renaming such that the initial "guacamole-" prefix is no longer
present ends up being inconsistent with the way guacamole-client is
structured:
$ ls client/
CONTRIBUTING guacamole guacamole-ext project-assembly.xml
doc guacamole-common LICENSE README
extensions guacamole-common-js pom.xml
$
It would be nice to adopt a structure which is not only familiar but
consistent. This structure doesn't seem to provide either of those
characteristics.
What if we continue using guacamole-client as the overall parent, and
instead include guacamole-server as a subdirectory therein (even
though it's not a Maven project):
$ cd guacamole/
$ ls
CONTRIBUTING guacamole guacamole-ext pom.xml
doc guacamole-common guacamole-server project-assembly.xml
extensions guacamole-common-js LICENSE README.md
$
Perhaps a little less daunting/alien? Everything here builds
automatically via Maven, with the sole exception being
"guacamole-server" which is at least in a predictable and consistent
location with respect to the other subprojects. The overall structure
ends up being:
guacamole/
extensions/
guacamole-auth-jdbc/
guacamole-auth-ldap/
guacamole-auth-noauth/
guacamole/
guacamole-common/
guacamole-common-js/
guacamole-ext/
guacamole-server/
Thoughts?
On Tue, Feb 16, 2016 at 11:43 AM, Mike Jumper <[email protected]> wrote:
> OK, then. Unless there are any further ideas (or objections), I will prepare
> the import with the following structure:
>
> guacamole/
> client/
> server/
>
> and we can continue molding the repo from there with an overall README.md,
> as well as other required files.
>
> Thanks, all.
>
> - Mike
>
> On Feb 12, 2016 12:38 AM, "Jean-Baptiste Onofré" <[email protected]> wrote:
>>
>> Good point, I forgot about this point.
>>
>> At least a small README.md ;)
>>
>> Regards
>> JB
>>
>> On 02/12/2016 09:37 AM, Mike Jumper wrote:
>>>
>>> On Feb 11, 2016 9:10 PM, "Jean-Baptiste Onofré" <[email protected]> wrote:
>>>>
>>>>
>>>> +1
>>>>
>>>> but I would add a parent pom to simplify the way of building.
>>>>
>>>
>>> A parent pom wouldn't work for the combined repository because
>>> guacamole-server is a native C project. It is built using GNU Autotools,
>>> not Maven like guacamole-client.
>>>
>>> To clarify:
>>>
>>> guacamole-server is the parent project of six subprojects (and a few
>>> convenience libraries) written in C99, all of which build using GNU
>>> Autotools:
>>>
>>> * guacd
>>> * libguac
>>> * libguac-client-rdp
>>> * libguac-client-ssh
>>> * libguac-client-telnet
>>> * libguac-client-vnc
>>>
>>> Building guacamole-server builds and installs each of those subprojects
>>> automatically (through a traditional recursive build).
>>>
>>> guacamole-client is the parent project of seven Java / JavaScript
>>> subprojects, and is already set up with a proper parent pom:
>>>
>>> * guacamole
>>> * guacamole-auth-jdbc
>>> * guacamole-auth-ldap
>>> * guacamole-auth-noauth
>>> * guacamole-common
>>> * guacamole-common-js
>>> * guacamole-ext
>>>
>>> Building guacamole-client builds all subprojects due to the existing
>>> parent
>>> pom.
>>>
>>> - Mike
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [email protected]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
