The default profile we have is just so that a developer doesn't have to
provide the release version when invoking maven on the command line. I
didn't want to require more typing :)
> Taken that you can inject special project.version via -D but what about
> having other dependent modules using that special version as well? You'd
> still need to have them controlled by injecting special property.
I'm not sure what you are asking. Are you referring to submodules within
one project? If so, your module POMs would also use the property. For
example, our module POMs have:
<parent>
<version>${releaseVersion}</version>
...
</parent>
...
<version>${releaseVersion}</version>
...
> In this scenario, apart from the pom.xml growing bigger, do you foresee
> any distinct disadvantage opting for the profile path (instead of
> property injection)?
I think of profiles as way to adjust the build according to the environment
in which the build is occurring (in my case developer's machine versus
hudson CI) rather than for per-version/per-branch adjustment. But, I don't
see any disadvantages for using a profile other than release version seems
to be one good candidate for singling out. At utipu, passing a
releaseVersion property to maven means we can quickly/easily make new
branches that are ready for CI. It also helps in cutting releases, because
we don't have to make any commits to repository to change a release version
from 1.0-SNAPSHOT to 1.0.
I stated in my first response that this approach may or may not be
appropriate for a framework for two reasons: (1) If you are building the
framework from source and using the result in other projects locally, you
might have to specify the version in the maven command line when building
the framework (this really depends on what value you use for the
releaseVersion in the default profile); and (2) I haven't seen anybody else
do it this way.
On Mon, Sep 21, 2009 at 10:10 AM, Indrajit Raychaudhuri <indraj...@gmail.com
> wrote:
>
> Ryan,
>
> Your comment:
> > (we just use "dev" so local developers' .war files are built as
> "utipu-dev.war")
> made me perceive that you go for manual build for dev. But, yes, point
> accepted.
>
> Taken that you can inject special project.version via -D but what about
> having other dependent modules using that special version as well? You'd
> still need to have them controlled by injecting special property.
>
> In this scenario, apart from the pom.xml growing bigger, do you foresee
> any distinct disadvantage opting for the profile path (instead of
> property injection)?
>
> Cheers, Indrajit
>
> On 21/09/09 7:18 PM, Ryan Donahue wrote:
> > In fact it works for multiple Hudson builds. We have serveral hudson
> > builds running concurrently: one for the currently released version, one
> > for the trunk, and others for customer-specific builds. Only one maven
> > profile is needed for the Hudson builds because these builds pass the
> > version in to maven.
> >
> >
> > On Mon, Sep 21, 2009 at 9:42 AM, Indrajit Raychaudhuri
> > <indraj...@gmail.com <mailto:indraj...@gmail.com>> wrote:
> >
> >
> > Ryan,
> >
> > Nice workflow! But I guess this works better when one is a Hudson
> build
> > and the other a manual build. What David was looking for is involves
> two
> > Hudson builds.
> >
> > Do you think this would serve the purpose using Maven profile (mvn -P
> > instead of mvn -D)?
> >
> http://github.com/dpp/liftweb/commit/45dc2e55bd37104aa2a56990914b38a1895b18f6
> >
> >
> > Cheers, Indrajit
> >
> >
> > On 21/09/09 6:28 PM, Ryan Donahue wrote:
> > >
> > > We pass the release version into maven from hudson.
> > >
> > > In the POM:
> > > <version>${releaseVersion}</version>
> > >
> > > In the hudson build's maven goals and options field:
> > > -DreleaseVersion=1.1-SNAPSHOT
> > >
> > > Actually, we go a little further by creating a hudson build
> property
> > > called releaseVersion. Then the maven options include:
> > > -DreleaseVersion=${releaseVersion}.
> > > This results in a prompt whenever you do a manual build, allowing
> you
> > > to change the releaseVersion property (good for release builds).
> > >
> > > If you go this route, you'll want to have at least 2 profiles in
> the
> > > POM, one for hudson builds invoked when the releaseVersion
> > property is
> > > present and a default profile for developers that sets the
> > > releaseVersion property to some default (we just use "dev" so
> local
> > > developers' .war files are built as "utipu-dev.war"). We use this
> > > strategy for utipu.com <http://utipu.com> (not a lift app) as
> > well as for our internal
> > > lift apps. It works well for us, but may or may not be
> appropriate
> > > for a framework build.
> > >
> > >
> > >
> > > On Sep 18, 7:38 pm, David Pollak<feeder.of.the.be...@gmail.com
> > <mailto:feeder.of.the.be...@gmail.com>>
> > > wrote:
> > >> Folks,
> > >> Is there a clean and easy way that anyone knows of to have Hudson
> do
> > >> alternate builds from different Git branches and put them in
> > SNAPSHOTS with
> > >> different versions (e.g., 1.1-SNAPSHOT_DPP_ACTOR)?
> > >>
> > >> I am making some wholesale changes to Lift's use of Actors
> > (basically
> > >> getting rid of all Scala Actors and creating some simple traits
> > that Akka or
> > >> other systems can implement so that Lift-based systems can
> > choose different
> > >> Actor implementations.
> > >>
> > >> Given that these changes are non-trivial, I'd like to run a
> > parallel version
> > >> of Lift for at least a few weeks and get feedback on the API
> > changes and
> > >> performance before committing the code to the main branch, but I
> > want the
> > >> code to available in Hudson.
> > >>
> > >> So... any ideas?
> > >>
> > >> Thanks,
> > >>
> > >> David
> > >>
> > >> --
> > >> Lift, the simply functional web frameworkhttp://liftweb.net
> > <http://liftweb.net>
> > >> Beginning Scalahttp://www.apress.com/book/view/1430219890
> > <http://www.apress.com/book/view/1430219890>
> > >> Follow me:http://twitter.com/dpp
> > >> Git some:http://github.com/dpp
> > > >
> >
> >
> >
> >
> > >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
