juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Bognar <jamesbog...@apache.org>
Subject Re: Split Juneau into separate named subprojects?
Date Tue, 22 Aug 2017 14:24:09 GMT
More thinking....

We could partition the projects into the following:

   1. Juneau Marshall
   2. Juneau Marshall RDF (depends on 1)
   3. Juneau SVL (depends on 1)
   4. Juneau Config (depends on 1+3)
   5. Juneau DTOs (depends on 1)
   6. Juneau Server (depends on 1+3+4)
   7. Juneau Server JAX/RS (depends on 1+3+4+6)
   8. Juneau Client (depends on 1)
   9. Juneau Microservice (depends on 1+3+4+6+8)
   10. Juneau All

So basically just breaking core into Marshall, SVL, Config, and DTOs.  This
makes a lot of sense since each of these features can be used on their own
and it highlights the capabilities of the framework.



On Mon, Aug 21, 2017 at 10:27 PM, James Bognar <jamesbognar@apache.org>
wrote:

> Some clarification...
>
> I'm not really thinking about this as separate TLPs, but rather a single
> Juneau project with maybe named subprojects of some sort.
>
> The reason I bring it up is that Juneau Core is a complete module on its
> own.  It's been used frequently in the past minus the REST support.  But
> the name 'Core' gives the impression that it's only a substrate for the
> Server and Client modules....not something meant to be consumed on its own.
>
> Maybe just a better name for Core would be sufficient?
>
> btw, Server and Client are also independent modules.  There isn't anything
> in Client that ties it to Server, and vis-versa.  That's especially true
> since the addition of 3rd-party remoteable proxy support in Client.
>
> Microservice is a different beast though.  It ties everything together
> into a single 'package'.
>
>
> On Sat, Aug 19, 2017 at 3:22 PM John D. Ament <johndament@apache.org>
> wrote:
>
>> 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?
>> > >
>> >
>> >
>>
>

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