jdaugherty opened a new pull request, #14924:
URL: https://github.com/apache/grails-core/pull/14924
This PR is a first step at adding meta-projects that export common
dependencies for a Grails Application. Assuming Grails is a platform, we can
consider some base files to always be included. Users should not have to know
the nuances of each library and which to include. If they are required to,
then it will make the framework harder to use.
This is especially true in Grails given that we have numerous ASTs spread
across many libraries. Previously the `controllers` project often acted as an
aggregator, but longer term we may want to push more of these dependency type
libraries to make it easier to start / create a Grails project.
Take Spring as an example, creating a base Spring application (from
start.spring.io) only includes the following:
implementation 'org.springframework.boot:spring-boot-starter'
testImplementation
'org.springframework.boot:spring-boot-starter-test'
testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
Effectively, this is the test & production dependencies. One of the core
tenants of Grails is convention over configuration, but by having an ever
growing list of libraries, we're doing the opposite. We're making Grails
harder to use and harder to understand what library is used for what.
One of the major reasons we decided end users shouldn't include nested
projects under the `org.apache.grails.*` coordinate space was for this same
reasoning - users do not have to know the internals or relationships of the
various Grails libraries. Instead, they should only include projects in the
`org.apache.grails` coordinate space. Said another way, a coordinate of
`org.apache.grails.views` could effectively be viewed as `package private`.
This way if the core library or underlying implementation changes, it's
transparent to the end user. The `grails-dependencies-*` projects are a
further evolution of this approach.
Here are some other usages for these libraries:
1. grails-dependencies-all - plugin authors can have their plugins add the
following gradle dependencies:
compileOnly 'grails-dependencies-all'
testImplementation 'grails-dependencies-all'
Then, those plugins will not include specific Grails versions in the
POM/modules and as long as there is API compatibility the plugins will stay
compatible for future releases. Without this, the plugin authors will have to
duplicate a large amount of dependencies. Worse the plugin author will have to
understand Grails internals because we selectively include ASTs in some of our
projects. By including all of the dependencies at compile, we can ensure their
classes are always transformed as expected.
2. grails-dependencies-assets - end applications can include these in the
`testAndDevelopmentOnly` scope to include the base Grails assets. Longer term,
we've talked about pushing more of our images into a package. This package can
be that package so that the Grails logos, etc can exist in a publish artifact
instead of being copied to every single project.
3. grails-dependencies-test - easily import the test libraries that are
commonly used to test web applications.
Of course, developers do not have to include these "all inclusive" libraries
and can still choose to manage each dependency in the `org.apache.grails`
coordinate space. This is likely very important for developers who are
sensitive to extremely large jar/war files.
However, the approach of managing each dependency that is from inside of the
Grails platform makes plugins fragile and harder to maintain. As we move
faster with Grails releases & tracking upstream Spring releases, it's important
that we can continue to move fast and not have to release as often as we update
internal libraries Grails uses. Otherwise, if Spring releases 12 times a year,
we're suddenly releasing all of these 12 times: grails-core, spring security,
redis, mail, audit logging, build test data, quartz, and many more. Assuming
just this list, that's 84 releases (12*7). It's just not going to be practical
if we have to update them every time.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
