I'm looking for a quick way, for any given multi-module project, to show a quick overview of the project hierarchy including only the modules in the project, excluding external dependencies.
eg for a project
project root
+- A
+- B
+- C
+- D
+- E
+- F
+- G
+- H
I would like to see a quick, single screen view for A-H (like it is depicted here) that gives me a fast digestible view to get an idea of a project structure. Ideally it would be command line output, not a platform specific solution (I note there is a tool for VisualStudio).
mvn dependency:tree is great but too verbose for this case, I suppose I could grep and cut the output apart but feels like there should be an easier way (ie another plugin).
You can filter the dependency tree: http://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html
So, if your group ID was com.foo.bar, you could get the projects in that group ID with:
mvn dependency:tree -Dincludes=com.foo.bar
Assuming all of your project's modules are within that group, that would cover your use case.
You could try this module here: MavenStructurePlugin
I had the same problem as you did and found it quite useful.
The output is pretty much what you seem to want:
test
|
|__ a
|
|__ b
|
|
\__ c
|
|__ d
|
|__ e
|
|__ f
Related
Is there a way to control where the .iws and .ipr files get generated? For instance, I have a project that is setup like this:
masterProj
|
+- devScripts
+- subProj1
+- subProj2
+- subProjX
Where the devScripts folder contains all our common build related stuff plus some code to boot-strap our Java apps. Currently it generates Eclipse projects, but I'd like to add the ability to generate IntelliJ projects as well. When we create our Eclipse workspaces we do that at the masterProj level, then import the project folders, including devScripts, under that. But if I run the gradle command in the devScripts folder for IntelliJ it places the .iws and .ipr files under devScripts, but it really should be one folder up.
What I'd like to end up with is something like:
masterProj
masterProj.iws
masterProj.ipr
|
+- devScripts
devScritps.iml
+- subProj1
subProj1.iml
+- subProj2
subProj2.iml
+- subProjX
subProjX.iml
Maybe I am trying to shove a round-peg into a square hole (as some of my research suggests) but I could not find any way to properly confirm or deny if what I am trying to do is possible or reasonable with Maven. Sadly, changing the nature of the project is not an option. Sorry for being verbose, but I want to make sure I explain the situation properly. I am somewhat of a maven newbie as well.
I have a multi-module project whose deliverable is separate .exe files for each of those modules. This project has different features depending on the client. Most are the same but some modules will include or exclude certain parts of code.
Hyper-Simplified Example
Client A
Module1
Module2
has feature x, feature y
Client B
Module1
Module2
has feature x, feature z
Currently, it is built with some batch files calling msbuild on pre-configured VisualStudio projects, which have the individual feature's source folders added to them.
Is there Maven-ish way of building the different versions individually without having to store the duplicate code like this example below?
project
+- root
| +- pom.xml
+- Module1
| +- pom.xml
| +- src
| | +- main
| | | +- c++
| | | +- include
+ Module2A
| +- pom.xml
| +- src
| | +- main
| | | +- c++
| | | | +- feature x
| | | | +- feature y
| | | +- include
+ Module2B
| +- pom.xml
| +- src
| | +- main
| | | +- c++
| | | | +- feature x
| | | | +- feature z
| | | +- include
Module2A and Module2B would both need to output Module2.exe
Ways that I have looked into possibly trying to use are profiles or some kind of inherited pom structure but neither seem to fit the bill. I really appreciate any insight someone has of techniques or plug-ins to help with this.
I have a multi-module Maven project (one level deep only). I like not to have to repeat the same things in all child projects, but how can I still do it (avoir repeating) when the parent project itself needs a different setting ?
The example I’m facing is when trying to produce a common folder for all artifacts and dependencies (but I can imagine other equivalent situations):
<properties>
<__.build.folder>../last_build</__.build.folder>
</properties>
Of course, this will lead to a situation where I have two last_build folder, one common to all child projects, one in the upper level folder.
How can I avoid that without having to duplicate the same setting in every child pom.xml ?
Can I use profiles ?
I don’t know, I’m new to Maven.
Thanks
Edit :
In this example, last_build is a subfolder of the folder containing the parent pom.xml. The child projects are all in other subfolders, from which last_build has to be addressed as "../last_build" - but not in the parent pom.xml !
|
*--rootFolder
| |
| *--last_build // aggregation folder
| |
| *--subProject1
| | |
| | *--pom.xml (../last_build)
| |
| *--subProject2
| | |
| | *--pom.xml (../last_build)
| |
| *--subProject3
| | |
| | *--pom.xml (../last_build)
| |
| *--pom.xml (last_build) // different here for the parent project
I don't think you're proceeding down a very useful path and I think that you may be confused about a few things.
First, at the highest level, your root or parent pom, there should be no project, no code, no resources, and no artifact, so there should also be no output or need for an output directory. All you should have at the highest level is the parent pom and subdirectories containing modules.
The next problem is that you think you need a common build folder. I am hard pushed to imagine a rational scenario where that would be necessary. The artifacts one typically builds in maven are self-contained jars/wars -- one per module, and these are cached in the local repo whenever you build through the install lifecycle. They can be used in situ from there.
I have a scenario where its step definitions resides in multiple files. For instance the login step resides in login_steps.rb and a search related step resides in search_steps.rb
Cucumber outputs undefined steps for any step that is not in login_steps.rb. The step definitions are run only when its present in login_steps.rb. Is it required to place all the step definitions of a scenario in the same file?
My folder structure
Project folder
└─ features
├─ pages
├─ scenarios
├─ step_definitions
└─ support
Command I used:
cucumber -r features features\scenarios\Test.feature
The whole point to Cucumber and the POM is that you have flexibility and do not need to re-write your steps per feature file. This is what my directory structure looks like:
Root
- features
- step_definitions
- step_definition.rb
- support
- env.rb
- lib
- BasePage.rb
- feature.feature
Basically, with this directory structure, it doesn't matter where your step definitions are AS LONG AS YOU REQUIRE THE SPECIFIC PAGE YOU'RE REFERENCING (your BasePage.rb file, for example)
require File.join(File.dirname(__FILE__), '..', '..', 'lib', 'pages', 'BasePage')
And /^I do something$/ do
#page = BasePage.new(#test_env)
#page.verify_el(css)
end
I'm not familiar with the specifics of RoR and cucumber, but I do use cucumber-jvm. Using steps from different files is supported. Note the documentation https://github.com/cucumber/cucumber/wiki/Cucumber-Backgrounder#where-do-i-put-tests specifically mentions it.
Sorry I can't be more help with the specific issue, but what you are trying to do (use step from different files) is workable.
This might be a "violation" but I would combine the answers from Whitney Imura and Dave W just to make the answer more clear...
You ask:
"Is it required to place all the step
definitions of a scenario in the same file?"
No. You can place your step definitions in logically distinct files within various folders, as you see fit (example below). After all, it is just ruby code.
Essentially Your command is correct for running an individual feature that has step definitions in various other folders...
cucumber -r features features\entities\entity.feature
If you do not run it as above, you will get missing stepdefs... Here I execute tests on a current project as a means to demonstrate:
cucumber
60 scenarios (14 undefined, 46 passed)
409 steps (32 skipped, 26 undefined, 351 passed)
cucumber -r features
60 scenarios (60 passed)
409 steps (409 passed)
As described in the Cucumber documentation, you can arrange your tests to suite your logical breakdown of your features:
|__ features
| |__ entities
| | |__ entity.feature
| | |__ step_definitions
| | |__ anything.rb
| | |__ entity_steps.rb
| |__ locations
| | |__ location.feature
| | |__ step_definitions
| | |__location_steps.rb
| |__ sites
| | |__ step_definitions
| |__ step_definitions
| | |__ local_assert_steps.rb
| | |__ local_crud_response_steps.rb
| | |__ local_email_steps.rb
| | |__ local_file_steps.rb
| | |__ local_script_steps.rb
| | |__ local_steps.rb
| | |__ local_web_steps.rb
` | |__ local_xml_file_steps.rb
|__ support
|__ env.rb
|__ local_env.rb
|__ local_transforms.rb
Running mvn idea:idea to generate IntelliJ IDEA project files we stumble into a folder that must be avoided, let's say .avoidMe, which is located inside every folder as a placeholder.
folder1
|
+- .avoidMe
|
+- folder2
| |
| +- .avoidMe
|
+- folder3
| |
| +- .avoidMe
. . .
I've looked at idea:idea exclude options but none of them accepts wildcars (e.g. .avoidMe , "/.avoidMe/" or else ) so that I need to add every possible path to the exclude property ( e.g. folder1/.avoidMe,folder1/folder2/.avoidMe,folder1/folder3/.avoidMe )
The idea here is to use it to run IDEA inspections and publish the results into Sonar.
Is there any way to exclude file search using a wildcard or any other trick than exhaustive path search ?
are there any other ways to run IDEA inspections and publish them into Sonar ?
You should never use mvn idea:idea, it's obsolete and was not updated for years. It's also known to generate incorrect projects with the bugs that will be hard to trace later.
Instead, just import pom.xml in IDEA, project files will be generated by IDEA automatically.
You can then Exclude certain folders in Project Structure | Modules | Sources. Be aware that this configuration will be lost on the next reimport.
There is another configuration to exclude folders that is global and will be not lost on reimport: Settings | File Types | Ignore files and folders.