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
> <[email protected] <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<[email protected] <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<
> [email protected] <javascript:;>>
> >>>> For additional commands, e-mail:
> >>>> [email protected]<javascript:;>
> >>>>
> >>>>
> >>>>
> >>> --
> >>> Ron Wheeler
> >>> President
> >>> Artifact Software Inc
> >>> email: [email protected] <javascript:;>
> >>> skype: ronaldmwheeler
> >>> phone: 866-970-2435, ext 102
> >>>
> >>>
> >>> ------------------------------**------------------------------**
> >>> ---------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> [email protected] <javascript:;>>
> >>> For additional commands, e-mail: [email protected]<javascript:;>
> >>>
> >>>
> >>
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: [email protected] <javascript:;>
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
>
