juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: Split Juneau into separate named subprojects?
Date Sat, 19 Aug 2017 19:21:57 GMT
I always see there being benefit to multiple git repos.  However, I'm not
sure that this would constitute a whole subproject.

On Sat, Aug 19, 2017 at 5:31 AM David Goddard <goddard@acm.org> wrote:

> I agree on the points of potential value of splitting and the timing.
> It may make sense to split for branding and documentation, but maybe not
> at this stage.
> In my view, the element that is most confusing in terms of project
> presentation and structure is the distinction between the microservice
> API and the other Juneau components (core, plus REST server/client).  If
> you look at the documentation (particularly
> http://juneau.incubator.apache.org/images/Components.png), you see a
> number of components: "core", "server", "client" and "microservice".
> The microservice component is different enough that it would be
> appropriate to brand separately.  The "core", "server" & "client"
> components fit together as a cohesive whole but are currently not really
> described as such.  Separating out the microservice part of the project
> might address some confusion (in my perception at least) over where the
> microservice API fits in:
>         Juneau == core, server, client
>         Anchorage == microservice API
> If you don't want to go as far as a separate named subproject, you could
> go halfway:
>         Juneau Platform == core, server, client
>         Juneau Microservices == microservice API
> Unless I have the wrong end of the stick and by "the REST subproject"
> James actually means to hive off Juneau Server, Client *and*
> Microservice to a subproject, leaving just Core as a standalone.  I'm
> not so sure of the value of this because I personally see the
> discontinuity as being between microservices and the rest rather than
> between core and the rest.  However, perhaps my view is coloured by not
> being a user of microservices myself (all my Juneau projects use core,
> server and/or client).
> David
> On 17/08/2017 21:53, Steve Blackmon wrote:
> > There are plenty of examples of TLPs that operate one or more
> sub-projects
> > - sometime each has a separate management committee and sometimes not.
> In
> > some cases sub-projects go on to become TLPs as well.
> >
> > I agree that juneau-core and juneau microservice are different enough and
> > each useful enough to be used, documented and branded stand-alone.
> > However, I would propose we focus on growing one community using all the
> > great capabilities in Juneau and the PMC can revisit sub-dividing into
> > sub-projects after graduation.
> >
> > Sent from Astro <https://www.helloastro.com> for Mac
> >
> > On Aug 10, 2017 at 8:37 AM, James Bognar <jamesbognar@apache.org> wrote:
> >
> >
> > I've been wondering this for a while and decided to mention it.
> >
> > Does it make sense to split up the Juneau Core and Juneau REST into
> > separate subprojects? (i.e. all managed together, but externally have
> > different names?) For example, the REST subproject would be rebranded as
> > Apache Anchorage, and Apache Juneau would refer to only the core
> > libraries. They would still belong to the same 'ecosystem' and release
> > schedules, but would just be called by two different names externally.
> >
> > The core libraries are often used independently of the REST libraries.
> The
> > current branding strongly suggests Juneau is a REST library when it's
> > really much more than that. The 'core' gives the impression that it's not
> > meant to be used as a standalone feature.
> >
> > Are there any precedents for a single project being reflected as multiple
> > TLP names?
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message