Hi Karl-Heinz,
in our specific case we build Magnolia modules
http://documentation.magnolia-cms.com/reference/module-mechanism.html#Moduleversionhandling
that have a module descriptor. The module descriptor contains a version
number for that module, which tells the system at runtime whether
Hi Stephen,
this could probably be handled by buildnumber-plugin using the SHA by
default, and only given some optional parameter it would prefix it with
the commit number?
Out of curiosity, how exactly is the branch shared among the team? Using
a shared filesystem? If everybody simply has
If you push the shared branch back to origin (yes bad practice I know... so
requires that everyone involved knows that the foo-feature branch will have
rewrites before merge back to master)
Ordinarily you would mandate that once a commit is pushed upstream it will
not be rewritten. But if you put
So I guess an optional parameter for buildnumber-plugin would be fine
then? By default people using your described workflow wouldn't see
problems, since they'd still use the SHA ony.
On 30.04.2013 10:44, Stephen Connolly wrote:
If you push the shared branch back to origin (yes bad practice I
Hi,
If in my pom I have this:
[..]
profile
idprofile1/id
activation
[..make sure this profile is active..]
/activation
properties
blah42/blah
/properties
/profile
profile
idprofile2/id
activation
[..make sure this profile is active..]
/activation
properties
I would like to be able to achieve the following using two command
line invocations:
- build and install jar files using mvn install
- run tests again, but against the installed jar files
The rationale is that the first mvn run will only run unit tests
(using test groups in TestNG), whereas the
Well just to put this into context.
What you actually want to do is run your second set of tests after the
'package' phase and before the 'install' phase. There is only the 'deploy'
phase after the 'install' phase so there would be no scope to run tests
after the 'install' phase.
If you look at
On 30 April 2013 12:28, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
What you actually want to do is run your second set of tests after the
'package' phase and before the 'install' phase. There is only the 'deploy'
phase after the 'install' phase so there would be no scope to run
Well how I normally do something like that is I put the failsafe execution
in a profile, which by convention is called `run-its`
So to build everything and install in the local repository cache:
mvn install
To build everything and install in the local repository cache with
integration tests
On 30 April 2013 13:20, Stephen Connolly stephen.alan.conno...@gmail.comwrote:
Well how I normally do something like that is I put the failsafe execution
in a profile, which by convention is called `run-its`
So to build everything and install in the local repository cache:
mvn install
To
Hi Jörg,
So I guess an optional parameter for buildnumber-plugin would be fine
then?
Adding an option (or better, populate a second Maven property) to
buildnumber-maven-plugin makes sense to me. It would be potentially useful,
not actively harmful, and based on what you said before, the work
Hi Curtis,
concerning the work being done already, there is a patch in
https://jira.codehaus.org/browse/MBUILDNUM-93 that by default uses the
commit number instead of the hash.
So the remaining work would be to append the short hash to the commit
number, and to make this behaviour optional.
Hi,
Actually it was Chris who helped me... Thanks Chris.
When I said NO access to RTC Build engine I meant for the physical server
where the build runs.
We have a support group that manages these servers which is why I don't have
the direct access.
(Yes that makes it more difficult to
[INFO] Executing: cmd.exe /X /C scm status --username srvrtcbuild --password
* --wide
[INFO] Working directory: D:\RTCBuildWorkspace\EI-Discovery2\EI AS-ITAM uCMDB
Pattern DEV
Again, you probably need to ensure that all directories involved in
the build do not have any spaces in the
If IBM were smart they would embrace Maven and do everything possible to
support it well within Jazz. Maven does not really compete with anything
IBM is doing, but it certainly compliments it in a positive way.
I have met a few people in IBM who are sympathetic to better support for
Maven, but I
Consider creating this directory D:\RTCBuildWorkspace\EI-Discovery2\EI
and sharing it, then try again to see if your error message changes. It
might help you to understand whether it's the directory name or the fact
that it's not shared, as the message says.
Shawn
Hi Wayne,
What I don't understand is that why would it work on my local laptop
with the same directory names? I realize the working directory on the RTC build
server uses the Component name (RTC term) which does have spaces in it.
BTW: Thanks everyone for prompt responses...
Robert
Hi all
Maybe somebody is interested in how a release could be built in a more
lightweight and safe way than with the maven-release-plugin. Especially
recommended for nightly releases.
It's not yet released, but basically fully working:
*mvn clean install -Dversion.override=1.2.3-S-5*
Hi all mates,
I am in a situation where I need to generate a POM and, in order to have
easily deployed/updated, I thought that having it attached in the project
would have simplified the build process.
The issue comes when external clients need to inherit from the generated
pom, because
What I don't understand is that why would it work on my local laptop
with the same directory names? I realize the working directory on the RTC
build server uses the Component name (RTC term) which does have spaces in it.
I couldn't even begin to guess. Clearly something is different
Hi Rotch
This sounds quite interesting and I feel it would be useful to a lot of
projects.
The release-plugin as it is, is not very flexible.
Questions
1. Why does the jar need to be part of maven installation? Why not a plugin?
2. Can it generate a version based on some strategy? Looks like
21 matches
Mail list logo
