You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@netbeans.apache.org by "Scott Palmer (Jira)" <ji...@apache.org> on 2020/04/06 21:46:00 UTC
[jira] [Comment Edited] (NETBEANS-4126) Tasks on Sub-projects of a
Gradle build are invoked by changing to the sub-project directory first,
this can change the project hierarchy
[ 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:45 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, 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.
> 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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: commits-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists