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
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
