You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juneau.apache.org by James Bognar <ja...@apache.org> on 2017/08/10 13:37:22 UTC
Split Juneau into separate named subprojects?
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?
Re: Split Juneau into separate named subprojects?
Posted by James Bognar <ja...@apache.org>.
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 <ja...@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 <jo...@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 <go...@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 <ja...@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?
>> > >
>> >
>> >
>>
>
Re: Split Juneau into separate named subprojects?
Posted by James Bognar <ja...@apache.org>.
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 <jo...@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 <go...@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 <ja...@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?
> > >
> >
> >
>
Re: Split Juneau into separate named subprojects?
Posted by "John D. Ament" <jo...@apache.org>.
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 <go...@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 <ja...@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?
> >
>
>
Re: Split Juneau into separate named subprojects?
Posted by David Goddard <go...@acm.org>.
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 <ja...@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?
>
Re: Split Juneau into separate named subprojects?
Posted by Steve Blackmon <sb...@apache.org>.
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 <ja...@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?