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.
Related
We use SonarQube against our application. One of the SonarQube rules says:
Selectors of lower specificity should come before overriding selectors of higher specificity
The details are here. As my application has many violations, changing the order by hand isn't really feasible. I'm wondering if there's a way to use scss-lint, stylelint or something else in a "fix" mode that could change the order of the selectors. I looked but couldn't find anything in stylelint. Maybe it can't safely be done automatically, as changing the order could affect specificity and therefore change the application behaviour...
As I personal! know there is no Linter which provide that. (I am curious about it.) But just some thoughts about the need of following that 'rule':
Indeed: writing SASS/CSS the way Selectors with lower specifity comes first is a good practicse. The CSS structure becomes more readable and it is easier to build up your code structure as there is a clearer systematic in your head (and the code).
But just up from the mechanic CSS works there is REALLY NO NEED to do it this way. The code simply doesn't become safer doing so or less safe and the pages don't load slower not doing it. That is what the mechanic of specifity has been done for: as of the specifity not the order of the selectors counts and you are able to write your code in the order you need it. Only if the specifity is the same the order counts.
So, maybe this rule leads to 'better' code. But: NOT ALL RULES NEEDS TO BE FULLFILLED. Not all rules Google tries to establish with their best practice rules they offer in their browser, nor all rules other analysis tools provide needs to be followed.
And if not in this project as it needs resources to correct it ... it maybe could but has not be a target for next project ;-)
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).
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.
I would like to know if the following is possible in Scala (but I think the question can be applied also to Java):
Create a Scala file dynamically (ok, no problem here)
Compile it (I don't think this would be a real problem)
Load/Unload the new class dynamically
Aside from knowing if dynamic code loading/reloading is possible (it's possible in Java so I think it's feasible also in Scala) I would like also to know the implication of this in terms of performance degradation (I could have many many classes, with no name clash but really many of them!).
TIA!
P.S.: I know other questions about class loading in Scala exist, but I haven't been able to find an answer about performance!
Yes, everything you want to do is certainly possible. You might like to take a look at ScalaMock, which is an example of creating Scala source code dynamically. And at SBT which is an example of calling the compiler from code. And then there are many different systems that load classes dynamically - look at the documentation for loadLibrary as a starting point.
But, depending on what you want to achieve, you might like to look at Scala Macros instead. They provide the same kind of flexibility as you would get by generating source code and then compiling it, but without many of the downsides of that approach. The original version of ScalaMock used to work by generating source code, but I'm in the process of moving to using macros instead.
It's all possible in Scala, as is clearly demonstrated by the REPL. It's even going to be relatively easy with Scala 2.10.