Looks reasonable as a structure and process.
When we start a branch, we just fix up the parent POM and any other POM
that needs it, to have the right version and build normally.
We also don't change the versions of things unless the thing changes.
It appears that you are trying to avoid using multiple parent POMs to
control the version.
I do not use profiles so perhaps someone else might be better able to
advise you.
You might want to elaborate how -Dbranch=<branch> does not work. That might
give someone a hint about how to fix this or how to inject a different process into
your build.
Ron
No need to copy me separately, I read the list.
On 01/08/2012 6:50 PM, Jeff Sawatzky wrote:
Ron, thanks for the reply. However, I've read the links you provided and I'm not sure if they help.
Also, when I said "and C and something that uses the data store" I meant "and C IS
something that uses the data store". So I only have three projects, A,B, and C. Not sure if
that changes your response any. I will try to re-word my question to see if it helps at all...
We have different branches, one for each step in our release cycle:
- "Feature Branch": this branch is the branch where the developer works on the
actual feature, and it is branched off of the last release branch.
- dev: this branch is the "continuous integration branch" that the feature
branch gets merged into once the feature is complete. If any issues are found, the
feature will be reopened and sent back to the developer to fix in the feature branch.
- qa: this is the "test" branch that the feature branch will get merged into
once all kinks have been worked out in the dev branch. If any issues are found, the
feature will be reopened and sent back to the developer to fix in the feature branch.
- staging: this is the "staging" branch that the feature branch will get merged
into once all kinks have been worked out in the qa branch. By now all kinks should have
been worked out and this is just a safety check before sending out to production, but if
any issues are found then it is reopened and sent back to the developer to fix in the
feature branch.
- demo: this is outside of the normal release cycle and is where we merge
features that the CEO wants to demo before they are fully ready
We have a different environment for each branch. I want to be able to deploy
specific builds of each branch to the environment automatically. I am trying to
get something working where the dependencies for each branch look like:
dev: A-1.0-dev-SNAPSHOT <-- B-1.0-dev-SNAPSHOT <-- C-1.0-dev-SNAPSHOT
qa: A-1.0-qa-SNAPSHOT <-- B-1.0-qa-SNAPSHOT <-- C-1.0-qa-SNAPSHOT
demo: A-1.0-demo-SNAPSHOT <-- B-1.0-demo-SNAPSHOT <-- C-1.0-demo-SNAPSHOT
staging: A-1.0.1.1 <-- B-1.0.1.1<-- C-1.0.1.1
I am currently trying to accomplish this by passing a -Dbranch=<branch> and
then have profiles for each branch (activated by the branch property) which specify
the version to use. This doesn't seem to be working the way I want though, and was
wondering if I am going about this the wrong way, and if so, what is the correct way?
Thanks again,
Jeff.
On 2012-07-20, at 11:54 AM, Ron Wheeler <[email protected]> wrote:
Everybody has this problem, once they get to the first release of their
application.
You can find lots of discussions about this in the forum archives.
Google is your friend as well.
Profiles are not the way to handle this.
Separate the code from environment.
Make A, B C and "something that uses the data store" without environment stuff.
Make a separate project for Dev that contains the Dev environment configuration and
depends on "something that uses the data store".jar that includes A, B and C.
Same for the rest(test, production, etc.)
These will have no code and just configuration files.
Use JNDI or some other method of communicating environment variables.
http://blog.artifact-software.com/tech/?p=150
http://blog.artifact-software.com/tech/?p=58
Ron
On 20/07/2012 11:08 AM, Jeff Sawatzky wrote:
I have multiple projects, lets call them A, B, and C. A is a util project, B is
the data store layer, and C and something that uses the data store. So, A
depends on nothing, B depends on A, and C depends on B. I am also trying to
create multiple builds for different environments, dev, test, production, and
have created related profiles in each project for each build and specify the
dependencies in those profiles. For instance, B-dev-SNAPSHOP depends on
A-dev-SNAPSHOT, and C-dev-SNAPSHOT depends on B-dev-SNAPSHOT. And I specify the
environment through a system property.
The problem I am running into is that when I build C, it includes the dev
profile and adds B-dev-SNAPSHOT as a dependency, but the environment system
property doesn't seem to get passed to the pom of B-dev-SNAPSHOT and therefore
the A-dev-SNAPSHOT dependency isn't included.
Am I going about this the wrong way?
Thanks,
Jeff.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
