You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jeff Sawatzky <je...@locationary.com> on 2012/07/20 17:08:14 UTC
multiple environment build and dependency management
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multiple environment build and dependency management
Posted by Jeff Sawatzky <je...@locationary.com>.
This is what I was thinking.
In my example, it appears when I try to build C-dev-SNAPSHOT by passing in -Dbranch=dev, C-dev-SNAPSHOT properly depends on B-dev-SNAPSHOT, but then B-dev-SNAPSHOT somehow doesn't get the branch and ends up using the default profile (activated when no branch is specified) and ends up depending on A-SNAPSHOT instead of A-dev-SNAPSHOT. Maybe I did something wrong, but I feel that the pom that is deployed should be the effective pom during the build and not the original so that it captures the exact state of all properties while building.
Jeff.
On 2012-08-02, at 10:25 AM, abhijith tn <ab...@gmail.com> wrote:
> Adding to this, There is a similar problem that I faced. Why does maven
> does not store the pom with replaced values for variables in the repository.
>
> To make it clear, Lets say, there is a variable which I would pass
> explicitly from the command line.
>
> mvn -e clean install -Dversion=1.0-SNAPSHOT and I would use this version
> variable as the version
>
> <version>${version}</version> in the pom. This gets stored in repository as
> ${version} itself. Shouldn't it be with the substituted value.
>
> On Thu, Aug 2, 2012 at 3:39 PM, Ron Wheeler
> <rw...@artifact-software.com>wrote:
>
>> 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 <rw...@artifact-software.com>>
>>> 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=150>
>>>>
>>>> http://blog.artifact-software.**com/tech/?p=58<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: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Ron Wheeler
>>>> President
>>>> Artifact Software Inc
>>>> email: rwheeler@artifact-software.com
>>>> skype: ronaldmwheeler
>>>> phone: 866-970-2435, ext 102
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multiple environment build and dependency management
Posted by Stephen Connolly <st...@gmail.com>.
One word: inheritance
If your parent has say foo.version=1.0 and declares multiple dependencies
with <version>${foo.version}</version> then when your Pom wants to bump to
1.1 you are forced to re-declare all inherited dependencies.
Now I am not saying that is best practice, but there are good people
relying on that.
Another example is distribution management, where the parent Pom defines
the URL via a property and the default value. At a later point in time you
need to roll a maintenance bug fix release, so bumping the parent is not an
option due to too much change, but your infra has since changed so by
specifying a property override in your settings.xml you get to keep going
All this causes problems, but fixing those causes others.
On Thursday, 2 August 2012, abhijith tn wrote:
> Adding to this, There is a similar problem that I faced. Why does maven
> does not store the pom with replaced values for variables in the
> repository.
>
> To make it clear, Lets say, there is a variable which I would pass
> explicitly from the command line.
>
> mvn -e clean install -Dversion=1.0-SNAPSHOT and I would use this version
> variable as the version
>
> <version>${version}</version> in the pom. This gets stored in repository as
> ${version} itself. Shouldn't it be with the substituted value.
>
> On Thu, Aug 2, 2012 at 3:39 PM, Ron Wheeler
> <rwheeler@artifact-software.com <javascript:;>>wrote:
>
> > 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 <rwheeler@artifact-software.
> **com<rwheeler@artifact-software.com <javascript:;>>>
> >> 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=150>
> >>>
> >>> http://blog.artifact-software.**com/tech/?p=58<
> 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: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org <javascript:;>>
> >>>> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
> >>>>
> >>>>
> >>>>
> >>> --
> >>> Ron Wheeler
> >>> President
> >>> Artifact Software Inc
> >>> email: rwheeler@artifact-software.com <javascript:;>
> >>> skype: ronaldmwheeler
> >>> phone: 866-970-2435, ext 102
> >>>
> >>>
> >>> ------------------------------**------------------------------**
> >>> ---------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org <javascript:;>>
> >>> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
> >>>
> >>>
> >>
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwheeler@artifact-software.com <javascript:;>
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
>
Re: multiple environment build and dependency management
Posted by abhijith tn <ab...@gmail.com>.
Adding to this, There is a similar problem that I faced. Why does maven
does not store the pom with replaced values for variables in the repository.
To make it clear, Lets say, there is a variable which I would pass
explicitly from the command line.
mvn -e clean install -Dversion=1.0-SNAPSHOT and I would use this version
variable as the version
<version>${version}</version> in the pom. This gets stored in repository as
${version} itself. Shouldn't it be with the substituted value.
On Thu, Aug 2, 2012 at 3:39 PM, Ron Wheeler
<rw...@artifact-software.com>wrote:
> 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 <rw...@artifact-software.com>>
>> 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=150>
>>>
>>> http://blog.artifact-software.**com/tech/?p=58<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: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Re: multiple environment build and dependency management
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 <rw...@artifact-software.com> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: multiple environment build and dependency management
Posted by Jeff Sawatzky <je...@locationary.com>.
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 <rw...@artifact-software.com> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: multiple environment build and dependency management
Posted by Ron Wheeler <rw...@artifact-software.com>.
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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multiple environment build and dependency management
Posted by Wayne Fay <wa...@gmail.com>.
> Yes, I am new to maven. Do you have any helpful suggestions as to how
> I can go about doing this without profiles?
What are problems you are currently using profiles (or attempting to)
to solve? More specifics in the problem description will generally
lead to better answers on this list.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multiple environment build and dependency management
Posted by Jeff Sawatzky <je...@locationary.com>.
Yes, I am new to maven. Do you have any helpful suggestions as to how I can go about doing this without profiles?
Regards,
Jeff.
On 2012-07-20, at 11:25 AM, Wayne Fay wrote:
>> 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?
>
> Sounds like you are a) new to Maven and b) trying to use profiles.
> This is a deadly combination.
>
> Find another solution to your problem that does NOT involve profiles.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multiple environment build and dependency management
Posted by Wayne Fay <wa...@gmail.com>.
> 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?
Sounds like you are a) new to Maven and b) trying to use profiles.
This is a deadly combination.
Find another solution to your problem that does NOT involve profiles.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org