[
https://issues.apache.org/jira/browse/NETBEANS-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076700#comment-17076700
]
Scott Palmer edited comment on NETBEANS-4126 at 4/6/20, 9:46 PM:
-----------------------------------------------------------------
I won't deny that the setup is a bit... unconventional.
This is a project that started before Gradle had the concept of Composite
Builds (https://docs.gradle.org/current/userguide/composite_builds.html), which
would likely have been the better way to go had it been available at the time.
Instead, I have a set of libraries with some dependencies between them. All of
them are part of a framework that is delivered as a rather hefty SDK. It is
useful during development to have these libraries behave as peer projects in a
multi-project build as changes to LibraryA are developed alongside
corresponding changes to LibraryB, so using project(':LibraryA') style
dependencies makes everything build smoothly from the root project. However,
each library is released as a separate JAR with it's own version.
When we do a release of an individual sub-project we run the build from within
the sub-project. For that purpose the library only depends on other released
libraries. The build logic handles the dependencies, automatically flipping
from peer projects when building from the root, to explicitly versioned
releases of the peer libraries when building from within a particular
sub-project. Since the working copy is always in a -SNAPSHOT state for each
library, the release build does not work using peer projects as dependencies,
because -SNAPSHOT dependencies are not allowed in a release.
So day-to-day development is done with the projects behaving as peers in a
multi-project build, with inter-project dependencies, but releases are built
with the sub-projects behaving as root projects with dependencies being the
latest release of the peers, referenced as normal dependencies.
I may seem like an anti-pattern, and perhaps it is, but it was working well and
really sped up development not having to explicitly build new snapshots of
dependencies all the time. So we didn't take on the job of converting our root
project to use composite builds instead, and lose the ability to build a
subproject and have it automatically build any peer dependencies that needed to
be built.
Edit: I should note that we used to build the sub-projects with the -u option
when doing a release, until it was deprecated. So initially the sub-projects
didn't have settings.gradle files. Those were added to workaround the
deprecation of the -u option at a later time.
was (Author: swpalmer):
I won't deny that the setup is a bit... unconventional.
This is a project that started before Gradle had the concept of Composite
Builds (https://docs.gradle.org/current/userguide/composite_builds.html), which
would likely have been the better way to go had it been available at the time.
Instead, I have a set of libraries with some dependencies between them. All of
them are part of a framework that is delivered as a rather hefty SDK. It is
useful during development to have these libraries behave as peer projects in a
multi-project build as changes to LibraryA are developed alongside
corresponding changes to LibraryB, so using project(':LibraryA') style
dependencies makes everything build smoothly from the root project. However,
each library is released as a separate JAR with it's own version.
When we do a release of an individual sub-project we run the build from within
the sub-project. For that purpose the library only depends on other released
libraries. The build logic handles the dependencies, automatically flipping
from peer projects when building from the root, to explicitly versioned
releases of the peer libraries when building from within a particular
sub-project. Since the working copy is always in a -SNAPSHOT state for each
library, the release build does not work using peer projects as dependencies,
because -SNAPSHOT dependencies are not allowed in a release.
So day-to-day development is done with the projects behaving as peers in a
multi-project build, with inter-project dependencies, but releases are built
with the sub-projects behaving as root projects with dependencies being the
latest release of the peers, referenced as normal dependencies.
I may seem like an anti-pattern, and perhaps it is, but it was working well and
really sped up development not having to explicitly build new snapshots of
dependencies all the time. So we didn't take on the job of converting our root
project to use composite builds instead, and lose the ability to build a
subproject and have it automatically build any peer dependencies that needed to
be built.
Edit: I should note that we used to build the sub-projects with the -u option,
until it was deprecated. So initially the sub-projects didn't have
settings.gradle files. Those were added to workaround the deprecation of the
-u option at a later time.
> Tasks on Sub-projects of a Gradle build are invoked by changing to the
> sub-project directory first, this can change the project hierarchy
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: NETBEANS-4126
> URL: https://issues.apache.org/jira/browse/NETBEANS-4126
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Gradle
> Affects Versions: 11.3
> Environment: macOS 10.15.4
> Gradle 6.3
> NetBeans 11.3 running on JDK-14
> Project configured to compile with JDK-8
> Reporter: Scott Palmer
> Assignee: Laszlo Kishalmi
> Priority: Major
>
> I have a multi-project Gradle project with a parent project and several
> sub-projects. However, in the sub-project folders I have a settings.gradle
> file, so if gradle is invoked from within the sub-folder the sub-project
> behaves as a root project. This is intentional.
> When I open the parent project in NetBeans, the sub-projects are correctly
> identified as belong to the parent project, but when build actions are done
> on them the gradle command is invoked from the sub-folder, e.g.:
> JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home"
> cd /Users/scott/dev/Kayak/MyParentProject/MySubProject;
> /Users/scott/dev/gradle/bin/gradle --configure-on-demand -x check build
> Instead the build target should be augmented with the project path:
> JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home"
> cd /Users/scott/dev/Kayak/MyParentProject; /Users/scott/dev/gradle/bin/gradle
> --configure-on-demand -x check :MySubProject:build
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
