I have two projects (pA, pB).
In pA I have:
Some common Gradle build script files (like foo.gradle, bar.gradle).
gradle.properties defining propertyA=a, propertyB=b.
In pB I am applying foo.gradle and bar.gradle like this:
buildscript {
apply from: '/path/to/foo.gradle', to: buildscript
...
}
apply from: '/path/to/bar.gradle'
In pB I have a gradle.properties where I have propertyA=blah, propertyB=moreBlah.
I don't understand why I'm getting the propties in projectB as a and b.
I don't have these properties defined anywhere else.
Any ideas why this is happening?
Think that this is likely coming from not defining these in the root-project, but in modules A/B. gradle.properties usually resides in the root project - and is common to all the modules. And so if it only will get parsed once, this might explain the behavior; even if it may appear illogical, the order of execution (and parsing that file) might cause that. When flipping to order of modules, it should apply it the other way around. Better move it upwards by one level and find a better way to accomplish the task.
Related
Any difference between this?
Settings.gradle
Case A:
include ':con', ':conlib', 'aaa:test'
vs Case B:
include 'aaa:test'
include ':con'
include ':conlib',
No difference?
or Is it effects to build order or something?
no, order (probably) does not matter. to be clear, this is an educated guess, after following the docs link I didn't learn much, but there are three reasons this has to be true:
1) changing the order of include() calls does not invalidate build caches. this is a good hint that the Gradle team does not see the order of include statements as important.
2) the docs do not stipulate a required or meaningful order. at least that i can tell from the available links.
3) buildSrc is compiled after settings.gradle[.kts]. anytime after Gradle 6 (see here), buildSrc is compiled after settings.gradle.kts, and buildSrc is made available in your build. It stands to reason, then, that the order of include() calls cannot matter, because if they did, it would transitively require a rebuild of your buildSrc, which would invalidate your entire build.
again, just educated guesses based on observations, i hope this helps.
The impact of ordering of include {submodule_name} can be found out in the Gradle doc.
But it should be also noted that it has to be {submodule_name} not {submodule_name}:{gardle_task} (like aaa:test).
So I finally have an awesome and fully functional Gradle build. ...but I'm noticing that the root build.gradle is pretty big. Several pages. I've done some searching but I don't see any examples of how to decomp one of these to smaller parts. Could I, for example, put nebula dependency management in a different file?
You can use
apply from: 'foo.gradle'
apply from: 'bar.gradle'
Is there a way to perform conditional execution of snippet in pom.xml?
my requirement is to copy a file/directory to deploy structure based on variable defined in pom.xml...
eg:
< if >
< equals arg1="package" arg2="package"/>
< then>
....
< /then>
< /if>
Not sure how can I achieve this!
Any pointers would be highly appreciated.
Thanks,
SR
Probably you'll need to use Maven AntRun Plugin for that.
In general, there's no conditional expressions in POM. The only thing similar somehow to this are build profiles that can be activated on some specified conditions, however they probably don't fit into your current case.
And, at the end, my suggestion here. We don't know exactly what your case is about and don't even have any real code snippet, however from my experience it's really unusual to have to use such hackin' stuff in Maven. For me it smells like some problems with Maven understanding, project structure or stuff like that. I may be wrong and maybe your case really needs that, but consider other options to fit into Maven default approach and conventions instead.
Well, you can use Maven's profiles, to do that.
Or you can take a look at Maven's Ant Tasks.
I have about 30 projects and 6 of them must have special (but the same) build process. All of those projects inherit from single parent.
I have defined the special build process in parent. It includes several plugins and lots of configuration.
The inheritance structore is like this:
- global-parent (this is the place where special profile is defined)
-a-parent
-a-ear
-a-war
-a-ejb
-a-special <--
-b-parent
-b-ear
-b-war
-b-ejb
-b-special <--
-c-parent
-c-ear
-c-war
-c-ejb
-c-special <--
etc...
So I cannot make those special projects inherit another pom.
How to set "a flag" in those special projects in pom.xml to run always against special-profile?
For now I've set profile/activation/file/extsts and creates special empty marker file in each special project but this is so ugly.
I've also tried to use maven-properties-plugin to set some system property flag but it is still ugly.
There must be a more legant way. Is this a bad design?
The standard way of doing this is with two levels of parent projects. I've done this with a "global-parent" and a "webapps-parent" with common configuration / profiles just for the webapp components. However, I observe that you need something like "multiple inheritance" which doesn't quite exist in Maven.
Otherwise, the "file exists" activation is acceptable, in my opinion.
Addendum
Without knowing what's exactly "special" about the special modules, it's hard to answer the somewhat subjective question "is this bad design?"
Perhaps a custom plugin that encapsulates all the other plugins would be "better" or "more Maven-ish" but at the end of the day - is your build maintainable and easy to run (i.e. svn co project; cd project; mvn package)?
If so, you've achieved your goals.
Is there a way to perform conditional execution of snippet in pom.xml?
my requirement is to copy a file/directory to deploy structure based on variable defined in pom.xml...
eg:
< if >
< equals arg1="package" arg2="package"/>
< then>
....
< /then>
< /if>
Not sure how can I achieve this!
Any pointers would be highly appreciated.
Thanks,
SR
Probably you'll need to use Maven AntRun Plugin for that.
In general, there's no conditional expressions in POM. The only thing similar somehow to this are build profiles that can be activated on some specified conditions, however they probably don't fit into your current case.
And, at the end, my suggestion here. We don't know exactly what your case is about and don't even have any real code snippet, however from my experience it's really unusual to have to use such hackin' stuff in Maven. For me it smells like some problems with Maven understanding, project structure or stuff like that. I may be wrong and maybe your case really needs that, but consider other options to fit into Maven default approach and conventions instead.
Well, you can use Maven's profiles, to do that.
Or you can take a look at Maven's Ant Tasks.