I am working with the following project structure
parent
+-- pom.xml (parent and reactor)
module-1
+-- pom.xml
module-...
+-- pom.xml
I would like to be able to do a mvn release:prepare on the parent project and have the resulting war as well as a consistent tag structure in svn.
Right now everything seems to work fine except the tagging of the modules, that is, a mvn release:prepare will tag the parent project but none of the child projects. I have already found and tried the switch commitByProject in the configuration of the parent-pom. I have entered and removed scm configurations in the moduel-poms, I have tried configuring the release-plugin in the module-poms all to no avail. The release-step never asks me for a tagname for any of the modules and consequently does not create a tag later on in the project.
How do I configure parent and module such that a mvn release:prepare will tag the modules?
I would suggest to reorganize the structure to fit Maven's best practice like the following:
root (pom.xml; parent)
+-- module-1 (pom.xml)
+-- module-2 (pom.xml)
+-- module-...
This will make your life easier with Maven and also in doing a release via mvn release:prepare etc.
I assume you have in VCS the following folder structure:
root
+-- parent (pom.xml)
+-- module-1 (pom.xml)
+-- module-2 (pom.xml)
+-- module-...
root is the folder which is checkedout from version control (trunk in SVN; or master git).
If you have given the correct relative path to the parent in the given modules everything should work without any problem....Configuring the scm part in parent.
After further, countless hours of searching I no longer assume, it is possible to tag each module independent from the others using the maven release plugin.
I have found (and lost) an explicit comment, that this is not possible with the release plugin and there are further hints, for example, that the release plugin only accepts exactly one scm tag in non-interactive mode.
As I'm a Java developer, not a maven developer I refuse to change my package structure and thus am stuck with doing the tagging by hand.
Related
I have a bunch of static files (basically favicons, apple-site-icons, etc) that I want to be at the root of _site when it's built. Currently they're just sitting at the root of my main code folder (along with _posts, _scss, _layouts, etc). It builds fine but it would be nice to move them into a subdirectory so the main directory isn't cluttered up (it's an OCD thing).
Is there any folder where I can put these items so they automatically copy to the root of _site when I build? I know I can write a script to do this and trigger it after the build, and there's probably an extension I could lean on, but I'm looking for a solution that just automatically moves them when I run jekyll build for simplicity.
NBD if I can't do it, just curious because I'm kind of a neat freak.
Thanks!
Jekyll allows you to do exactly that using permalinks.
Permalinks are the output path for your pages, posts, or collections. They allow you to structure the directories of your source code different from the directories in your output.
A simple example extracted from the official page is a case where you have /my-pages/about-me.html with the front matter as follows:
---
permalink: /about/
---
This way you specify the output url. In this example, you could access it in local with localhost:4000/about/
The source option. You can specify this in your _config.yml or as a command line option (https://jekyllrb.com/docs/configuration/options/). How you set this has slightly different requirements/implications.
First, move everything that belongs to the Jekyll site into a folder (e.g. "src").
Then set one of these up (assuming you have a Gemfile):
Command line option with root Gemfile:
Keep Gemfile in the root folder
Run bundle install
Run bundle exec jekyll serve --source src
Command line option with nested Gemfile:
Run BUNDLE_GEMFILE=src/Gemfile bundle install
Run BUNDLE_GEMFILE=src/Gemfile bundle exec jekyll serve --source src
Config file option:
Keep Gemfile and _config.yml in the root folder
Add source: src somewhere in your _config.yml
Run bundle install
Run bundle exec jekyll serve
Each solution here might work better with other external services building your site. There are likely other ways to set this up, but this should get you started.
In the Polymer Starter Kit, every reference to the bower_components subdirectory refers to a node just below the app directory. However, (at least in my version of PSK) the bower_components subdirectory is one level up from the app directory. In other words, the bower_components subdirectory is actually located in the project root directory.
Am I just miscounting my directory nodes? Or does this have something to do with how gulp and maybe vulcanize work? Or is it something else altogether that I'm not understanding?
For example, in index.html there is this script tag:
index.html
<script src="bower_components/webcomponentsjs/webcomponents-lite.js"></script>
which suggests the bower_components directory is at the same level as index.html. But it's not. bower_components is actually one level up.
Same for element imports.
Compilation of responses from Polymer Slack Site:
Response #1:
yeah, gulp basically builds everything into a build and the web server serves the build folder instead of the project. I don’t remember what’s the name of the build folder in starter kit in particular, but for most project it works as I described
Response #2:
it’s specific to PSK. The local server mounts that directory and serves it as if it were inside app. I just sent in a PR to change this because it’s confusing
Is it possible to use Susy with Jekyll? If so, how?
I tried adding 'susy' to my Gemfile and bundle install'ing, then adding susy to my gems array in config.yml:
// _config.yml
...
gems:
- 'jekyll-compass'
- 'susy'
and following the instructions in Jekyll's docs, placing #import 'susy' in my /css/style.scss file. However, I get an error:
File to import not found or unreadable: susy.
jekyll-compass lets you configure Compass. There's more info in its readme, but for susy I just needed to add a _data/compass.yml file, and add
require:
- susy
to it.
Also, jekyll-compass expects your main entry style.scss to be under _sass, not css (like Jekyll's out of the box sass support does). I'm sure this is configurable as well.
If you're willing to install susy with bower, you can just symlink the files under bower_components/susy/sass to the _sass directory (ln -s bower_components/susy/sass/* _sass. I have a fairly minimal working example on GitHub.
The CSS is generated properly and served here for now (though that link will hopefully rapidly become out of sync with the git commit referenced above).
I have a maven multi-modul project. The structure looks like:
-modulA (Main project)
- pom.xml
-parentModul (Aggregator)
- pom.xml
- ModulB (Integration Test Project)
-pom.xml
Package definition is like:
<project ...>
<modules>
<module>../modulA</module>
<module>ModulB</module>
</modules>
One of the moduls (ModulA) has the same hierarchy level, The other is in the parent modul.
I try to add a job in Jenkins to build all automatically. (clean package)..
How should I configure the job that parentModul finds the other modules and build the project.??
Add another aggregator. Place modulA and parentModul in the same directory and one level above them, simply add another pom like this:
aggregator/
|- modulA/
| |- pom.xml
|- parentModul/
| |- modulB/
| | |- pom.xml
| |- pom.xml
|- pom.xml
In the aggregator/pom.xml define a modules section as follows:
<project ...>
<modules>
<module>modulA</module>
<module>parentModul</module>
</modules>
</project>
One solution would be to use SVN Externals to assemble sane Maven project workspace from insane SVN structure even accross different svn servers. Using svn external is not an ideal solution as it will cause problems with maven release plugin and with CI's SCM polling in certain configuration. They tell you : "You should not use svn externals" as makes life more difficult. But so do leg cast and crutches but when you have broken leg (or svn structure that is fubar) you really do not mind the inconvenience.
There several ways of doing this, depending on your SVN structure and desired workspace structure:
svn co modulA
cd modulA
svn propedit svn:externals . NB: Note the (curdir) dot at the end of line!
add following line:
parentModul http://path.to.your.svn.location.of.parentModul
svn ci -m "added externals for parent"
svn up
and the svn retrieves (and commits) you code to following workspace structure
modulA/
| |- pom.xml
parentModul/
|- modulB/
| |- pom.xml
|- pom.xml
pom.xml
Or you could add a new directory to SVN 'workplace' and add new pom.xml there and get all modules you could ever want via svn externals to one level (or to multiple levels).
In my case it is not possible to add another parent project. ModulA is already checked in SVN independently from the others.
This indicates that you're probably wrong in putting moduleA in the <modules> section. If moduleA has different life cycle, then you should include it as a dependency.
I am new to Jenkins/Hudson and am trying to migrate a C make-based project from buildbot. For legacy reasons, the build system is hard-coded to build outside of the versioned source tree (git), one directory above, in a separate directory. E.g.:
workspace
.git
foo
bar
build
artifacts
Besides the fact that it ends up creating a directory outside the workspace, Jenkins won't recognize items in the build/ directory above to archive as artifacts.
How can I make this kind of build system work with Hudson? Building in-source-tree is not a short-term option. The only option I found was "use custom workspace," but all this does it hard-code the workspace directory to some other directory.
To answer my own question: there is indeed an option in Jenkins git plugin to check out to a local subdirectory instead of the root of the workspace. With the git plugin, click on the Advanced button and fill in the field "Local subdirectory for repo (optional)".
I don't find the option that djs mentioned, but you can specify a different work directory:
Configure job
Extended Project settings
Use custom work space
This can be set to everywhere you want, also the workspace of a different job.