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
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
properties and profiles aren't mutually exclusive.
In a typical workflow, the property will just be another level of
indirection:
developer sets property which sets profile
instead of:
developer sets profile
So profiles are still the underlying mechanism for configuring units of
behaviour.
On 20/09/09 4:46 AM, David Pollak wrote:
Care to take a look at the pom.xml files in the dpp_wip_actorized branch
and make them to the right thing?
Done:
http://github.com/dpp/liftweb/commit/45dc2e55bd37104aa2a56990914b38a1895b18f6
But the tests don't pass in lift-util hope that's a known
On Fri, Sep 18, 2009 at 4:44 PM, Kevin Wright kev.lee.wri...@googlemail.com
wrote:
Your best bet is probably:
Modifiy the pom in the branch, e.g. by adding a qualifier to the version
infoManually configure a second build in hudson that points to the branch
I'm pretty sure you can't
Dependency classifier might be close to what you'd need.
See the 'Classifier' section in http://maven.apache.org/pom.html#Dependencies
So, you could create a build profile (disabled by default), say
dppactor as so:
profiles
profile
iddppactor/id
activation
Quite right, it's classifier and not qualifier. It was a typo, honest!
:-p
Nice thinking about using profiles, lets you keep the pom in sync between
trunk and the branch, should help nicely with those merges One change I
would make though is to activate the profile by way of a property:
Acknowledged. Using property to activate profile allows greater
flexibility and would be preferred option indeed.
Cheers, Indrajit
On 20/09/09 1:19 AM, Kevin Wright wrote:
Quite right, it's classifier and not qualifier. It was a typo,
honest! :-p
Nice thinking about using profiles, lets
Care to take a look at the pom.xml files in the dpp_wip_actorized branch and
make them to the right thing?
Also, do you have rights on Hudson/Nexus on scala-tools.org? If not, please
send mail to ad...@scala-tools.org
On Sat, Sep 19, 2009 at 12:58 PM, Indrajit Raychaudhuri indraj...@gmail.com
Profiles are nice, but I think just using -P should be ok here (instead of
properties). Although I do like the properties approach, I usually use that
to simplify builds in the case where I have a system with a guaranteed
property. At work we usually use a profile to attach the hudosn build
Your best bet is probably:
Modifiy the pom in the branch, e.g. by adding a qualifier to the version
infoManually configure a second build in hudson that points to the branch
I'm pretty sure you can't automate on this one :(
On Sat, Sep 19, 2009 at 12:38 AM, David Pollak
11 matches
Mail list logo
