►
From YouTube: Working Group: January 10, 2023
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
it's
five
past,
so
let's
get
started,
looks
like
we're
already
recording.
So
that's
great
first
things.
First
welcome
back
everyone.
We
had
kind
of
a
light.
First
working
group
back
so
happy
New
Year
to
everyone
that
we
didn't
see
last
week.
A
I
hope
everybody
had
some
time
off
and
relaxed
and
didn't
think
about
build
packs
too
much
to
kick
us
off.
I
was
wondering
if
anybody
would
be
able
to
volunteer
to
be
a
note
taker
today.
A
A
All
right
looking
at
new
faces,
it
doesn't
look
like
anyone
new
has
joined
today,
so
we
can
move
on
so
I'll
share
my
screen
for
looking
at
the
outstanding
rfcs.
A
B
Yeah
I
had
some
discussions
with
Daniel
this
morning
and
there's
still
some
technical
challenges
that
we
need
to
overcome
and
he
suggested
we
take
a
a
another
approach
and
actually
opened
up
another
RFC
to
create
a
Java,
build
path,
specific
Builder,
so
I'm
working
on
that
RFC,
hopefully
I'll
have
that
done
before
the
next
work
group
meeting.
But
until
that
result,
this
one's
not
going
to
move
any
further
I,
don't
think.
B
I'm
planning
on
leaving
it
open
because
it
still
needs
this
still
needs
to
be
resolved.
I
mean
this
is
my
ultimate
goal
is
to
have
additional
jvms
in
available
to
the
Java
to
build
packs,
and
one
way
to
do
that
is
to
create
a
Java,
specific
Builder.
A
A
C
A
B
C
Like
for
for
just
for
for
context,
the
the
decision
that
we
took
is
we
actually
have
a
an
own
builder
just
having
the
two
different
jvms
that
sap
produces
one
for
Java,
eight
and
the
other
for
11
and
17
and
decided
to
go
that
way,
and
it
works
pretty
pretty
nicely
I
mean
you,
you
do
get
some
responsibilities
with
that,
but
on
the
other
hand,
you
really
have
some
some
tight
control
over
other
things
like
for
us
now.
C
This
means
we
actually
produce
kind
of
everything
we
produce
our
own
stack,
which
is
slightly
bigger
than
tiny.
We
produce
our
own
Java
meta
buildback,
because
we
don't
need
lightning
and
SBT
and
other
build
tools
that
are
available
in
the
in
the
meta,
build
pack
and
we
finally
package
the
Builder,
and
it
is
okay
in
terms
of
efforts,
and
it's
rather
easy
to
be
automated.
Now.
B
So
my
main
motivation
is
to
make
it
easier
to
use
the
open,
the
eclipse,
open,
j9,
jvm
and
I,
just
kind
of
felt
like
the
way
we
added
additional
Java
app
servers
to
adopt
a
build
pack
and
by
just
defining
an
environment
variables.
So
in
that
that's
easy
to
do
so.
That's
why
I
wrote
the
the
initial
RFC
to
just
make
it
easier
to
choose
any
jvm
you
want,
and
that
would
be
available
to
everybody.
B
But
I
understand
the
the
work
you
have
done.
I
just
don't
know
if
we,
if
we
want
to
invest
that
sort
of
time
and
effort
and
energy
to
create
our
own
exact
builders.
C
All
right,
it's
just
I,
guess
it's
the
the
layer
limit
right
that
makes
this
not
applicable
for
the
standard
Builder
right,
because
otherwise
yeah,
of
course,
that
would
be
a
that
would
be
an
easy
thing
to
just
say:
let's
just
add
them
get
an
environment
variable,
but
there's
the
the
catch
is
the
127
layers,
I
guess.
B
Right
and
yeah
that's
a
technical
challenge
that
I've
been
referring
to
that
layer
limit
and
I
I
kind
of
did
a
little
bit
of
prototype,
creating
a
a
Java
composite,
build
pack
Builder
with
all
the
jvms
was
only
like
44
layers.
B
B
Sure
I
haven't
finished:
writing
it
yet,
but
yeah.
No,
it's
it's!
It's
basically
just
to
create
a
Java,
Builder,
specific
or
Java
buildback,
a
specific
Builder
that'll.
Just
have
the
bill
tax
dated
by
the
Java
composite
Builder
not
have
any
idea
that
family
language
is
stuff
in
there
and
that's
primarily
to
get
by
the
the
layered
limit
that
prevents
us
from
making
adding
new,
build
packs
to
the
to
the
current
builders.
A
C
I
guess
I
could
but
there's
nobody
else
there
from
the
Java
maintenance.
It
doesn't
really
look
like
it's
much
appreciated
the
the
idea
is
to
have
some
more
loose
coupling
in
how
this
gets
decided.
So
there
are
some
indicators
for
how
you
could
actually
realize
what
version
of
java
is
needed,
and
this
is
about
opening
up
the
build
plan
logic
to
something
where
this
could
easily
be
done.
C
Just
imagine
a
maven
build
pack
realizing
from
the
maven
Palm
that
a
certain
Java
version
is
set
and
then
just
requesting
this
specific
version,
instead
of
just
relying
on
the
default
I
think
it
it
lately
came
up
when
spring
boot
3
came
out
and
doesn't
work
with
the
default
Java
version
in
the
Java
build
Tech,
but
it
seems
like
Daniel
thinks
this
is
adding
too
much
complexity.
C
To
be
honest,
I
still
have
to
sync
with
the
with
from
my
team
in
in
terms
of
an
answer
to
that,
and
if
we
can
actually
manage
to
convince
the
Java
main
heinous
that
this
might
still
be
in
good
enough
trade-off
in
terms
of
complexity
and
others.
I
I
I
really
have
to
read
more
on
that
I.
Don't
I,
don't
quite
get
the
complexity.
That
Daniel
sees.
Maybe
it's
there.
It's
just
lack
of
experience,
but
that's
the
that's.
C
If,
if
it
finds
maven-specific
metadata
in
a
jar
manifest,
then
it
just
picks
the
right
version
so
to
save,
but
that's
pretty
specific
and
it's
I
think
in
the
wrong
place,
but
there's
a
bit
of
disagreement
about
right
and
wrong
places
here.
A
Got
it
thank
you
for
that?
It
sounds
pretty
Java
specific,
but
is
there.
C
Well,
the
the
only
thing
but
I
don't
know
enough
about
the
others.
The
only
thing
would
be.
If
something
like
that
mechanism,
it
actually
has
a
precedent
in
the
potato
project.
So
if
there
would
be
in
the
note
or
I,
don't
know,
Ruby
ecosystem,
if
there
would
be
something
where,
where
such
a
mechanism
exists
and
Works
nicely
and
and
like
or
you
have
some
experience
with
the
complexity
that
it
resulted
with
like
result
could
also
be
that,
yes,
it
exists,
but
we
shouldn't
have
done
it.
A
C
A
C
B
I
certainly
got
bit
by
the
spring
boot
problem,
so
definitely
would
have
been
nice
to
be
able
to
specify
another
version
of
java.
So
I
do
see
your
point
and
I
I
would
find
this
very
useful
and
I
could
have
comments
too.
So
yeah
you.
C
Can
you
can
add
it's
like
in
the
in
the
end,
Daniel
actually
started
collecting
use
cases
that
are
currently
not
supported
and
asks
for
more
if
there
are
more
and
then
have
a
more
guided
decision
on
if
it's
worth
the
effort
or
if
there
are
solutions,
other
solutions
to
it.
The
spring
boot
thing
will
probably
quickly
resolve
like
we
are
working
on
an
RFC
to
bump
the
default
version
to
17
and
actually
probably
go
in
one
step
further
and
establish
a
process
of.
When
are
we
going
to
bump
it
the
next
time?
C
So
maybe
that
resolves
most
of
it,
because
I
guess
the
spring
boot
Community
Waits
a
little
bit
until
they
require
newer
versions
of
java.
But
it's
more
like
it's
more
like
Band-Aid
from
my
point
of
view
yeah,
but
it
will
work
right.
Setting
the
default
version
to
17
will
solve
the
spring
boot
problem.
B
A
Okay,
we
have
another
Java
RFC
from
David,
who
is
not
here,
but
he's
wondering
if
anybody
has
any
context
on
this
RFC.
A
C
It's
a
it's
a
bit
triggered
by
our
efforts
to
to
provide
some
integration
tests
for
for
the
Java
build
packs,
which
we
run
on
our
end,
but
I
think
the
Java
build
pack
got
bitten
one
and
once
or
twice
already
in
the
past,
by
some
some
things
that
were
unexpected.
Some
built
packs
behaving
strangely,
requiring
certain
things
and
then
I
think
there
were
some
things
detecting
too
freely
or
not.
C
Detecting
and
one
of
the
major
concerns
from
Daniel
and
David
were
that
the
execution
times
are
quite
long
and
there
are
a
lot
of
PRS.
So
I
think
that's
the
root
of
of
this
idea
of
having
a
kind
of
Branch
for
all
these
PRS.
So
you
can
run
the
the
integration
tests
on
the
merge
into
the
main
branch
instead
of
for
each
and
every
PR,
so
I
think
that's
the
idea
behind
this
I
threw
in
some
other
ideas,
for
that
could
be
even
alternative.
C
Solutions
based
on
renovate
but
I
I
agree
with
the
with
Daniel
like.
If
that
is
not
a
lot
of
effort.
But
it's
a
quick
step
forward
would
allow
to
merge
the
integration
tests
that
are
in
Flight.
As
a
PR,
and
we
could
think
as
a
as
a
project
about
something
like
renovate,
where
I
guess,
we
should
at
some
point
in
time
open
an
RFC
to
propose
something
for
the
whole
project
and
throw
in
some
some
of
our
experience
with
renovate
yeah.
A
Right,
it's
coming
back
to
me
now
we
did
discuss
this
last
week.
We
were
saying,
as
this
comment
says
over
here,
be
a
great
opportunity
to
align
in
the
project
between
Java
and
non-java.
So
I
think.
We've
said
in
the
past
that
this
idea
of
using
renovate
is
pretty
interesting,
so
definitely
open
to
seeing
an
RFC
about
that.
C
We
use
it,
we
we
use
it
for
everything,
starting
with
the
stack
actually
like
we
get
bumps
for
all
the
packages
like
there's
a
there's,
a
data
source
called
ripology
where
they
actually
collect
from
a
bunch
of
distributions
the
package
meter
data,
so
we
actually
even
use
it
for
our
stack
description
for
the
dependencies
in
between.
So
all
the
meta
built
back
to
build
back
dependencies
and
all
these
these
things
works
pretty
nicely
all.
A
A
Okay
and
then
the
last
one
we
have
here
is
a.net
core
specific
RFC
from
forest
and
Forest.
Let
me
know
he
can't
join
today,
so
I
haven't
actually
had
a
chance
to
read
through
the
RFC,
so
I
won't
speak
too
much
to
it,
but
I
know
it's
essentially.
A
We've
recently
introduced
a
new
build
pack
into
the.net
core
ecosystem.net
core
asp.net
runtime,
which
replaces
the.net
core
runtime
and
the.net
core
asp.net
separate,
build
packs,
and
so
what
Forest
is
proposing
here,
I
believe,
is
to
remove
the.net
core
runtime
and
asp.net,
build
packs
and
update
the
new
build
pack
that
we
have
to
adhere
to
the
old
and
the
new
build
plan
API,
so
that
we
can
give
users
a
migration
path
if
they
have
other
build
packs
that
were
consuming
the.net,
core
runtime
and
asp.net,
build
packs
with
those
provides
and
requires
so
that
we
can
solely
move
people
away
from
that
workflow
and
using
the
new
set
of
build
packs
or
the
new
build
pack.
A
Foreign
am
I
hearing
anything
else
about
this
one,
so
I
think
we
are
done
talking
about
all
the
open
rfcs
and
we
can
move
on.
The
next
thing
would
be
CNB
updates
and
questions.
I,
don't
think
we
had
any
last
week,
but
are
there
any
updates?
People
are
aware
of
from
the
cognitive,
build
packs
out
of
things.
A
Right
does
not
sound
like
it,
so
we
can
move
on
from
a
project
update
point
of
view.
I
don't
see
anything
here.
We
are
more
or
less
done
with
our
dependency
management.
A
Overhaul
I
think
we
came
back
from
the
end
of
the
year
break
and
we
were
just
finishing
up
some
small
touches
but
I
think
for
the
most
part,
all
of
our
main
dependencies
have
been
moved
over
we're
now
doing
some
polishing,
like
spinning
down
workflows
on
the
depth
server
refactoring
a
couple
of
compilation
that
we
have
I
think
for
PHP
and
maybe
another
dependency
that
were
kind
of
rough,
that
we
kind
of
rushed.
A
So
we
could
get
the
tendency
stuff
over
the
line,
so
we're
just
doing
some
finishing
touches,
but
all
of
the
dependencies
in
the
project
for
the
non-java
build
packs
should
now
be
off
the
depth
server,
which
is
great
I.
Think
besides,
that
I
don't
have
any
major
project
updates,
but
if
anybody
else
has
one
that
they
want
to
share
feel
free.