+1
It would prefer such kind of structure.
Regards
JB
On 02/17/2016 01:00 AM, Olivier Lamy wrote:
Hi,
From a noob POV, I prefer the option with
guacamole/
guacamole-client/
guacamole-server/
guacamole-extensions/
etc....
We can even try to have a maven build executing the C build (well it's just
a matter of executing some command line :-) )
Pros: easy to understand for newbies
Cons: no separation of concerns a release will be a release of all (is it
really a problem?)
On 17 February 2016 at 10:12, Mike Jumper <[email protected]> wrote:
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
