[
https://issues.apache.org/jira/browse/NETBEANS-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076700#comment-17076700
]
Scott Palmer commented on NETBEANS-4126:
----------------------------------------
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: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
