10:13 a.m.
This design proposal covers the inter related tasks of splitting up the
build, and also creating a build/provisioning system that will make it
easy for end users to consume Wildfly. Apologies for the length, but it
is a complex topic. The first part explains what we are trying to
achieve, the second part covers how we are planning to actually
implement it.
The Wildfly code base is over a million lines of java and has a test
suite that generally takes close to two hours to run in its entirety.
This makes the project very unwieldily, and the large size and slow test
suite makes development painful.
To deal with this issue we are going to split the Wildfly code base into
smaller discrete repositories. The planned split is as follows:
- Core: just the WF core
- Arquillian: the arquillian adaptors
- Servlet: a WF distribution with just Undertow, and some basic EE
functionality such as naming
- EE: All the core EE related functionality, EJB's, messaging etc
- Clustering: The core clustering functionality
- Console: The management console
- Dist: brings all the pieces together, and allows us to run all tests
against a full server
Note that this list is in no way final, and is open to debate. We will
most likely want to split up the EE component at some point, possibly
along some kind of web profile/full profile type split.
Each of these repos will build a feature pack, which will contain the
following:
- Feature specification / description
- Core version requirements (e.g. WF10)
- Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
- module.xml files for all required modules that are not provided by
other features
- References to maven GAV's for jars (possibly a level of indirection
here, module.xml may just contain the group and artifact, and the
version may be in a version.properties file to allow it to be easily
overridden)
- Default configuration snippet, subsystem snippets are packaged in the
subsystem jars, templates that combine them into config files are part
of the feature pack.
- Misc files (e.g. xsds) with indication of where on path to place them
Note that a feature pack is not a complete server, it cannot simply be
extracted and run, it first needs to be assembled into a server by the
provisioning tool. The feature packs also just contain references to the
maven GAV of required jars, they do not have the actual jars in the pack
(which should make them very lightweight).
Feature packs will be assembled by the WF build tool, which is just a
maven plugin that will replace our existing hacky collection of ant
scripts.
Actual server instances will be assembled by the provisioning tool,
which will be implemented as a library with several different front
ends, including a maven plugin and a CLI (possibly integrated into our
existing CLI). In general the provisioning tool will be able to
provision three different types of servers:
- A traditional server with all jar files in the distribution
- A server that uses maven coordinates in module.xml files, with all
artifacts downloaded as part of the provisioning process
- As above, but with artifacts being lazily loaded as needed (not
recommended for production, but I think this may be useful from a
developer point of view)
The provisioning tool will work from an XML descriptor that describes
the server that is to be built. In general this information will include:
- GAV of the feature packs to use
- Filtering information if not all features from a pack are required
(e.g. just give me JAX-RS from the EE pack. In this case the only
modules/subsystems installed from the pack will be modules and subystem
that JAX-RS requires).
- Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
which will allow community users to easily upgrade individual components.
- Configuration changes that are required (e.g. some way to add a
datasource to the assembled server). The actual form this will take
still needs to be decided. Note that this need to work on both a user
level (a user adding a datasource) and a feature pack level (e.g. the
JON feature packing adding a required data source).
- GAV of deployments to install in the server. This should allow a
server complete with deployments and the necessary config to be
assembled and be immediately ready to be put into service.
Note that if you just want a full WF install you should be able to
provision it with a single line in the provisioning file, by specifying
the dist feature pack. We will still provide our traditional download,
which will be build by the provisioning tool as part of our build process.
The provisioning tool will also be able to upgrade servers, which
basically consists of provisioning a new modules directory. Rollback is
provided by provisioning from an earlier version of provisioning file.
When a server is provisioned the tool will make a backup copy of the
file used, so it should always be possible to examine the provisioning
file that was used to build the current server config.
Note that when an update is performed on an existing server config will
not be updated, unless the update adds an additional config file, in
which case the new config file will be generated (however existing
config will not be touched).
Note that as a result of this split we will need to do much more
frequent releases of the individual feature packs, to allow the most
recent code to be integrated into dist.
Implementation Plan
The above changes are obviously a big job, and will not happen
overnight. They are also highly likely to conflict with other changes,
so maintaining a long running branch that gets rebased is not a
practical option. Instead the plan it to perform the split in
incremental changes. The basic steps are listed below, some of which can
be performed in parallel.
1) Using the initial implementation of my build plugin (in my
wildfly-build-plugin branch) we split up the server along the lines
above. The code will all stay in the same repo, however the plugin will
be used to build all the individual pieces, which are then assembled as
part of the final build process. Note that the plugin in its current
form does both the build and provision step, and the pack format is
produces is far from the final pack format that we will want to use.
2) Split up the test suite into modules based on the features that they
test. This will result in several smaller modules in place of a single
large one, which should also be a usability improvement as individual
tests will be be faster to run, and run times for all tests in a module
should be more manageable.
3) Split the core into into own module.
4) Split everything else into its own module. As part of this step we
need to make sure we still have the ability to run all tests against the
full server, as well as against the cut down feature pack version of the
server.
5) Focus on the build an provisioning tool, to implement all the
features above, and to finalize the WF pack format.
I think that just about covers it. There are still lots of nitty gritty
details that need to be worked out, however I think this covers all the
main aspects of the design. We are planning on starting work on this
basically immediately, as we want to get this implemented as early in
the WF9 cycle as possible.
Stuart
11:42 a.m.
On 06/10/2014 08:13 AM, Stuart Douglas wrote:
This design proposal covers the inter related tasks of splitting up
the
build, and also creating a build/provisioning system that will make it
easy for end users to consume Wildfly. Apologies for the length, but it
is a complex topic. The first part explains what we are trying to
achieve, the second part covers how we are planning to actually
implement it.
The Wildfly code base is over a million lines of java and has a test
suite that generally takes close to two hours to run in its entirety.
This makes the project very unwieldily, and the large size and slow test
suite makes development painful.
To deal with this issue we are going to split the Wildfly code base into
smaller discrete repositories. The planned split is as follows:
- Core: just the WF core
- Arquillian: the arquillian adaptors
- Servlet: a WF distribution with just Undertow, and some basic EE
functionality such as naming
- EE: All the core EE related functionality, EJB's, messaging etc
- Clustering: The core clustering functionality
- Console: The management console
- Dist: brings all the pieces together, and allows us to run all tests
against a full server
Note that this list is in no way final, and is open to debate. We will
most likely want to split up the EE component at some point, possibly
along some kind of web profile/full profile type split.
Each of these repos will build a feature pack, which will contain the
following:
- Feature specification / description
- Core version requirements (e.g. WF10)
- Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
- module.xml files for all required modules that are not provided by
other features
- References to maven GAV's for jars (possibly a level of indirection
here, module.xml may just contain the group and artifact, and the
version may be in a version.properties file to allow it to be easily
overridden)
- Default configuration snippet, subsystem snippets are packaged in the
subsystem jars, templates that combine them into config files are part
of the feature pack.
- Misc files (e.g. xsds) with indication of where on path to place them
Note that a feature pack is not a complete server, it cannot simply be
extracted and run, it first needs to be assembled into a server by the
provisioning tool. The feature packs also just contain references to the
maven GAV of required jars, they do not have the actual jars in the pack
(which should make them very lightweight).
Feature packs will be assembled by the WF build tool, which is just a
maven plugin that will replace our existing hacky collection of ant
scripts.
Actual server instances will be assembled by the provisioning tool,
which will be implemented as a library with several different front
ends, including a maven plugin and a CLI (possibly integrated into our
existing CLI). In general the provisioning tool will be able to
provision three different types of servers:
- A traditional server with all jar files in the distribution
- A server that uses maven coordinates in module.xml files, with all
artifacts downloaded as part of the provisioning process
- As above, but with artifacts being lazily loaded as needed (not
recommended for production, but I think this may be useful from a
developer point of view)
The provisioning tool will work from an XML descriptor that describes
the server that is to be built. In general this information will include:
- GAV of the feature packs to use
- Filtering information if not all features from a pack are required
(e.g. just give me JAX-RS from the EE pack. In this case the only
modules/subsystems installed from the pack will be modules and subystem
that JAX-RS requires).
- Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
which will allow community users to easily upgrade individual components.
- Configuration changes that are required (e.g. some way to add a
datasource to the assembled server). The actual form this will take
still needs to be decided. Note that this need to work on both a user
level (a user adding a datasource) and a feature pack level (e.g. the
JON feature packing adding a required data source).
- GAV of deployments to install in the server. This should allow a
server complete with deployments and the necessary config to be
assembled and be immediately ready to be put into service.
Note that if you just want a full WF install you should be able to
provision it with a single line in the provisioning file, by specifying
the dist feature pack. We will still provide our traditional download,
which will be build by the provisioning tool as part of our build process.
The provisioning tool will also be able to upgrade servers, which
basically consists of provisioning a new modules directory. Rollback is
provided by provisioning from an earlier version of provisioning file.
When a server is provisioned the tool will make a backup copy of the
file used, so it should always be possible to examine the provisioning
file that was used to build the current server config.
Note that when an update is performed on an existing server config will
not be updated, unless the update adds an additional config file, in
which case the new config file will be generated (however existing
config will not be touched).
Note that as a result of this split we will need to do much more
frequent releases of the individual feature packs, to allow the most
recent code to be integrated into dist.
Implementation Plan
The above changes are obviously a big job, and will not happen
overnight. They are also highly likely to conflict with other changes,
so maintaining a long running branch that gets rebased is not a
practical option. Instead the plan it to perform the split in
incremental changes. The basic steps are listed below, some of which can
be performed in parallel.
1) Using the initial implementation of my build plugin (in my
wildfly-build-plugin branch) we split up the server along the lines
above. The code will all stay in the same repo, however the plugin will
be used to build all the individual pieces, which are then assembled as
part of the final build process. Note that the plugin in its current
form does both the build and provision step, and the pack format is
produces is far from the final pack format that we will want to use.
I think the
plugin should be a separate project to it's not tied to the
same release cycle. There's already a groupId of org.wildfly.plugins
where the wildfly-maven-plugin exists. Maybe it should use the same groupId.
This would also allow other projects to use the plugin sooner and start
to assemble their own runtime. It might help determine some issues
quicker as well.
2) Split up the test suite into modules based on the features that they
test. This will result in several smaller modules in place of a single
large one, which should also be a usability improvement as individual
tests will be be faster to run, and run times for all tests in a module
should be more manageable.
3) Split the core into into own module.
4) Split everything else into its own module. As part of this step we
need to make sure we still have the ability to run all tests against the
full server, as well as against the cut down feature pack version of the
server.
5) Focus on the build an provisioning tool, to implement all the
features above, and to finalize the WF pack format.
I think that just about covers it. There are still lots of nitty gritty
details that need to be worked out, however I think this covers all the
main aspects of the design. We are planning on starting work on this
basically immediately, as we want to get this implemented as early in
the WF9 cycle as possible.
Stuart
Overall I think this plan is great. I personally can't wait until we at
least have a true core server to use.
FWIW IBM uses the term "feature pack" for WebSphere Application Server
extras. Though they tend to be huge and not easy to apply.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat
11:49 a.m.
I think the plugin should be a separate project to it's not tied
to the
same release cycle. There's already a groupId of org.wildfly.plugins
where the wildfly-maven-plugin exists. Maybe it should use the same groupId.
This would also allow other projects to use the plugin sooner and start
to assemble their own runtime. It might help determine some issues
quicker as well.
I agree, although initially I want to keep it in the WF code base, just
so we do not need to do a new release every day while it is evolving
rapidly.
Overall I think this plan is great. I personally can't wait until
we at
least have a true core server to use.
FWIW IBM uses the term "feature pack" for WebSphere Application Server
extras. Though they tend to be huge and not easy to apply.
If anyone has any better names I would love to hear them.
Stuart
>
>
>
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:10 p.m.
On 6/10/14, 11:49 AM, Stuart Douglas wrote:
>
> FWIW IBM uses the term "feature pack" for WebSphere Application Server
> extras. Though they tend to be huge and not easy to apply.
If anyone has any better names I would love to hear them.
I don't consider the fact that someone else uses the same term for a
similar thing to be a negative. Unless that thing isn't really similar
at all.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
12:30 p.m.
On 06/11/2014 10:10 AM, Brian Stansberry wrote:
--
James R. Perkins
JBoss by Red Hat
On 6/10/14, 11:49 AM, Stuart Douglas wrote:
>> FWIW IBM uses the term "feature pack" for WebSphere Application Server
>> extras. Though they tend to be huge and not easy to apply.
> If anyone has any better names I would love to hear them.
>
I don't consider the fact that someone else uses the same term for a
similar thing to be a negative. Unless that thing isn't really similar
at all.
Agreed I just wanted to point it out. I was mainly a bit concerned with
how converted devs might look at it. I don't know what most users think,
but I know when I saw WAS needed a feature pack to do what I was doing I
just would skip it unless I really needed it. The WAS feature packs were
usually huge and I never liked the way they applied.
That said, it's also a positive being the same name for converts as they
know what it means.
2:17 p.m.
On 06/10/2014 11:13 AM, Stuart Douglas wrote:
This design proposal covers the inter related tasks of splitting up
the
build, and also creating a build/provisioning system that will make it
easy for end users to consume Wildfly. Apologies for the length, but it
is a complex topic. The first part explains what we are trying to
achieve, the second part covers how we are planning to actually
implement it.
The Wildfly code base is over a million lines of java and has a test
suite that generally takes close to two hours to run in its entirety.
This makes the project very unwieldily, and the large size and slow test
suite makes development painful.
To deal with this issue we are going to split the Wildfly code base into
smaller discrete repositories. The planned split is as follows:
- Core: just the WF core
- Arquillian: the arquillian adaptors
- Servlet: a WF distribution with just Undertow, and some basic EE
functionality such as naming
- EE: All the core EE related functionality, EJB's, messaging etc
- Clustering: The core clustering functionality
- Console: The management console
- Dist: brings all the pieces together, and allows us to run all tests
against a full server
Any concerns about circular dependencies that could impact the build?
For example, EE depends on Clustering and Clustering depends on EE.
Adding separate system level interfaces for each module might help, so
that Clustering doesn't depend directly on the EE module and the EE
module doesn't depend on Clustering.
Note that this list is in no way final, and is open to debate. We will
most likely want to split up the EE component at some point, possibly
along some kind of web profile/full profile type split.
Each of these repos will build a feature pack, which will contain the
following:
- Feature specification / description
- Core version requirements (e.g. WF10)
- Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
- module.xml files for all required modules that are not provided by
other features
- References to maven GAV's for jars (possibly a level of indirection
here, module.xml may just contain the group and artifact, and the
version may be in a version.properties file to allow it to be easily
overridden)
- Default configuration snippet, subsystem snippets are packaged in the
subsystem jars, templates that combine them into config files are part
of the feature pack.
- Misc files (e.g. xsds) with indication of where on path to place them
Note that a feature pack is not a complete server, it cannot simply be
extracted and run, it first needs to be assembled into a server by the
provisioning tool. The feature packs also just contain references to the
maven GAV of required jars, they do not have the actual jars in the pack
(which should make them very lightweight).
Feature packs will be assembled by the WF build tool, which is just a
maven plugin that will replace our existing hacky collection of ant
scripts.
Actual server instances will be assembled by the provisioning tool,
which will be implemented as a library with several different front
ends, including a maven plugin and a CLI (possibly integrated into our
existing CLI). In general the provisioning tool will be able to
provision three different types of servers:
- A traditional server with all jar files in the distribution
- A server that uses maven coordinates in module.xml files, with all
artifacts downloaded as part of the provisioning process
- As above, but with artifacts being lazily loaded as needed (not
recommended for production, but I think this may be useful from a
developer point of view)
The provisioning tool will work from an XML descriptor that describes
the server that is to be built. In general this information will include:
- GAV of the feature packs to use
- Filtering information if not all features from a pack are required
(e.g. just give me JAX-RS from the EE pack. In this case the only
modules/subsystems installed from the pack will be modules and subystem
that JAX-RS requires).
- Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
which will allow community users to easily upgrade individual components.
- Configuration changes that are required (e.g. some way to add a
datasource to the assembled server). The actual form this will take
still needs to be decided. Note that this need to work on both a user
level (a user adding a datasource) and a feature pack level (e.g. the
JON feature packing adding a required data source).
- GAV of deployments to install in the server. This should allow a
server complete with deployments and the necessary config to be
assembled and be immediately ready to be put into service.
Note that if you just want a full WF install you should be able to
provision it with a single line in the provisioning file, by specifying
the dist feature pack. We will still provide our traditional download,
which will be build by the provisioning tool as part of our build process.
The provisioning tool will also be able to upgrade servers, which
basically consists of provisioning a new modules directory. Rollback is
provided by provisioning from an earlier version of provisioning file.
When a server is provisioned the tool will make a backup copy of the
file used, so it should always be possible to examine the provisioning
file that was used to build the current server config.
Note that when an update is performed on an existing server config will
not be updated, unless the update adds an additional config file, in
which case the new config file will be generated (however existing
config will not be touched).
Note that as a result of this split we will need to do much more
frequent releases of the individual feature packs, to allow the most
recent code to be integrated into dist.
Implementation Plan
The above changes are obviously a big job, and will not happen
overnight. They are also highly likely to conflict with other changes,
so maintaining a long running branch that gets rebased is not a
practical option. Instead the plan it to perform the split in
incremental changes. The basic steps are listed below, some of which can
be performed in parallel.
1) Using the initial implementation of my build plugin (in my
wildfly-build-plugin branch) we split up the server along the lines
above. The code will all stay in the same repo, however the plugin will
be used to build all the individual pieces, which are then assembled as
part of the final build process. Note that the plugin in its current
form does both the build and provision step, and the pack format is
produces is far from the final pack format that we will want to use.
2) Split up the test suite into modules based on the features that they
test. This will result in several smaller modules in place of a single
large one, which should also be a usability improvement as individual
tests will be be faster to run, and run times for all tests in a module
should be more manageable.
3) Split the core into into own module.
4) Split everything else into its own module. As part of this step we
need to make sure we still have the ability to run all tests against the
full server, as well as against the cut down feature pack version of the
server.
5) Focus on the build an provisioning tool, to implement all the
features above, and to finalize the WF pack format.
I think that just about covers it. There are still lots of nitty gritty
details that need to be worked out, however I think this covers all the
main aspects of the design. We are planning on starting work on this
basically immediately, as we want to get this implemented as early in
the WF9 cycle as possible.
Stuart
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:55 p.m.
On Tue, Jun 10, 2014 at 9:17 PM, Scott Marlow <smarlow(a)redhat.com> wrote:
Any concerns about circular dependencies that could impact the
build?
For example, EE depends on Clustering and Clustering depends on EE.
EE does *not* depend on clustering and if does it is a bug that needs to be
fixed.
But in any case your question is valid and I don't think we will address
this in phase one
as most of "features" just build on top of another there is no mix and
match yet.
But when we do have scenarios like this it should be quite easily
addressed, just resolve complete graph and if we get a loop, we fail the
build.
--
tomaz
3:21 p.m.
Any concerns about circular dependencies that could impact the build?
For example, EE depends on Clustering and Clustering depends on EE.
As part of the split we are going to have to address some issues with
inter module dependencies. Circular references in general should not be
too much of a problem, I think the main issue will be modules depending
on things that they should not, and we will have to do some refactoring
to fix.
Stuart
Adding separate system level interfaces for each module might help, so
that Clustering doesn't depend directly on the EE module and the EE
module doesn't depend on Clustering.
>
> Note that this list is in no way final, and is open to debate. We will
> most likely want to split up the EE component at some point, possibly
> along some kind of web profile/full profile type split.
>
> Each of these repos will build a feature pack, which will contain the
> following:
>
> - Feature specification / description
> - Core version requirements (e.g. WF10)
> - Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
> - module.xml files for all required modules that are not provided by
> other features
> - References to maven GAV's for jars (possibly a level of indirection
> here, module.xml may just contain the group and artifact, and the
> version may be in a version.properties file to allow it to be easily
> overridden)
> - Default configuration snippet, subsystem snippets are packaged in the
> subsystem jars, templates that combine them into config files are part
> of the feature pack.
> - Misc files (e.g. xsds) with indication of where on path to place them
>
> Note that a feature pack is not a complete server, it cannot simply be
> extracted and run, it first needs to be assembled into a server by the
> provisioning tool. The feature packs also just contain references to the
> maven GAV of required jars, they do not have the actual jars in the pack
> (which should make them very lightweight).
>
> Feature packs will be assembled by the WF build tool, which is just a
> maven plugin that will replace our existing hacky collection of ant
> scripts.
>
> Actual server instances will be assembled by the provisioning tool,
> which will be implemented as a library with several different front
> ends, including a maven plugin and a CLI (possibly integrated into our
> existing CLI). In general the provisioning tool will be able to
> provision three different types of servers:
>
> - A traditional server with all jar files in the distribution
> - A server that uses maven coordinates in module.xml files, with all
> artifacts downloaded as part of the provisioning process
> - As above, but with artifacts being lazily loaded as needed (not
> recommended for production, but I think this may be useful from a
> developer point of view)
>
> The provisioning tool will work from an XML descriptor that describes
> the server that is to be built. In general this information will include:
>
> - GAV of the feature packs to use
> - Filtering information if not all features from a pack are required
> (e.g. just give me JAX-RS from the EE pack. In this case the only
> modules/subsystems installed from the pack will be modules and subystem
> that JAX-RS requires).
> - Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
> which will allow community users to easily upgrade individual components.
> - Configuration changes that are required (e.g. some way to add a
> datasource to the assembled server). The actual form this will take
> still needs to be decided. Note that this need to work on both a user
> level (a user adding a datasource) and a feature pack level (e.g. the
> JON feature packing adding a required data source).
> - GAV of deployments to install in the server. This should allow a
> server complete with deployments and the necessary config to be
> assembled and be immediately ready to be put into service.
>
> Note that if you just want a full WF install you should be able to
> provision it with a single line in the provisioning file, by specifying
> the dist feature pack. We will still provide our traditional download,
> which will be build by the provisioning tool as part of our build
> process.
>
> The provisioning tool will also be able to upgrade servers, which
> basically consists of provisioning a new modules directory. Rollback is
> provided by provisioning from an earlier version of provisioning file.
> When a server is provisioned the tool will make a backup copy of the
> file used, so it should always be possible to examine the provisioning
> file that was used to build the current server config.
>
> Note that when an update is performed on an existing server config will
> not be updated, unless the update adds an additional config file, in
> which case the new config file will be generated (however existing
> config will not be touched).
>
> Note that as a result of this split we will need to do much more
> frequent releases of the individual feature packs, to allow the most
> recent code to be integrated into dist.
>
> Implementation Plan
>
> The above changes are obviously a big job, and will not happen
> overnight. They are also highly likely to conflict with other changes,
> so maintaining a long running branch that gets rebased is not a
> practical option. Instead the plan it to perform the split in
> incremental changes. The basic steps are listed below, some of which can
> be performed in parallel.
>
> 1) Using the initial implementation of my build plugin (in my
> wildfly-build-plugin branch) we split up the server along the lines
> above. The code will all stay in the same repo, however the plugin will
> be used to build all the individual pieces, which are then assembled as
> part of the final build process. Note that the plugin in its current
> form does both the build and provision step, and the pack format is
> produces is far from the final pack format that we will want to use.
>
> 2) Split up the test suite into modules based on the features that they
> test. This will result in several smaller modules in place of a single
> large one, which should also be a usability improvement as individual
> tests will be be faster to run, and run times for all tests in a module
> should be more manageable.
>
> 3) Split the core into into own module.
>
> 4) Split everything else into its own module. As part of this step we
> need to make sure we still have the ability to run all tests against the
> full server, as well as against the cut down feature pack version of the
> server.
>
> 5) Focus on the build an provisioning tool, to implement all the
> features above, and to finalize the WF pack format.
>
> I think that just about covers it. There are still lots of nitty gritty
> details that need to be worked out, however I think this covers all the
> main aspects of the design. We are planning on starting work on this
> basically immediately, as we want to get this implemented as early in
> the WF9 cycle as possible.
>
> Stuart
>
>
>
>
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
5:31 a.m.
Hi Stuart,
Many good points.
I have some questions in this regard.
1, Could you please clarify the difference between feature packs, module,
and subsystems?
If I understand correctly, that subsystems, and module to feature packs is
like what ingredients to recipes.
2, To my gut feel, the feature packs you described shares the same concept
of feature of Karaf. For more info, please refer to
http://karaf.apache.org/manual/latest/users-guide/provisioning.html. Is it
possible for Wildfly to be built on top of OSGi container in the future?
Regards,
Peter C
On Wed, Jun 11, 2014 at 1:13 AM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
This design proposal covers the inter related tasks of splitting up
the
build, and also creating a build/provisioning system that will make it
easy for end users to consume Wildfly. Apologies for the length, but it
is a complex topic. The first part explains what we are trying to
achieve, the second part covers how we are planning to actually
implement it.
The Wildfly code base is over a million lines of java and has a test
suite that generally takes close to two hours to run in its entirety.
This makes the project very unwieldily, and the large size and slow test
suite makes development painful.
To deal with this issue we are going to split the Wildfly code base into
smaller discrete repositories. The planned split is as follows:
- Core: just the WF core
- Arquillian: the arquillian adaptors
- Servlet: a WF distribution with just Undertow, and some basic EE
functionality such as naming
- EE: All the core EE related functionality, EJB's, messaging etc
- Clustering: The core clustering functionality
- Console: The management console
- Dist: brings all the pieces together, and allows us to run all tests
against a full server
Note that this list is in no way final, and is open to debate. We will
most likely want to split up the EE component at some point, possibly
along some kind of web profile/full profile type split.
Each of these repos will build a feature pack, which will contain the
following:
- Feature specification / description
- Core version requirements (e.g. WF10)
- Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
- module.xml files for all required modules that are not provided by
other features
- References to maven GAV's for jars (possibly a level of indirection
here, module.xml may just contain the group and artifact, and the
version may be in a version.properties file to allow it to be easily
overridden)
- Default configuration snippet, subsystem snippets are packaged in the
subsystem jars, templates that combine them into config files are part
of the feature pack.
- Misc files (e.g. xsds) with indication of where on path to place them
Note that a feature pack is not a complete server, it cannot simply be
extracted and run, it first needs to be assembled into a server by the
provisioning tool. The feature packs also just contain references to the
maven GAV of required jars, they do not have the actual jars in the pack
(which should make them very lightweight).
Feature packs will be assembled by the WF build tool, which is just a
maven plugin that will replace our existing hacky collection of ant
scripts.
Actual server instances will be assembled by the provisioning tool,
which will be implemented as a library with several different front
ends, including a maven plugin and a CLI (possibly integrated into our
existing CLI). In general the provisioning tool will be able to
provision three different types of servers:
- A traditional server with all jar files in the distribution
- A server that uses maven coordinates in module.xml files, with all
artifacts downloaded as part of the provisioning process
- As above, but with artifacts being lazily loaded as needed (not
recommended for production, but I think this may be useful from a
developer point of view)
The provisioning tool will work from an XML descriptor that describes
the server that is to be built. In general this information will include:
- GAV of the feature packs to use
- Filtering information if not all features from a pack are required
(e.g. just give me JAX-RS from the EE pack. In this case the only
modules/subsystems installed from the pack will be modules and subystem
that JAX-RS requires).
- Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
which will allow community users to easily upgrade individual components.
- Configuration changes that are required (e.g. some way to add a
datasource to the assembled server). The actual form this will take
still needs to be decided. Note that this need to work on both a user
level (a user adding a datasource) and a feature pack level (e.g. the
JON feature packing adding a required data source).
- GAV of deployments to install in the server. This should allow a
server complete with deployments and the necessary config to be
assembled and be immediately ready to be put into service.
Note that if you just want a full WF install you should be able to
provision it with a single line in the provisioning file, by specifying
the dist feature pack. We will still provide our traditional download,
which will be build by the provisioning tool as part of our build process.
The provisioning tool will also be able to upgrade servers, which
basically consists of provisioning a new modules directory. Rollback is
provided by provisioning from an earlier version of provisioning file.
When a server is provisioned the tool will make a backup copy of the
file used, so it should always be possible to examine the provisioning
file that was used to build the current server config.
Note that when an update is performed on an existing server config will
not be updated, unless the update adds an additional config file, in
which case the new config file will be generated (however existing
config will not be touched).
Note that as a result of this split we will need to do much more
frequent releases of the individual feature packs, to allow the most
recent code to be integrated into dist.
Implementation Plan
The above changes are obviously a big job, and will not happen
overnight. They are also highly likely to conflict with other changes,
so maintaining a long running branch that gets rebased is not a
practical option. Instead the plan it to perform the split in
incremental changes. The basic steps are listed below, some of which can
be performed in parallel.
1) Using the initial implementation of my build plugin (in my
wildfly-build-plugin branch) we split up the server along the lines
above. The code will all stay in the same repo, however the plugin will
be used to build all the individual pieces, which are then assembled as
part of the final build process. Note that the plugin in its current
form does both the build and provision step, and the pack format is
produces is far from the final pack format that we will want to use.
2) Split up the test suite into modules based on the features that they
test. This will result in several smaller modules in place of a single
large one, which should also be a usability improvement as individual
tests will be be faster to run, and run times for all tests in a module
should be more manageable.
3) Split the core into into own module.
4) Split everything else into its own module. As part of this step we
need to make sure we still have the ability to run all tests against the
full server, as well as against the cut down feature pack version of the
server.
5) Focus on the build an provisioning tool, to implement all the
features above, and to finalize the WF pack format.
I think that just about covers it. There are still lots of nitty gritty
details that need to be worked out, however I think this covers all the
main aspects of the design. We are planning on starting work on this
basically immediately, as we want to get this implemented as early in
the WF9 cycle as possible.
Stuart
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:59 a.m.
Peter Cai wrote:
Hi Stuart,
Many good points.
I have some questions in this regard.
1, Could you please clarify the difference between feature packs,
module, and subsystems?
If I understand correctly, that subsystems, and module to feature packs
is like what ingredients to recipes.
A feature pack contains subsystems and other modules.
2, To my gut feel, the feature packs you described shares the same
concept of feature of Karaf. For more info, please refer to
http://karaf.apache.org/manual/latest/users-guide/provisioning.html. Is
it possible for Wildfly to be built on top of OSGi container in the future?
It is kinda like Karaf, but we are not based on OSGi, and have no plans
to move.
Stuart
Regards,
Peter C
On Wed, Jun 11, 2014 at 1:13 AM, Stuart Douglas <sdouglas(a)redhat.com
<mailto:sdouglas@redhat.com>> wrote:
This design proposal covers the inter related tasks of splitting up the
build, and also creating a build/provisioning system that will make it
easy for end users to consume Wildfly. Apologies for the length, but it
is a complex topic. The first part explains what we are trying to
achieve, the second part covers how we are planning to actually
implement it.
The Wildfly code base is over a million lines of java and has a test
suite that generally takes close to two hours to run in its entirety.
This makes the project very unwieldily, and the large size and slow test
suite makes development painful.
To deal with this issue we are going to split the Wildfly code base into
smaller discrete repositories. The planned split is as follows:
- Core: just the WF core
- Arquillian: the arquillian adaptors
- Servlet: a WF distribution with just Undertow, and some basic EE
functionality such as naming
- EE: All the core EE related functionality, EJB's, messaging etc
- Clustering: The core clustering functionality
- Console: The management console
- Dist: brings all the pieces together, and allows us to run all tests
against a full server
Note that this list is in no way final, and is open to debate. We will
most likely want to split up the EE component at some point, possibly
along some kind of web profile/full profile type split.
Each of these repos will build a feature pack, which will contain the
following:
- Feature specification / description
- Core version requirements (e.g. WF10)
- Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
- module.xml files for all required modules that are not provided by
other features
- References to maven GAV's for jars (possibly a level of indirection
here, module.xml may just contain the group and artifact, and the
version may be in a version.properties file to allow it to be easily
overridden)
- Default configuration snippet, subsystem snippets are packaged in the
subsystem jars, templates that combine them into config files are part
of the feature pack.
- Misc files (e.g. xsds) with indication of where on path to place them
Note that a feature pack is not a complete server, it cannot simply be
extracted and run, it first needs to be assembled into a server by the
provisioning tool. The feature packs also just contain references to the
maven GAV of required jars, they do not have the actual jars in the pack
(which should make them very lightweight).
Feature packs will be assembled by the WF build tool, which is just a
maven plugin that will replace our existing hacky collection of ant
scripts.
Actual server instances will be assembled by the provisioning tool,
which will be implemented as a library with several different front
ends, including a maven plugin and a CLI (possibly integrated into our
existing CLI). In general the provisioning tool will be able to
provision three different types of servers:
- A traditional server with all jar files in the distribution
- A server that uses maven coordinates in module.xml files, with all
artifacts downloaded as part of the provisioning process
- As above, but with artifacts being lazily loaded as needed (not
recommended for production, but I think this may be useful from a
developer point of view)
The provisioning tool will work from an XML descriptor that describes
the server that is to be built. In general this information will
include:
- GAV of the feature packs to use
- Filtering information if not all features from a pack are required
(e.g. just give me JAX-RS from the EE pack. In this case the only
modules/subsystems installed from the pack will be modules and subystem
that JAX-RS requires).
- Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
which will allow community users to easily upgrade individual
components.
- Configuration changes that are required (e.g. some way to add a
datasource to the assembled server). The actual form this will take
still needs to be decided. Note that this need to work on both a user
level (a user adding a datasource) and a feature pack level (e.g. the
JON feature packing adding a required data source).
- GAV of deployments to install in the server. This should allow a
server complete with deployments and the necessary config to be
assembled and be immediately ready to be put into service.
Note that if you just want a full WF install you should be able to
provision it with a single line in the provisioning file, by specifying
the dist feature pack. We will still provide our traditional download,
which will be build by the provisioning tool as part of our build
process.
The provisioning tool will also be able to upgrade servers, which
basically consists of provisioning a new modules directory. Rollback is
provided by provisioning from an earlier version of provisioning file.
When a server is provisioned the tool will make a backup copy of the
file used, so it should always be possible to examine the provisioning
file that was used to build the current server config.
Note that when an update is performed on an existing server config will
not be updated, unless the update adds an additional config file, in
which case the new config file will be generated (however existing
config will not be touched).
Note that as a result of this split we will need to do much more
frequent releases of the individual feature packs, to allow the most
recent code to be integrated into dist.
Implementation Plan
The above changes are obviously a big job, and will not happen
overnight. They are also highly likely to conflict with other changes,
so maintaining a long running branch that gets rebased is not a
practical option. Instead the plan it to perform the split in
incremental changes. The basic steps are listed below, some of which can
be performed in parallel.
1) Using the initial implementation of my build plugin (in my
wildfly-build-plugin branch) we split up the server along the lines
above. The code will all stay in the same repo, however the plugin will
be used to build all the individual pieces, which are then assembled as
part of the final build process. Note that the plugin in its current
form does both the build and provision step, and the pack format is
produces is far from the final pack format that we will want to use.
2) Split up the test suite into modules based on the features that they
test. This will result in several smaller modules in place of a single
large one, which should also be a usability improvement as individual
tests will be be faster to run, and run times for all tests in a module
should be more manageable.
3) Split the core into into own module.
4) Split everything else into its own module. As part of this step we
need to make sure we still have the ability to run all tests against the
full server, as well as against the cut down feature pack version of the
server.
5) Focus on the build an provisioning tool, to implement all the
features above, and to finalize the WF pack format.
I think that just about covers it. There are still lots of nitty gritty
details that need to be worked out, however I think this covers all the
main aspects of the design. We are planning on starting work on this
basically immediately, as we want to get this implemented as early in
the WF9 cycle as possible.
Stuart
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:32 a.m.
On Jun 11, 2014, at 9:59 AM, Stuart Douglas
<stuart.w.douglas(a)gmail.com> wrote:
It is kinda like Karaf, but we are not based on OSGi, and have no plans
to move.
The problem with using OSGi for the base modularity in WildFly, is that Java EE
class-loading rules do not map well to it, so you ultimately end up with two classloading
models. It also mandates it's own service model and brings in a vast amount of
complexity that our server internals didn't really benefit from. Finally we felt the
performance cost of it's dependency resolution algorithm was way too high (we wanted
deterministic o(1) resolution)
That said, we did expect interest in building OSGi applications on a full application
server, so our original plan with AS7 was to build a lightweight flexible modular class
loader, that would be mappable to all known class loading models, including OSGi and Java
EE. That became JBoss Modules.
AS7.x did ship with OSGi support based on JBoss Modules, however it had very little uptake
with our users and customers. Instead there was more interest in just using our modularity
layer directly.
Based on this, we decided to split off the OSGi layer into a separate optional project,
and focus more energy to other areas which were in more demand.
This isn't set in stone though. Ultimately WildFly is driven by what the community
wants and of course, code contributions is the best vehicle.
-Jason
10:57 a.m.
Something that I did not cover was how to actually do the split it terms
of preserving history. We have a few options:
1) Just copy the files into a clean repo. There is no history in the
repo, but you could always check the existing wildfly repo if you really
need it.
2) Copy the complete WF repo and then delete the parts that are not
going to be part of the new repo. This leaves complete history, but
means that the check outs will be larger than they should be.
3) Use git-filter-branch to create a new repo with just the history of
the relevant files. We still have a small checkout size, but the history
is still in the repo.
I think we should go with option 3.
Stuart
Stuart Douglas wrote:
This design proposal covers the inter related tasks of splitting up
the
build, and also creating a build/provisioning system that will make it
easy for end users to consume Wildfly. Apologies for the length, but it
is a complex topic. The first part explains what we are trying to
achieve, the second part covers how we are planning to actually
implement it.
The Wildfly code base is over a million lines of java and has a test
suite that generally takes close to two hours to run in its entirety.
This makes the project very unwieldily, and the large size and slow test
suite makes development painful.
To deal with this issue we are going to split the Wildfly code base into
smaller discrete repositories. The planned split is as follows:
- Core: just the WF core
- Arquillian: the arquillian adaptors
- Servlet: a WF distribution with just Undertow, and some basic EE
functionality such as naming
- EE: All the core EE related functionality, EJB's, messaging etc
- Clustering: The core clustering functionality
- Console: The management console
- Dist: brings all the pieces together, and allows us to run all tests
against a full server
Note that this list is in no way final, and is open to debate. We will
most likely want to split up the EE component at some point, possibly
along some kind of web profile/full profile type split.
Each of these repos will build a feature pack, which will contain the
following:
- Feature specification / description
- Core version requirements (e.g. WF10)
- Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
- module.xml files for all required modules that are not provided by
other features
- References to maven GAV's for jars (possibly a level of indirection
here, module.xml may just contain the group and artifact, and the
version may be in a version.properties file to allow it to be easily
overridden)
- Default configuration snippet, subsystem snippets are packaged in the
subsystem jars, templates that combine them into config files are part
of the feature pack.
- Misc files (e.g. xsds) with indication of where on path to place them
Note that a feature pack is not a complete server, it cannot simply be
extracted and run, it first needs to be assembled into a server by the
provisioning tool. The feature packs also just contain references to the
maven GAV of required jars, they do not have the actual jars in the pack
(which should make them very lightweight).
Feature packs will be assembled by the WF build tool, which is just a
maven plugin that will replace our existing hacky collection of ant
scripts.
Actual server instances will be assembled by the provisioning tool,
which will be implemented as a library with several different front
ends, including a maven plugin and a CLI (possibly integrated into our
existing CLI). In general the provisioning tool will be able to
provision three different types of servers:
- A traditional server with all jar files in the distribution
- A server that uses maven coordinates in module.xml files, with all
artifacts downloaded as part of the provisioning process
- As above, but with artifacts being lazily loaded as needed (not
recommended for production, but I think this may be useful from a
developer point of view)
The provisioning tool will work from an XML descriptor that describes
the server that is to be built. In general this information will include:
- GAV of the feature packs to use
- Filtering information if not all features from a pack are required
(e.g. just give me JAX-RS from the EE pack. In this case the only
modules/subsystems installed from the pack will be modules and subystem
that JAX-RS requires).
- Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
which will allow community users to easily upgrade individual components.
- Configuration changes that are required (e.g. some way to add a
datasource to the assembled server). The actual form this will take
still needs to be decided. Note that this need to work on both a user
level (a user adding a datasource) and a feature pack level (e.g. the
JON feature packing adding a required data source).
- GAV of deployments to install in the server. This should allow a
server complete with deployments and the necessary config to be
assembled and be immediately ready to be put into service.
Note that if you just want a full WF install you should be able to
provision it with a single line in the provisioning file, by specifying
the dist feature pack. We will still provide our traditional download,
which will be build by the provisioning tool as part of our build process.
The provisioning tool will also be able to upgrade servers, which
basically consists of provisioning a new modules directory. Rollback is
provided by provisioning from an earlier version of provisioning file.
When a server is provisioned the tool will make a backup copy of the
file used, so it should always be possible to examine the provisioning
file that was used to build the current server config.
Note that when an update is performed on an existing server config will
not be updated, unless the update adds an additional config file, in
which case the new config file will be generated (however existing
config will not be touched).
Note that as a result of this split we will need to do much more
frequent releases of the individual feature packs, to allow the most
recent code to be integrated into dist.
Implementation Plan
The above changes are obviously a big job, and will not happen
overnight. They are also highly likely to conflict with other changes,
so maintaining a long running branch that gets rebased is not a
practical option. Instead the plan it to perform the split in
incremental changes. The basic steps are listed below, some of which can
be performed in parallel.
1) Using the initial implementation of my build plugin (in my
wildfly-build-plugin branch) we split up the server along the lines
above. The code will all stay in the same repo, however the plugin will
be used to build all the individual pieces, which are then assembled as
part of the final build process. Note that the plugin in its current
form does both the build and provision step, and the pack format is
produces is far from the final pack format that we will want to use.
2) Split up the test suite into modules based on the features that they
test. This will result in several smaller modules in place of a single
large one, which should also be a usability improvement as individual
tests will be be faster to run, and run times for all tests in a module
should be more manageable.
3) Split the core into into own module.
4) Split everything else into its own module. As part of this step we
need to make sure we still have the ability to run all tests against the
full server, as well as against the cut down feature pack version of the
server.
5) Focus on the build an provisioning tool, to implement all the
features above, and to finalize the WF pack format.
I think that just about covers it. There are still lots of nitty gritty
details that need to be worked out, however I think this covers all the
main aspects of the design. We are planning on starting work on this
basically immediately, as we want to get this implemented as early in
the WF9 cycle as possible.
Stuart
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
5:33 a.m.
Hi,
Concerning tests and the integration tests in the test suite, will the splitting requires
them to be run twice or more ?
Let's say we test CDI integration with JAX-RS, will it be tested in the feature pack
JAR-RS, or in JAX-RS and JavaEE and complete dist ?
Cheers,
Emmanuel
Le 11/06/2014 17:57, Stuart Douglas a écrit :
Something that I did not cover was how to actually do the split it
terms
of preserving history. We have a few options:
1) Just copy the files into a clean repo. There is no history in the
repo, but you could always check the existing wildfly repo if you really
need it.
2) Copy the complete WF repo and then delete the parts that are not
going to be part of the new repo. This leaves complete history, but
means that the check outs will be larger than they should be.
3) Use git-filter-branch to create a new repo with just the history of
the relevant files. We still have a small checkout size, but the history
is still in the repo.
I think we should go with option 3.
Stuart
Stuart Douglas wrote:
> This design proposal covers the inter related tasks of splitting up the
> build, and also creating a build/provisioning system that will make it
> easy for end users to consume Wildfly. Apologies for the length, but it
> is a complex topic. The first part explains what we are trying to
> achieve, the second part covers how we are planning to actually
> implement it.
>
> The Wildfly code base is over a million lines of java and has a test
> suite that generally takes close to two hours to run in its entirety.
> This makes the project very unwieldily, and the large size and slow test
> suite makes development painful.
>
> To deal with this issue we are going to split the Wildfly code base into
> smaller discrete repositories. The planned split is as follows:
>
> - Core: just the WF core
> - Arquillian: the arquillian adaptors
> - Servlet: a WF distribution with just Undertow, and some basic EE
> functionality such as naming
> - EE: All the core EE related functionality, EJB's, messaging etc
> - Clustering: The core clustering functionality
> - Console: The management console
> - Dist: brings all the pieces together, and allows us to run all tests
> against a full server
>
> Note that this list is in no way final, and is open to debate. We will
> most likely want to split up the EE component at some point, possibly
> along some kind of web profile/full profile type split.
>
> Each of these repos will build a feature pack, which will contain the
> following:
>
> - Feature specification / description
> - Core version requirements (e.g. WF10)
> - Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
> - module.xml files for all required modules that are not provided by
> other features
> - References to maven GAV's for jars (possibly a level of indirection
> here, module.xml may just contain the group and artifact, and the
> version may be in a version.properties file to allow it to be easily
> overridden)
> - Default configuration snippet, subsystem snippets are packaged in the
> subsystem jars, templates that combine them into config files are part
> of the feature pack.
> - Misc files (e.g. xsds) with indication of where on path to place them
>
> Note that a feature pack is not a complete server, it cannot simply be
> extracted and run, it first needs to be assembled into a server by the
> provisioning tool. The feature packs also just contain references to the
> maven GAV of required jars, they do not have the actual jars in the pack
> (which should make them very lightweight).
>
> Feature packs will be assembled by the WF build tool, which is just a
> maven plugin that will replace our existing hacky collection of ant
> scripts.
>
> Actual server instances will be assembled by the provisioning tool,
> which will be implemented as a library with several different front
> ends, including a maven plugin and a CLI (possibly integrated into our
> existing CLI). In general the provisioning tool will be able to
> provision three different types of servers:
>
> - A traditional server with all jar files in the distribution
> - A server that uses maven coordinates in module.xml files, with all
> artifacts downloaded as part of the provisioning process
> - As above, but with artifacts being lazily loaded as needed (not
> recommended for production, but I think this may be useful from a
> developer point of view)
>
> The provisioning tool will work from an XML descriptor that describes
> the server that is to be built. In general this information will include:
>
> - GAV of the feature packs to use
> - Filtering information if not all features from a pack are required
> (e.g. just give me JAX-RS from the EE pack. In this case the only
> modules/subsystems installed from the pack will be modules and subystem
> that JAX-RS requires).
> - Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
> which will allow community users to easily upgrade individual components.
> - Configuration changes that are required (e.g. some way to add a
> datasource to the assembled server). The actual form this will take
> still needs to be decided. Note that this need to work on both a user
> level (a user adding a datasource) and a feature pack level (e.g. the
> JON feature packing adding a required data source).
> - GAV of deployments to install in the server. This should allow a
> server complete with deployments and the necessary config to be
> assembled and be immediately ready to be put into service.
>
> Note that if you just want a full WF install you should be able to
> provision it with a single line in the provisioning file, by specifying
> the dist feature pack. We will still provide our traditional download,
> which will be build by the provisioning tool as part of our build process.
>
> The provisioning tool will also be able to upgrade servers, which
> basically consists of provisioning a new modules directory. Rollback is
> provided by provisioning from an earlier version of provisioning file.
> When a server is provisioned the tool will make a backup copy of the
> file used, so it should always be possible to examine the provisioning
> file that was used to build the current server config.
>
> Note that when an update is performed on an existing server config will
> not be updated, unless the update adds an additional config file, in
> which case the new config file will be generated (however existing
> config will not be touched).
>
> Note that as a result of this split we will need to do much more
> frequent releases of the individual feature packs, to allow the most
> recent code to be integrated into dist.
>
> Implementation Plan
>
> The above changes are obviously a big job, and will not happen
> overnight. They are also highly likely to conflict with other changes,
> so maintaining a long running branch that gets rebased is not a
> practical option. Instead the plan it to perform the split in
> incremental changes. The basic steps are listed below, some of which can
> be performed in parallel.
>
> 1) Using the initial implementation of my build plugin (in my
> wildfly-build-plugin branch) we split up the server along the lines
> above. The code will all stay in the same repo, however the plugin will
> be used to build all the individual pieces, which are then assembled as
> part of the final build process. Note that the plugin in its current
> form does both the build and provision step, and the pack format is
> produces is far from the final pack format that we will want to use.
>
> 2) Split up the test suite into modules based on the features that they
> test. This will result in several smaller modules in place of a single
> large one, which should also be a usability improvement as individual
> tests will be be faster to run, and run times for all tests in a module
> should be more manageable.
>
> 3) Split the core into into own module.
>
> 4) Split everything else into its own module. As part of this step we
> need to make sure we still have the ability to run all tests against the
> full server, as well as against the cut down feature pack version of the
> server.
>
> 5) Focus on the build an provisioning tool, to implement all the
> features above, and to finalize the WF pack format.
>
> I think that just about covers it. There are still lots of nitty gritty
> details that need to be worked out, however I think this covers all the
> main aspects of the design. We are planning on starting work on this
> basically immediately, as we want to get this implemented as early in
> the WF9 cycle as possible.
>
> Stuart
>
>
>
>
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
5:45 a.m.
In short no.
But in practice, it is complicated question
I am currently working in splitting testsuite to core & full distro.
So some tests will only be part of core and others of full distro.
When we went trough tests we saw that some tests overlap and would need to
be run in both testsuites, but luckily they are a minority.
Bigger problem we have right now is to make sure tests that belong to core
properly work there as not everything is avalible.
There will be some work needed to fix such tests but in end they will be
just in one place.
To address your question more specifically, idea is that one feature is
only tested in its appropriate distro/feature and not duplicated.
unless that new distro/feature adds some stuff that modifies default
behavior where testing of some features should be re-done.
even now we have tests that only test specific features and ones that tests
integrations of bunch of features.
We just need to be smart about how do testing.
--
tomaz
On Thu, Jun 12, 2014 at 12:33 PM, Emmanuel Hugonnet <ehugonne(a)redhat.com>
wrote:
Hi,
Concerning tests and the integration tests in the test suite, will the
splitting requires them to be run twice or more ?
Let's say we test CDI integration with JAX-RS, will it be tested in the
feature pack JAR-RS, or in JAX-RS and JavaEE and complete dist ?
Cheers,
Emmanuel
Le 11/06/2014 17:57, Stuart Douglas a écrit :
> Something that I did not cover was how to actually do the split it terms
> of preserving history. We have a few options:
>
> 1) Just copy the files into a clean repo. There is no history in the
> repo, but you could always check the existing wildfly repo if you really
> need it.
>
> 2) Copy the complete WF repo and then delete the parts that are not
> going to be part of the new repo. This leaves complete history, but
> means that the check outs will be larger than they should be.
>
> 3) Use git-filter-branch to create a new repo with just the history of
> the relevant files. We still have a small checkout size, but the history
> is still in the repo.
>
> I think we should go with option 3.
>
> Stuart
>
> Stuart Douglas wrote:
>> This design proposal covers the inter related tasks of splitting up the
>> build, and also creating a build/provisioning system that will make it
>> easy for end users to consume Wildfly. Apologies for the length, but it
>> is a complex topic. The first part explains what we are trying to
>> achieve, the second part covers how we are planning to actually
>> implement it.
>>
>> The Wildfly code base is over a million lines of java and has a test
>> suite that generally takes close to two hours to run in its entirety.
>> This makes the project very unwieldily, and the large size and slow test
>> suite makes development painful.
>>
>> To deal with this issue we are going to split the Wildfly code base into
>> smaller discrete repositories. The planned split is as follows:
>>
>> - Core: just the WF core
>> - Arquillian: the arquillian adaptors
>> - Servlet: a WF distribution with just Undertow, and some basic EE
>> functionality such as naming
>> - EE: All the core EE related functionality, EJB's, messaging etc
>> - Clustering: The core clustering functionality
>> - Console: The management console
>> - Dist: brings all the pieces together, and allows us to run all tests
>> against a full server
>>
>> Note that this list is in no way final, and is open to debate. We will
>> most likely want to split up the EE component at some point, possibly
>> along some kind of web profile/full profile type split.
>>
>> Each of these repos will build a feature pack, which will contain the
>> following:
>>
>> - Feature specification / description
>> - Core version requirements (e.g. WF10)
>> - Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
>> - module.xml files for all required modules that are not provided by
>> other features
>> - References to maven GAV's for jars (possibly a level of indirection
>> here, module.xml may just contain the group and artifact, and the
>> version may be in a version.properties file to allow it to be easily
>> overridden)
>> - Default configuration snippet, subsystem snippets are packaged in the
>> subsystem jars, templates that combine them into config files are part
>> of the feature pack.
>> - Misc files (e.g. xsds) with indication of where on path to place them
>>
>> Note that a feature pack is not a complete server, it cannot simply be
>> extracted and run, it first needs to be assembled into a server by the
>> provisioning tool. The feature packs also just contain references to the
>> maven GAV of required jars, they do not have the actual jars in the pack
>> (which should make them very lightweight).
>>
>> Feature packs will be assembled by the WF build tool, which is just a
>> maven plugin that will replace our existing hacky collection of ant
>> scripts.
>>
>> Actual server instances will be assembled by the provisioning tool,
>> which will be implemented as a library with several different front
>> ends, including a maven plugin and a CLI (possibly integrated into our
>> existing CLI). In general the provisioning tool will be able to
>> provision three different types of servers:
>>
>> - A traditional server with all jar files in the distribution
>> - A server that uses maven coordinates in module.xml files, with all
>> artifacts downloaded as part of the provisioning process
>> - As above, but with artifacts being lazily loaded as needed (not
>> recommended for production, but I think this may be useful from a
>> developer point of view)
>>
>> The provisioning tool will work from an XML descriptor that describes
>> the server that is to be built. In general this information will
include:
>>
>> - GAV of the feature packs to use
>> - Filtering information if not all features from a pack are required
>> (e.g. just give me JAX-RS from the EE pack. In this case the only
>> modules/subsystems installed from the pack will be modules and subystem
>> that JAX-RS requires).
>> - Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
>> which will allow community users to easily upgrade individual
components.
>> - Configuration changes that are required (e.g. some way to add a
>> datasource to the assembled server). The actual form this will take
>> still needs to be decided. Note that this need to work on both a user
>> level (a user adding a datasource) and a feature pack level (e.g. the
>> JON feature packing adding a required data source).
>> - GAV of deployments to install in the server. This should allow a
>> server complete with deployments and the necessary config to be
>> assembled and be immediately ready to be put into service.
>>
>> Note that if you just want a full WF install you should be able to
>> provision it with a single line in the provisioning file, by specifying
>> the dist feature pack. We will still provide our traditional download,
>> which will be build by the provisioning tool as part of our build
process.
>>
>> The provisioning tool will also be able to upgrade servers, which
>> basically consists of provisioning a new modules directory. Rollback is
>> provided by provisioning from an earlier version of provisioning file.
>> When a server is provisioned the tool will make a backup copy of the
>> file used, so it should always be possible to examine the provisioning
>> file that was used to build the current server config.
>>
>> Note that when an update is performed on an existing server config will
>> not be updated, unless the update adds an additional config file, in
>> which case the new config file will be generated (however existing
>> config will not be touched).
>>
>> Note that as a result of this split we will need to do much more
>> frequent releases of the individual feature packs, to allow the most
>> recent code to be integrated into dist.
>>
>> Implementation Plan
>>
>> The above changes are obviously a big job, and will not happen
>> overnight. They are also highly likely to conflict with other changes,
>> so maintaining a long running branch that gets rebased is not a
>> practical option. Instead the plan it to perform the split in
>> incremental changes. The basic steps are listed below, some of which can
>> be performed in parallel.
>>
>> 1) Using the initial implementation of my build plugin (in my
>> wildfly-build-plugin branch) we split up the server along the lines
>> above. The code will all stay in the same repo, however the plugin will
>> be used to build all the individual pieces, which are then assembled as
>> part of the final build process. Note that the plugin in its current
>> form does both the build and provision step, and the pack format is
>> produces is far from the final pack format that we will want to use.
>>
>> 2) Split up the test suite into modules based on the features that they
>> test. This will result in several smaller modules in place of a single
>> large one, which should also be a usability improvement as individual
>> tests will be be faster to run, and run times for all tests in a module
>> should be more manageable.
>>
>> 3) Split the core into into own module.
>>
>> 4) Split everything else into its own module. As part of this step we
>> need to make sure we still have the ability to run all tests against the
>> full server, as well as against the cut down feature pack version of the
>> server.
>>
>> 5) Focus on the build an provisioning tool, to implement all the
>> features above, and to finalize the WF pack format.
>>
>> I think that just about covers it. There are still lots of nitty gritty
>> details that need to be worked out, however I think this covers all the
>> main aspects of the design. We are planning on starting work on this
>> basically immediately, as we want to get this implemented as early in
>> the WF9 cycle as possible.
>>
>> Stuart
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:19 a.m.
Basically yes.
This still needs to have some of the details worked out, but in general
tests are going to be split into modules based on the features they
required, and these modules will become part of the relevant feature
packs, so these tests will be run when building the feature pack.
These tests will also be published as a test-jar artifact, and our dist
repo that builds a complete server will also have the ability to run all
the tests.
This means that if you have a web test it will be run once when building
the web feature, and again when integrating a new version of that
feature into the main distro.
Stuart
Emmanuel Hugonnet wrote:
Hi,
Concerning tests and the integration tests in the test suite, will the splitting requires
them to be run twice or more ?
Let's say we test CDI integration with JAX-RS, will it be tested in the feature pack
JAR-RS, or in JAX-RS and JavaEE and complete dist ?
Cheers,
Emmanuel
Le 11/06/2014 17:57, Stuart Douglas a écrit :
> Something that I did not cover was how to actually do the split it terms
> of preserving history. We have a few options:
>
> 1) Just copy the files into a clean repo. There is no history in the
> repo, but you could always check the existing wildfly repo if you really
> need it.
>
> 2) Copy the complete WF repo and then delete the parts that are not
> going to be part of the new repo. This leaves complete history, but
> means that the check outs will be larger than they should be.
>
> 3) Use git-filter-branch to create a new repo with just the history of
> the relevant files. We still have a small checkout size, but the history
> is still in the repo.
>
> I think we should go with option 3.
>
> Stuart
>
> Stuart Douglas wrote:
>> This design proposal covers the inter related tasks of splitting up the
>> build, and also creating a build/provisioning system that will make it
>> easy for end users to consume Wildfly. Apologies for the length, but it
>> is a complex topic. The first part explains what we are trying to
>> achieve, the second part covers how we are planning to actually
>> implement it.
>>
>> The Wildfly code base is over a million lines of java and has a test
>> suite that generally takes close to two hours to run in its entirety.
>> This makes the project very unwieldily, and the large size and slow test
>> suite makes development painful.
>>
>> To deal with this issue we are going to split the Wildfly code base into
>> smaller discrete repositories. The planned split is as follows:
>>
>> - Core: just the WF core
>> - Arquillian: the arquillian adaptors
>> - Servlet: a WF distribution with just Undertow, and some basic EE
>> functionality such as naming
>> - EE: All the core EE related functionality, EJB's, messaging etc
>> - Clustering: The core clustering functionality
>> - Console: The management console
>> - Dist: brings all the pieces together, and allows us to run all tests
>> against a full server
>>
>> Note that this list is in no way final, and is open to debate. We will
>> most likely want to split up the EE component at some point, possibly
>> along some kind of web profile/full profile type split.
>>
>> Each of these repos will build a feature pack, which will contain the
>> following:
>>
>> - Feature specification / description
>> - Core version requirements (e.g. WF10)
>> - Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
>> - module.xml files for all required modules that are not provided by
>> other features
>> - References to maven GAV's for jars (possibly a level of indirection
>> here, module.xml may just contain the group and artifact, and the
>> version may be in a version.properties file to allow it to be easily
>> overridden)
>> - Default configuration snippet, subsystem snippets are packaged in the
>> subsystem jars, templates that combine them into config files are part
>> of the feature pack.
>> - Misc files (e.g. xsds) with indication of where on path to place them
>>
>> Note that a feature pack is not a complete server, it cannot simply be
>> extracted and run, it first needs to be assembled into a server by the
>> provisioning tool. The feature packs also just contain references to the
>> maven GAV of required jars, they do not have the actual jars in the pack
>> (which should make them very lightweight).
>>
>> Feature packs will be assembled by the WF build tool, which is just a
>> maven plugin that will replace our existing hacky collection of ant
>> scripts.
>>
>> Actual server instances will be assembled by the provisioning tool,
>> which will be implemented as a library with several different front
>> ends, including a maven plugin and a CLI (possibly integrated into our
>> existing CLI). In general the provisioning tool will be able to
>> provision three different types of servers:
>>
>> - A traditional server with all jar files in the distribution
>> - A server that uses maven coordinates in module.xml files, with all
>> artifacts downloaded as part of the provisioning process
>> - As above, but with artifacts being lazily loaded as needed (not
>> recommended for production, but I think this may be useful from a
>> developer point of view)
>>
>> The provisioning tool will work from an XML descriptor that describes
>> the server that is to be built. In general this information will include:
>>
>> - GAV of the feature packs to use
>> - Filtering information if not all features from a pack are required
>> (e.g. just give me JAX-RS from the EE pack. In this case the only
>> modules/subsystems installed from the pack will be modules and subystem
>> that JAX-RS requires).
>> - Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
>> which will allow community users to easily upgrade individual components.
>> - Configuration changes that are required (e.g. some way to add a
>> datasource to the assembled server). The actual form this will take
>> still needs to be decided. Note that this need to work on both a user
>> level (a user adding a datasource) and a feature pack level (e.g. the
>> JON feature packing adding a required data source).
>> - GAV of deployments to install in the server. This should allow a
>> server complete with deployments and the necessary config to be
>> assembled and be immediately ready to be put into service.
>>
>> Note that if you just want a full WF install you should be able to
>> provision it with a single line in the provisioning file, by specifying
>> the dist feature pack. We will still provide our traditional download,
>> which will be build by the provisioning tool as part of our build process.
>>
>> The provisioning tool will also be able to upgrade servers, which
>> basically consists of provisioning a new modules directory. Rollback is
>> provided by provisioning from an earlier version of provisioning file.
>> When a server is provisioned the tool will make a backup copy of the
>> file used, so it should always be possible to examine the provisioning
>> file that was used to build the current server config.
>>
>> Note that when an update is performed on an existing server config will
>> not be updated, unless the update adds an additional config file, in
>> which case the new config file will be generated (however existing
>> config will not be touched).
>>
>> Note that as a result of this split we will need to do much more
>> frequent releases of the individual feature packs, to allow the most
>> recent code to be integrated into dist.
>>
>> Implementation Plan
>>
>> The above changes are obviously a big job, and will not happen
>> overnight. They are also highly likely to conflict with other changes,
>> so maintaining a long running branch that gets rebased is not a
>> practical option. Instead the plan it to perform the split in
>> incremental changes. The basic steps are listed below, some of which can
>> be performed in parallel.
>>
>> 1) Using the initial implementation of my build plugin (in my
>> wildfly-build-plugin branch) we split up the server along the lines
>> above. The code will all stay in the same repo, however the plugin will
>> be used to build all the individual pieces, which are then assembled as
>> part of the final build process. Note that the plugin in its current
>> form does both the build and provision step, and the pack format is
>> produces is far from the final pack format that we will want to use.
>>
>> 2) Split up the test suite into modules based on the features that they
>> test. This will result in several smaller modules in place of a single
>> large one, which should also be a usability improvement as individual
>> tests will be be faster to run, and run times for all tests in a module
>> should be more manageable.
>>
>> 3) Split the core into into own module.
>>
>> 4) Split everything else into its own module. As part of this step we
>> need to make sure we still have the ability to run all tests against the
>> full server, as well as against the cut down feature pack version of the
>> server.
>>
>> 5) Focus on the build an provisioning tool, to implement all the
>> features above, and to finalize the WF pack format.
>>
>> I think that just about covers it. There are still lots of nitty gritty
>> details that need to be worked out, however I think this covers all the
>> main aspects of the design. We are planning on starting work on this
>> basically immediately, as we want to get this implemented as early in
>> the WF9 cycle as possible.
>>
>> Stuart
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
9:45 a.m.
Please also consider the requirements we need to follow when maintaining
the products based on previous AS7/WildFly releases.
Regards,
Darran Lofthouse.
On 11/06/14 16:57, Stuart Douglas wrote:
Something that I did not cover was how to actually do the split it
terms
of preserving history. We have a few options:
1) Just copy the files into a clean repo. There is no history in the
repo, but you could always check the existing wildfly repo if you really
need it.
2) Copy the complete WF repo and then delete the parts that are not
going to be part of the new repo. This leaves complete history, but
means that the check outs will be larger than they should be.
3) Use git-filter-branch to create a new repo with just the history of
the relevant files. We still have a small checkout size, but the history
is still in the repo.
I think we should go with option 3.
Stuart
Stuart Douglas wrote:
> This design proposal covers the inter related tasks of splitting up the
> build, and also creating a build/provisioning system that will make it
> easy for end users to consume Wildfly. Apologies for the length, but it
> is a complex topic. The first part explains what we are trying to
> achieve, the second part covers how we are planning to actually
> implement it.
>
> The Wildfly code base is over a million lines of java and has a test
> suite that generally takes close to two hours to run in its entirety.
> This makes the project very unwieldily, and the large size and slow test
> suite makes development painful.
>
> To deal with this issue we are going to split the Wildfly code base into
> smaller discrete repositories. The planned split is as follows:
>
> - Core: just the WF core
> - Arquillian: the arquillian adaptors
> - Servlet: a WF distribution with just Undertow, and some basic EE
> functionality such as naming
> - EE: All the core EE related functionality, EJB's, messaging etc
> - Clustering: The core clustering functionality
> - Console: The management console
> - Dist: brings all the pieces together, and allows us to run all tests
> against a full server
>
> Note that this list is in no way final, and is open to debate. We will
> most likely want to split up the EE component at some point, possibly
> along some kind of web profile/full profile type split.
>
> Each of these repos will build a feature pack, which will contain the
> following:
>
> - Feature specification / description
> - Core version requirements (e.g. WF10)
> - Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
> - module.xml files for all required modules that are not provided by
> other features
> - References to maven GAV's for jars (possibly a level of indirection
> here, module.xml may just contain the group and artifact, and the
> version may be in a version.properties file to allow it to be easily
> overridden)
> - Default configuration snippet, subsystem snippets are packaged in the
> subsystem jars, templates that combine them into config files are part
> of the feature pack.
> - Misc files (e.g. xsds) with indication of where on path to place them
>
> Note that a feature pack is not a complete server, it cannot simply be
> extracted and run, it first needs to be assembled into a server by the
> provisioning tool. The feature packs also just contain references to the
> maven GAV of required jars, they do not have the actual jars in the pack
> (which should make them very lightweight).
>
> Feature packs will be assembled by the WF build tool, which is just a
> maven plugin that will replace our existing hacky collection of ant
> scripts.
>
> Actual server instances will be assembled by the provisioning tool,
> which will be implemented as a library with several different front
> ends, including a maven plugin and a CLI (possibly integrated into our
> existing CLI). In general the provisioning tool will be able to
> provision three different types of servers:
>
> - A traditional server with all jar files in the distribution
> - A server that uses maven coordinates in module.xml files, with all
> artifacts downloaded as part of the provisioning process
> - As above, but with artifacts being lazily loaded as needed (not
> recommended for production, but I think this may be useful from a
> developer point of view)
>
> The provisioning tool will work from an XML descriptor that describes
> the server that is to be built. In general this information will include:
>
> - GAV of the feature packs to use
> - Filtering information if not all features from a pack are required
> (e.g. just give me JAX-RS from the EE pack. In this case the only
> modules/subsystems installed from the pack will be modules and subystem
> that JAX-RS requires).
> - Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
> which will allow community users to easily upgrade individual components.
> - Configuration changes that are required (e.g. some way to add a
> datasource to the assembled server). The actual form this will take
> still needs to be decided. Note that this need to work on both a user
> level (a user adding a datasource) and a feature pack level (e.g. the
> JON feature packing adding a required data source).
> - GAV of deployments to install in the server. This should allow a
> server complete with deployments and the necessary config to be
> assembled and be immediately ready to be put into service.
>
> Note that if you just want a full WF install you should be able to
> provision it with a single line in the provisioning file, by specifying
> the dist feature pack. We will still provide our traditional download,
> which will be build by the provisioning tool as part of our build process.
>
> The provisioning tool will also be able to upgrade servers, which
> basically consists of provisioning a new modules directory. Rollback is
> provided by provisioning from an earlier version of provisioning file.
> When a server is provisioned the tool will make a backup copy of the
> file used, so it should always be possible to examine the provisioning
> file that was used to build the current server config.
>
> Note that when an update is performed on an existing server config will
> not be updated, unless the update adds an additional config file, in
> which case the new config file will be generated (however existing
> config will not be touched).
>
> Note that as a result of this split we will need to do much more
> frequent releases of the individual feature packs, to allow the most
> recent code to be integrated into dist.
>
> Implementation Plan
>
> The above changes are obviously a big job, and will not happen
> overnight. They are also highly likely to conflict with other changes,
> so maintaining a long running branch that gets rebased is not a
> practical option. Instead the plan it to perform the split in
> incremental changes. The basic steps are listed below, some of which can
> be performed in parallel.
>
> 1) Using the initial implementation of my build plugin (in my
> wildfly-build-plugin branch) we split up the server along the lines
> above. The code will all stay in the same repo, however the plugin will
> be used to build all the individual pieces, which are then assembled as
> part of the final build process. Note that the plugin in its current
> form does both the build and provision step, and the pack format is
> produces is far from the final pack format that we will want to use.
>
> 2) Split up the test suite into modules based on the features that they
> test. This will result in several smaller modules in place of a single
> large one, which should also be a usability improvement as individual
> tests will be be faster to run, and run times for all tests in a module
> should be more manageable.
>
> 3) Split the core into into own module.
>
> 4) Split everything else into its own module. As part of this step we
> need to make sure we still have the ability to run all tests against the
> full server, as well as against the cut down feature pack version of the
> server.
>
> 5) Focus on the build an provisioning tool, to implement all the
> features above, and to finalize the WF pack format.
>
> I think that just about covers it. There are still lots of nitty gritty
> details that need to be worked out, however I think this covers all the
> main aspects of the design. We are planning on starting work on this
> basically immediately, as we want to get this implemented as early in
> the WF9 cycle as possible.
>
> Stuart
>
>
>
>
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:48 a.m.
I am not sure if either of these choices will make much difference? In
general our directory layout will be the same, so it should just be
possibly to cherry pick patches from WF.
Stuart
Darran Lofthouse wrote:
Please also consider the requirements we need to follow when
maintaining
the products based on previous AS7/WildFly releases.
Regards,
Darran Lofthouse.
On 11/06/14 16:57, Stuart Douglas wrote:
> Something that I did not cover was how to actually do the split it terms
> of preserving history. We have a few options:
>
> 1) Just copy the files into a clean repo. There is no history in the
> repo, but you could always check the existing wildfly repo if you really
> need it.
>
> 2) Copy the complete WF repo and then delete the parts that are not
> going to be part of the new repo. This leaves complete history, but
> means that the check outs will be larger than they should be.
>
> 3) Use git-filter-branch to create a new repo with just the history of
> the relevant files. We still have a small checkout size, but the history
> is still in the repo.
>
> I think we should go with option 3.
>
> Stuart
>
> Stuart Douglas wrote:
>> This design proposal covers the inter related tasks of splitting up the
>> build, and also creating a build/provisioning system that will make it
>> easy for end users to consume Wildfly. Apologies for the length, but it
>> is a complex topic. The first part explains what we are trying to
>> achieve, the second part covers how we are planning to actually
>> implement it.
>>
>> The Wildfly code base is over a million lines of java and has a test
>> suite that generally takes close to two hours to run in its entirety.
>> This makes the project very unwieldily, and the large size and slow test
>> suite makes development painful.
>>
>> To deal with this issue we are going to split the Wildfly code base into
>> smaller discrete repositories. The planned split is as follows:
>>
>> - Core: just the WF core
>> - Arquillian: the arquillian adaptors
>> - Servlet: a WF distribution with just Undertow, and some basic EE
>> functionality such as naming
>> - EE: All the core EE related functionality, EJB's, messaging etc
>> - Clustering: The core clustering functionality
>> - Console: The management console
>> - Dist: brings all the pieces together, and allows us to run all tests
>> against a full server
>>
>> Note that this list is in no way final, and is open to debate. We will
>> most likely want to split up the EE component at some point, possibly
>> along some kind of web profile/full profile type split.
>>
>> Each of these repos will build a feature pack, which will contain the
>> following:
>>
>> - Feature specification / description
>> - Core version requirements (e.g. WF10)
>> - Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
>> - module.xml files for all required modules that are not provided by
>> other features
>> - References to maven GAV's for jars (possibly a level of indirection
>> here, module.xml may just contain the group and artifact, and the
>> version may be in a version.properties file to allow it to be easily
>> overridden)
>> - Default configuration snippet, subsystem snippets are packaged in the
>> subsystem jars, templates that combine them into config files are part
>> of the feature pack.
>> - Misc files (e.g. xsds) with indication of where on path to place them
>>
>> Note that a feature pack is not a complete server, it cannot simply be
>> extracted and run, it first needs to be assembled into a server by the
>> provisioning tool. The feature packs also just contain references to the
>> maven GAV of required jars, they do not have the actual jars in the pack
>> (which should make them very lightweight).
>>
>> Feature packs will be assembled by the WF build tool, which is just a
>> maven plugin that will replace our existing hacky collection of ant
>> scripts.
>>
>> Actual server instances will be assembled by the provisioning tool,
>> which will be implemented as a library with several different front
>> ends, including a maven plugin and a CLI (possibly integrated into our
>> existing CLI). In general the provisioning tool will be able to
>> provision three different types of servers:
>>
>> - A traditional server with all jar files in the distribution
>> - A server that uses maven coordinates in module.xml files, with all
>> artifacts downloaded as part of the provisioning process
>> - As above, but with artifacts being lazily loaded as needed (not
>> recommended for production, but I think this may be useful from a
>> developer point of view)
>>
>> The provisioning tool will work from an XML descriptor that describes
>> the server that is to be built. In general this information will include:
>>
>> - GAV of the feature packs to use
>> - Filtering information if not all features from a pack are required
>> (e.g. just give me JAX-RS from the EE pack. In this case the only
>> modules/subsystems installed from the pack will be modules and subystem
>> that JAX-RS requires).
>> - Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
>> which will allow community users to easily upgrade individual components.
>> - Configuration changes that are required (e.g. some way to add a
>> datasource to the assembled server). The actual form this will take
>> still needs to be decided. Note that this need to work on both a user
>> level (a user adding a datasource) and a feature pack level (e.g. the
>> JON feature packing adding a required data source).
>> - GAV of deployments to install in the server. This should allow a
>> server complete with deployments and the necessary config to be
>> assembled and be immediately ready to be put into service.
>>
>> Note that if you just want a full WF install you should be able to
>> provision it with a single line in the provisioning file, by specifying
>> the dist feature pack. We will still provide our traditional download,
>> which will be build by the provisioning tool as part of our build process.
>>
>> The provisioning tool will also be able to upgrade servers, which
>> basically consists of provisioning a new modules directory. Rollback is
>> provided by provisioning from an earlier version of provisioning file.
>> When a server is provisioned the tool will make a backup copy of the
>> file used, so it should always be possible to examine the provisioning
>> file that was used to build the current server config.
>>
>> Note that when an update is performed on an existing server config will
>> not be updated, unless the update adds an additional config file, in
>> which case the new config file will be generated (however existing
>> config will not be touched).
>>
>> Note that as a result of this split we will need to do much more
>> frequent releases of the individual feature packs, to allow the most
>> recent code to be integrated into dist.
>>
>> Implementation Plan
>>
>> The above changes are obviously a big job, and will not happen
>> overnight. They are also highly likely to conflict with other changes,
>> so maintaining a long running branch that gets rebased is not a
>> practical option. Instead the plan it to perform the split in
>> incremental changes. The basic steps are listed below, some of which can
>> be performed in parallel.
>>
>> 1) Using the initial implementation of my build plugin (in my
>> wildfly-build-plugin branch) we split up the server along the lines
>> above. The code will all stay in the same repo, however the plugin will
>> be used to build all the individual pieces, which are then assembled as
>> part of the final build process. Note that the plugin in its current
>> form does both the build and provision step, and the pack format is
>> produces is far from the final pack format that we will want to use.
>>
>> 2) Split up the test suite into modules based on the features that they
>> test. This will result in several smaller modules in place of a single
>> large one, which should also be a usability improvement as individual
>> tests will be be faster to run, and run times for all tests in a module
>> should be more manageable.
>>
>> 3) Split the core into into own module.
>>
>> 4) Split everything else into its own module. As part of this step we
>> need to make sure we still have the ability to run all tests against the
>> full server, as well as against the cut down feature pack version of the
>> server.
>>
>> 5) Focus on the build an provisioning tool, to implement all the
>> features above, and to finalize the WF pack format.
>>
>> I think that just about covers it. There are still lots of nitty gritty
>> details that need to be worked out, however I think this covers all the
>> main aspects of the design. We are planning on starting work on this
>> basically immediately, as we want to get this implemented as early in
>> the WF9 cycle as possible.
>>
>> Stuart
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:51 a.m.
On 12/06/14 15:48, Stuart Douglas wrote:
I am not sure if either of these choices will make much difference?
In
general our directory layout will be the same, so it should just be
possibly to cherry pick patches from WF.
That is probably true but I think this is an important enough point that
before changes are made we know that it will be possible rather than
than just should be possible.
Stuart
Darran Lofthouse wrote:
> Please also consider the requirements we need to follow when maintaining
> the products based on previous AS7/WildFly releases.
>
> Regards,
> Darran Lofthouse.
>
>
> On 11/06/14 16:57, Stuart Douglas wrote:
>> Something that I did not cover was how to actually do the split it terms
>> of preserving history. We have a few options:
>>
>> 1) Just copy the files into a clean repo. There is no history in the
>> repo, but you could always check the existing wildfly repo if you really
>> need it.
>>
>> 2) Copy the complete WF repo and then delete the parts that are not
>> going to be part of the new repo. This leaves complete history, but
>> means that the check outs will be larger than they should be.
>>
>> 3) Use git-filter-branch to create a new repo with just the history of
>> the relevant files. We still have a small checkout size, but the history
>> is still in the repo.
>>
>> I think we should go with option 3.
>>
>> Stuart
>>
>> Stuart Douglas wrote:
>>> This design proposal covers the inter related tasks of splitting up the
>>> build, and also creating a build/provisioning system that will make it
>>> easy for end users to consume Wildfly. Apologies for the length, but it
>>> is a complex topic. The first part explains what we are trying to
>>> achieve, the second part covers how we are planning to actually
>>> implement it.
>>>
>>> The Wildfly code base is over a million lines of java and has a test
>>> suite that generally takes close to two hours to run in its entirety.
>>> This makes the project very unwieldily, and the large size and slow
>>> test
>>> suite makes development painful.
>>>
>>> To deal with this issue we are going to split the Wildfly code base
>>> into
>>> smaller discrete repositories. The planned split is as follows:
>>>
>>> - Core: just the WF core
>>> - Arquillian: the arquillian adaptors
>>> - Servlet: a WF distribution with just Undertow, and some basic EE
>>> functionality such as naming
>>> - EE: All the core EE related functionality, EJB's, messaging etc
>>> - Clustering: The core clustering functionality
>>> - Console: The management console
>>> - Dist: brings all the pieces together, and allows us to run all tests
>>> against a full server
>>>
>>> Note that this list is in no way final, and is open to debate. We will
>>> most likely want to split up the EE component at some point, possibly
>>> along some kind of web profile/full profile type split.
>>>
>>> Each of these repos will build a feature pack, which will contain the
>>> following:
>>>
>>> - Feature specification / description
>>> - Core version requirements (e.g. WF10)
>>> - Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
>>> - module.xml files for all required modules that are not provided by
>>> other features
>>> - References to maven GAV's for jars (possibly a level of indirection
>>> here, module.xml may just contain the group and artifact, and the
>>> version may be in a version.properties file to allow it to be easily
>>> overridden)
>>> - Default configuration snippet, subsystem snippets are packaged in the
>>> subsystem jars, templates that combine them into config files are part
>>> of the feature pack.
>>> - Misc files (e.g. xsds) with indication of where on path to place them
>>>
>>> Note that a feature pack is not a complete server, it cannot simply be
>>> extracted and run, it first needs to be assembled into a server by the
>>> provisioning tool. The feature packs also just contain references to
>>> the
>>> maven GAV of required jars, they do not have the actual jars in the
>>> pack
>>> (which should make them very lightweight).
>>>
>>> Feature packs will be assembled by the WF build tool, which is just a
>>> maven plugin that will replace our existing hacky collection of ant
>>> scripts.
>>>
>>> Actual server instances will be assembled by the provisioning tool,
>>> which will be implemented as a library with several different front
>>> ends, including a maven plugin and a CLI (possibly integrated into our
>>> existing CLI). In general the provisioning tool will be able to
>>> provision three different types of servers:
>>>
>>> - A traditional server with all jar files in the distribution
>>> - A server that uses maven coordinates in module.xml files, with all
>>> artifacts downloaded as part of the provisioning process
>>> - As above, but with artifacts being lazily loaded as needed (not
>>> recommended for production, but I think this may be useful from a
>>> developer point of view)
>>>
>>> The provisioning tool will work from an XML descriptor that describes
>>> the server that is to be built. In general this information will
>>> include:
>>>
>>> - GAV of the feature packs to use
>>> - Filtering information if not all features from a pack are required
>>> (e.g. just give me JAX-RS from the EE pack. In this case the only
>>> modules/subsystems installed from the pack will be modules and subystem
>>> that JAX-RS requires).
>>> - Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
>>> which will allow community users to easily upgrade individual
>>> components.
>>> - Configuration changes that are required (e.g. some way to add a
>>> datasource to the assembled server). The actual form this will take
>>> still needs to be decided. Note that this need to work on both a user
>>> level (a user adding a datasource) and a feature pack level (e.g. the
>>> JON feature packing adding a required data source).
>>> - GAV of deployments to install in the server. This should allow a
>>> server complete with deployments and the necessary config to be
>>> assembled and be immediately ready to be put into service.
>>>
>>> Note that if you just want a full WF install you should be able to
>>> provision it with a single line in the provisioning file, by specifying
>>> the dist feature pack. We will still provide our traditional download,
>>> which will be build by the provisioning tool as part of our build
>>> process.
>>>
>>> The provisioning tool will also be able to upgrade servers, which
>>> basically consists of provisioning a new modules directory. Rollback is
>>> provided by provisioning from an earlier version of provisioning file.
>>> When a server is provisioned the tool will make a backup copy of the
>>> file used, so it should always be possible to examine the provisioning
>>> file that was used to build the current server config.
>>>
>>> Note that when an update is performed on an existing server config will
>>> not be updated, unless the update adds an additional config file, in
>>> which case the new config file will be generated (however existing
>>> config will not be touched).
>>>
>>> Note that as a result of this split we will need to do much more
>>> frequent releases of the individual feature packs, to allow the most
>>> recent code to be integrated into dist.
>>>
>>> Implementation Plan
>>>
>>> The above changes are obviously a big job, and will not happen
>>> overnight. They are also highly likely to conflict with other changes,
>>> so maintaining a long running branch that gets rebased is not a
>>> practical option. Instead the plan it to perform the split in
>>> incremental changes. The basic steps are listed below, some of which
>>> can
>>> be performed in parallel.
>>>
>>> 1) Using the initial implementation of my build plugin (in my
>>> wildfly-build-plugin branch) we split up the server along the lines
>>> above. The code will all stay in the same repo, however the plugin will
>>> be used to build all the individual pieces, which are then assembled as
>>> part of the final build process. Note that the plugin in its current
>>> form does both the build and provision step, and the pack format is
>>> produces is far from the final pack format that we will want to use.
>>>
>>> 2) Split up the test suite into modules based on the features that they
>>> test. This will result in several smaller modules in place of a single
>>> large one, which should also be a usability improvement as individual
>>> tests will be be faster to run, and run times for all tests in a module
>>> should be more manageable.
>>>
>>> 3) Split the core into into own module.
>>>
>>> 4) Split everything else into its own module. As part of this step we
>>> need to make sure we still have the ability to run all tests against
>>> the
>>> full server, as well as against the cut down feature pack version of
>>> the
>>> server.
>>>
>>> 5) Focus on the build an provisioning tool, to implement all the
>>> features above, and to finalize the WF pack format.
>>>
>>> I think that just about covers it. There are still lots of nitty gritty
>>> details that need to be worked out, however I think this covers all the
>>> main aspects of the design. We are planning on starting work on this
>>> basically immediately, as we want to get this implemented as early in
>>> the WF9 cycle as possible.
>>>
>>> Stuart
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:56 a.m.
Just double checked this and it works fine. Basically I just created a
core distro using the script in my wildfly-build-plugin branch, and then
initialized a new git repo with the result.
I then added a new commit, and tested cherry-picking it onto an older
code base, and it worked as expected.
Stuart
Darran Lofthouse wrote:
On 12/06/14 15:48, Stuart Douglas wrote:
> I am not sure if either of these choices will make much difference? In
> general our directory layout will be the same, so it should just be
> possibly to cherry pick patches from WF.
That is probably true but I think this is an important enough point that
before changes are made we know that it will be possible rather than
than just should be possible.
> Stuart
>
> Darran Lofthouse wrote:
>> Please also consider the requirements we need to follow when maintaining
>> the products based on previous AS7/WildFly releases.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 11/06/14 16:57, Stuart Douglas wrote:
>>> Something that I did not cover was how to actually do the split it
>>> terms
>>> of preserving history. We have a few options:
>>>
>>> 1) Just copy the files into a clean repo. There is no history in the
>>> repo, but you could always check the existing wildfly repo if you
>>> really
>>> need it.
>>>
>>> 2) Copy the complete WF repo and then delete the parts that are not
>>> going to be part of the new repo. This leaves complete history, but
>>> means that the check outs will be larger than they should be.
>>>
>>> 3) Use git-filter-branch to create a new repo with just the history of
>>> the relevant files. We still have a small checkout size, but the
>>> history
>>> is still in the repo.
>>>
>>> I think we should go with option 3.
>>>
>>> Stuart
>>>
>>> Stuart Douglas wrote:
>>>> This design proposal covers the inter related tasks of splitting up
>>>> the
>>>> build, and also creating a build/provisioning system that will make it
>>>> easy for end users to consume Wildfly. Apologies for the length,
>>>> but it
>>>> is a complex topic. The first part explains what we are trying to
>>>> achieve, the second part covers how we are planning to actually
>>>> implement it.
>>>>
>>>> The Wildfly code base is over a million lines of java and has a test
>>>> suite that generally takes close to two hours to run in its entirety.
>>>> This makes the project very unwieldily, and the large size and slow
>>>> test
>>>> suite makes development painful.
>>>>
>>>> To deal with this issue we are going to split the Wildfly code base
>>>> into
>>>> smaller discrete repositories. The planned split is as follows:
>>>>
>>>> - Core: just the WF core
>>>> - Arquillian: the arquillian adaptors
>>>> - Servlet: a WF distribution with just Undertow, and some basic EE
>>>> functionality such as naming
>>>> - EE: All the core EE related functionality, EJB's, messaging etc
>>>> - Clustering: The core clustering functionality
>>>> - Console: The management console
>>>> - Dist: brings all the pieces together, and allows us to run all tests
>>>> against a full server
>>>>
>>>> Note that this list is in no way final, and is open to debate. We will
>>>> most likely want to split up the EE component at some point, possibly
>>>> along some kind of web profile/full profile type split.
>>>>
>>>> Each of these repos will build a feature pack, which will contain the
>>>> following:
>>>>
>>>> - Feature specification / description
>>>> - Core version requirements (e.g. WF10)
>>>> - Dependency info on other features (e.g. RestEASY X requires CDI 1.1)
>>>> - module.xml files for all required modules that are not provided by
>>>> other features
>>>> - References to maven GAV's for jars (possibly a level of
indirection
>>>> here, module.xml may just contain the group and artifact, and the
>>>> version may be in a version.properties file to allow it to be easily
>>>> overridden)
>>>> - Default configuration snippet, subsystem snippets are packaged in
>>>> the
>>>> subsystem jars, templates that combine them into config files are part
>>>> of the feature pack.
>>>> - Misc files (e.g. xsds) with indication of where on path to place
>>>> them
>>>>
>>>> Note that a feature pack is not a complete server, it cannot simply be
>>>> extracted and run, it first needs to be assembled into a server by the
>>>> provisioning tool. The feature packs also just contain references to
>>>> the
>>>> maven GAV of required jars, they do not have the actual jars in the
>>>> pack
>>>> (which should make them very lightweight).
>>>>
>>>> Feature packs will be assembled by the WF build tool, which is just a
>>>> maven plugin that will replace our existing hacky collection of ant
>>>> scripts.
>>>>
>>>> Actual server instances will be assembled by the provisioning tool,
>>>> which will be implemented as a library with several different front
>>>> ends, including a maven plugin and a CLI (possibly integrated into our
>>>> existing CLI). In general the provisioning tool will be able to
>>>> provision three different types of servers:
>>>>
>>>> - A traditional server with all jar files in the distribution
>>>> - A server that uses maven coordinates in module.xml files, with all
>>>> artifacts downloaded as part of the provisioning process
>>>> - As above, but with artifacts being lazily loaded as needed (not
>>>> recommended for production, but I think this may be useful from a
>>>> developer point of view)
>>>>
>>>> The provisioning tool will work from an XML descriptor that describes
>>>> the server that is to be built. In general this information will
>>>> include:
>>>>
>>>> - GAV of the feature packs to use
>>>> - Filtering information if not all features from a pack are required
>>>> (e.g. just give me JAX-RS from the EE pack. In this case the only
>>>> modules/subsystems installed from the pack will be modules and
>>>> subystem
>>>> that JAX-RS requires).
>>>> - Version overrides (e.g. give me Reaseasy 3.0.10 instead of 3.0.8),
>>>> which will allow community users to easily upgrade individual
>>>> components.
>>>> - Configuration changes that are required (e.g. some way to add a
>>>> datasource to the assembled server). The actual form this will take
>>>> still needs to be decided. Note that this need to work on both a user
>>>> level (a user adding a datasource) and a feature pack level (e.g. the
>>>> JON feature packing adding a required data source).
>>>> - GAV of deployments to install in the server. This should allow a
>>>> server complete with deployments and the necessary config to be
>>>> assembled and be immediately ready to be put into service.
>>>>
>>>> Note that if you just want a full WF install you should be able to
>>>> provision it with a single line in the provisioning file, by
>>>> specifying
>>>> the dist feature pack. We will still provide our traditional download,
>>>> which will be build by the provisioning tool as part of our build
>>>> process.
>>>>
>>>> The provisioning tool will also be able to upgrade servers, which
>>>> basically consists of provisioning a new modules directory.
>>>> Rollback is
>>>> provided by provisioning from an earlier version of provisioning file.
>>>> When a server is provisioned the tool will make a backup copy of the
>>>> file used, so it should always be possible to examine the provisioning
>>>> file that was used to build the current server config.
>>>>
>>>> Note that when an update is performed on an existing server config
>>>> will
>>>> not be updated, unless the update adds an additional config file, in
>>>> which case the new config file will be generated (however existing
>>>> config will not be touched).
>>>>
>>>> Note that as a result of this split we will need to do much more
>>>> frequent releases of the individual feature packs, to allow the most
>>>> recent code to be integrated into dist.
>>>>
>>>> Implementation Plan
>>>>
>>>> The above changes are obviously a big job, and will not happen
>>>> overnight. They are also highly likely to conflict with other changes,
>>>> so maintaining a long running branch that gets rebased is not a
>>>> practical option. Instead the plan it to perform the split in
>>>> incremental changes. The basic steps are listed below, some of which
>>>> can
>>>> be performed in parallel.
>>>>
>>>> 1) Using the initial implementation of my build plugin (in my
>>>> wildfly-build-plugin branch) we split up the server along the lines
>>>> above. The code will all stay in the same repo, however the plugin
>>>> will
>>>> be used to build all the individual pieces, which are then
>>>> assembled as
>>>> part of the final build process. Note that the plugin in its current
>>>> form does both the build and provision step, and the pack format is
>>>> produces is far from the final pack format that we will want to use.
>>>>
>>>> 2) Split up the test suite into modules based on the features that
>>>> they
>>>> test. This will result in several smaller modules in place of a single
>>>> large one, which should also be a usability improvement as individual
>>>> tests will be be faster to run, and run times for all tests in a
>>>> module
>>>> should be more manageable.
>>>>
>>>> 3) Split the core into into own module.
>>>>
>>>> 4) Split everything else into its own module. As part of this step we
>>>> need to make sure we still have the ability to run all tests against
>>>> the
>>>> full server, as well as against the cut down feature pack version of
>>>> the
>>>> server.
>>>>
>>>> 5) Focus on the build an provisioning tool, to implement all the
>>>> features above, and to finalize the WF pack format.
>>>>
>>>> I think that just about covers it. There are still lots of nitty
>>>> gritty
>>>> details that need to be worked out, however I think this covers all
>>>> the
>>>> main aspects of the design. We are planning on starting work on this
>>>> basically immediately, as we want to get this implemented as early in
>>>> the WF9 cycle as possible.
>>>>
>>>> Stuart
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
3277
days inactive
3279
days old
18 comments
10 participants
participants (10)
-
Brian Stansberry -
Darran Lofthouse -
Emmanuel Hugonnet -
James R. Perkins -
Jason T. Greene -
Peter Cai -
Scott Marlow -
Stuart Douglas -
Stuart Douglas -
Tomaž Cerar