Good evening, people.
I've already wasted the whole day trying to manage with maven.
I have the following project structure:
base-pom.xml
|-module1
| |-module1-resources
|-module2
| |-module2-resources
|-module3
| |module3-resources
|
|-general-resources
I'm looking for some way of getting the following output structure:
output-folder
|-libs-folder/3rdrarty-jars
|-config-folder/general-resources not-packed
|-module1.jar
|-module2.jar
|-module3.jar
|-module1-resources not-packed
|-module2-resources not-packed
|-module3-resources not-packed
Also a thing to mention: classpath of my project modules should be something like this:
Class-Path: /config-folder module2.jar module3.jar libs/3rdparty_1.jar libs/3rdparty_2.jar libs/3rdparty_3.jar
I don't know if maven allows to have such a complicated output structure - all samples, i've found having wasted a lot of time, show nothing even similar to my requirements.
Related
When running glide install on my project, I get the following error:
[ERROR] Error scanning github.com/golang/protobuf/proto/testdata: cannot find package "." in:
/Users/bevernie/.glide/cache/src/https-github.com-golang-protobuf/proto/testdata
[ERROR] Failed to retrieve a list of dependencies: Error resolving imports
When checking protobuf's source code, I can in fact see that there is no such package. I however don't directly use protobuf, so the error must come from one of the dependencies I use.
When running glide tree on my project, there is only one instance of github.com/golang/protobuf/proto/testdata:
|-- github.com/golang/protobuf/proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
| |-- github.com/golang/protobuf/proto/test_proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto/test_proto)
| | |-- (Recursion) github.com/golang/protobuf/proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
| |-- github.com/golang/protobuf/ptypes/any (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/ptypes/any)
| | |-- (Recursion) github.com/golang/protobuf/proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
github.com/golang/protobuf/proto/testdata (glide get github.com/golang/protobuf/proto/testdata)
|-- github.com/golang/protobuf/ptypes/any (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/ptypes/any)
| |-- github.com/golang/protobuf/proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
| | |-- github.com/golang/protobuf/proto/test_proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto/test_proto)
| | | |-- (Recursion) github.com/golang/protobuf/proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
| | |-- (Recursion) github.com/golang/protobuf/ptypes/any (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/ptypes/any)
which doesn't really help me pinpoint the source of the problem.
Do you have any suggestions as of how to fix the issues?
My project was compiling just fine until a week or two ago (I use Docker to deploy in production, so the glide install was run every time and never failed before that, and I haven't added any new dependency recently).
Before your own PR (995), there was glide issue 968
It looks like it's caused by a repository's structure changing, i.e. a sub-package being moved, or removed entirely.
Workarounds proposed by Elliot Wright (seeruk):
If the package that has been updated is under your own control, then I've since found it easier to use some of the newer Go features like type aliases to ease the pain from refactoring.
So, instead of just moving a package, move it and then make aliases to the new location in the old one so that your older code still works.
Then, gradually move things over. Basically just mark things as deprecated but make sure they're still usable for a little while until you've ported new code over.
If the package is not in your control, then you can always clone the version you want manually to your vendor folder and make your updates in your code.
Once you're done, Glide should let you update again.
If it's much more complex, sometimes it's even easier to revert to using go get until you're done updating packages, and rely on your $GOPATH contents.
It's far from ideal, but there are ways you can work around it at least.
In the mean time, I've also made an issue about this on dep.
I think they're looking into a way of disabling this kind of check if you just want the tool to trust you as the developer.
So you can check if you have the same issue using godep, or even the bleeding-edge vgo.
I'm following Maven's Standard Directory Layout for my project.
Is there a preferred directory to put my checkstyle.xml file? I've seen it on at least 3 possible locations:
src/main/resources/checkstyle.xml
src/main/checkstyle/checkstyle.xml - Example: Joda-Time
src/checkstyle/checkstyle.xml - Example: Spring Boot
Since this is mostly a file for developers, the first option gives me doubts. Would it make sense to include checkstyle.xml into the JAR file?
Thanks,
Fede
Putting checkstyle.xml in src directory doesn't really make sense, as it is not part of source code.
The most common convention I've observed in my projects is putting it into config/checkstyle/checkstyle.xml. Thousands of projects use it (filename:checkstyle.xml path:config/checkstyle) and Gradle uses this location by default.
I have a maven multi module project like so
modA
modB
modC
modD
custom-pom.xml
And here the pom
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.xx.xx.correspondence</groupId>
<artifactId>xxHudsonTP</artifactId>
<version>1</version>
<packaging>pom</packaging>
<modules>
<module>modA</module>
<module>modB</module>
</modules>
</project>
Now, when I invoke release:branch with the intent of creating a branch on custom-pom.xml like so
mvn release:branch -DbranchName=new-branch -f custom-pom.xml
It ends up creating a branch with all 4 modules.
Is there any way using release plugin to make sure only selected modules are branched without resorting to branching each module separately.?
Any other maven plugins..?
Edited
The background of this questions stems from the fact that the svn repo that I am working with has about 20 different modules with 4 different artifacts that they need to generate. I could have easily gone with grouping the modules into sub folders, but since a few modules are common between
the artifacts, I didn't think too much into splitting them up.
I understand that branching all modules is trivial and probably simple to manage, but the other developers in the team have this feeling of dealing with too much for accomplishing simple tasks like a one line bug fix. Hope that helps.
As far as I know, there is no solution to answer what you asked.
You have to keep in mind that multimodule projects (aggregation) means that every submodule share the same application lifecycle. This is really what modules and aggregation are intended to.
I see 2 differents workarounds.
You have 2 real differents lifecycles
There is indeed 2 groups in your 4 submodules, lets say group1 : A and B, group 2, C and D.
Split them into 2 new projects :
Group1
|-- Project A
| `-- pom.xml
|-- Project B
| `-- pom.xml
`-- pom.xml
Group2
|-- Project C
| `-- pom.xml
|-- Project D
| `-- pom.xml
`-- pom.xml
Pro : You may be able to branch group 1 and 2 separately.
Cons : You won't be able anymore to perform simultaneaous action (in one command) on every project (like realeasing or builind them)
You really have 1 single lifecycle
This is probably the case. You may want to branch only 1 or 2 submodules because of your very good understanding of the underlying architecture of the project. An so, you don't want to deal with too many conf / artifacts / time building ... Indeed, all those reasons may have indirects impacts that you won't see. Always build the whole project !
If this is for space saving (however most of SCM allow you to branch with few space, like Yorkw said), because your SCM allow you to get only submodules (and maybe both, like for Clearcase) ... sorry, there is no solution. This is the maven way, and I think this is the good one. (ok it's a little bit demagogic, but I really believe what I said)
Don't hesitate to explain us why you really want to branch only a subset of your modules. If there is another reason, you may have more accurate(s) solution(s).
I don't know if I totally got the concept wrong, but I want to create several projects with dependencies to other projects which are not part of the directory structure of a parent project. I know that the normal way of doing this would be to use an external dependency which fetches from some external repository. But in this case, where let's say in project called 'F' a framework is developed, which is used in project 'P'., then P uses F, but F should IMO not necessarily be a sub-project of P as P is only used to test-drive the development of F (but it's not only a unit test). Later in the process, when F is stable, F is separated and can be consumed by other projects via a repository. But during development of F with P as it's test case, it would be nice if that round-trip through the repository could be omitted.
To make matters worse, for the initial development there is more than one test-driving consumer project, which all need to have a dependency to F, but not via an external repository.
My idea is to develop F in some place on the disk with it's own git reposity. The other P like projects reside somewhere else on the disk and have a local file system based dependency to F. Would such a construct be possible in Gradle? If so, where do I start? I scanned the Java examples but couldn't find an appropriate example.
Any ideas?
The Gradle project hierarchy is fully virtual. It just has the default that the physical location corresponds to the virtual hierarchy. But you have complete control over this. See: http://gradle.org/0.9-rc-1/docs/userguide/build_lifecycle.html#sec:settings_file
Regarding your other ideas have a look at the following Jira: http://jira.codehaus.org/browse/GRADLE-1014
You could consider a folder hierarchy like this one:
Main folder
|- F folder
| |- .git
| |- sources
| |- build.gradle (with parts specific to F)
|- P folder
| |- sources
| |- build.gradle (with part specific to P)
|- build.gradle (with common parts)
|- settings.gradle
So you can always decide to run gradle on either the F project, the P project or the two alltoegether. It will also allows you to promote you F project alone without the P or any other side projects.
For more up-to-date information, check the Multi Project Builds chapter of the Gradle documentation.
I have a monolith Gradle project that contains multiple subprojects, each with its own subprojects, like so:
project
|
|-- subprojectA
| |-- models
|
|-- subprojectB
| |-- models
This compiles fine but the issue is when I try to add a dependency on :subprojectB:models to :subprojectA:models, Gradle thinks :subprojectA:models is trying to add a dependency on itself and complains of a circular dependency, even though I specify the fully qualified path like so (in subprojectA's build.gradle):
compile project(':subprojectB:models')
How can I avoid this? Can subprojects not have the same name even if their paths are unique?
Project identity for dependency resolution is based on the group:name:version or GAV coordinates, as explained in the linked Gradle issue.
So you need to make sure your different models project have different GAVs.
One way to make this happen is to make the subprojectA (or B) part of the group.
Another way is to assign names that are not based on the containing folder.
That's currently a known Gradle issue as Gradle by default uses the parent directory name as the project name. You can work around the issue as described here by assigning unique subproject names in the root project's settings.gradle like so:
include ':subprojectA:models', ':subprojectB:models'
project(':subprojectA:models-a').projectDir = file('subprojectA/models')
project(':subprojectB:models-b').projectDir = file('subprojectA/models')