juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Goddard <godd...@acm.org>
Subject Re: Split Juneau into separate named subprojects?
Date Sat, 19 Aug 2017 09:31:18 GMT
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?
> 


Mime
View raw message