[Lift] Re: Alternate Lift builds?
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 Pollakfeeder.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
-~--~~~~--~~--~--~---
[Lift] Re: Alternate Lift builds?
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 Pollakfeeder.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
[Lift] Re: Alternate Lift builds?
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.
Why would we want this indirection then?
- The property can hold a string or numeric value that can be used
elsewhere, such as release versions.
- properties can be given default values if not expressly provided
- Properties can be provided by other mechanisms, not just command-line
arguments
- A single profile can be enabled by multiple properties
- Multiple profiles can be enabled from a single property
On Mon, Sep 21, 2009 at 3:59 PM, Ryan Donahue donahu...@gmail.com wrote:
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
[Lift] Re: Alternate Lift builds?
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 one. Also, do you have rights on Hudson/Nexus on scala-tools.org http://scala-tools.org? If not, please send mail to ad...@scala-tools.org mailto:ad...@scala-tools.org I don't. Have sent mail. On Sat, Sep 19, 2009 at 12:58 PM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.com wrote: 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 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: http://maven.apache.org/guides/introduction/introduction-to-profiles.html It doesn't make a great deal of difference at this level, but I've found it can really make things a lot more flexible if you want to start mixing in configurations based on architecture or JVM version, or if you're working with multi-module builds. http://maven.apache.org/guides/introduction/introduction-to-profiles.html On Sat, Sep 19, 2009 at 6:28 PM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.com mailto:indraj...@gmail.com mailto:indraj...@gmail.com wrote: 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 activeByDefaultfalse/activeByDefault /activation dependencies dependency groupIdnet.liftweb/groupId artifactIdlift-actor/artifactId version1.1-SNAPSHOT/version classifierdpp/classifier /dependency /dependencies /profile /profiles See http://maven.apache.org/pom.html#Profiles for more. Now if you invoke mvn -Pdppactor compile, the dependency would be on lift-actor-1.1-SNAPSHOT-dpp.jar! To create lift-actor-1.1-SNAPSHOT-dpp.jar, you can follow the same technique (another profile). Just use the optional config parameter 'classifier' See: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#classifier Now Hudson build would just need the extra param (-P) to do the needful. Hope this helps. Cheers, Indrajit On Sep 19, 4:38 am, David Pollak feeder.of.the.be...@gmail.com mailto:feeder.of.the.be...@gmail.com mailto: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 http://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 http://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 -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some:
[Lift] Re: Alternate Lift builds?
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 automate on this one :( Thanks! On Sat, Sep 19, 2009 at 12:38 AM, David Pollak 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 framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala 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 -~--~~~~--~~--~--~---
[Lift] Re: Alternate Lift builds?
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 activeByDefaultfalse/activeByDefault /activation dependencies dependency groupIdnet.liftweb/groupId artifactIdlift-actor/artifactId version1.1-SNAPSHOT/version classifierdpp/classifier /dependency /dependencies /profile /profiles See http://maven.apache.org/pom.html#Profiles for more. Now if you invoke mvn -Pdppactor compile, the dependency would be on lift-actor-1.1-SNAPSHOT-dpp.jar! To create lift-actor-1.1-SNAPSHOT-dpp.jar, you can follow the same technique (another profile). Just use the optional config parameter 'classifier' See: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#classifier Now Hudson build would just need the extra param (-P) to do the needful. Hope this helps. Cheers, Indrajit On Sep 19, 4:38 am, David Pollak 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 Beginning Scalahttp://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 -~--~~~~--~~--~--~---
[Lift] Re: Alternate Lift builds?
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: http://maven.apache.org/guides/introduction/introduction-to-profiles.html It doesn't make a great deal of difference at this level, but I've found it can really make things a lot more flexible if you want to start mixing in configurations based on architecture or JVM version, or if you're working with multi-module builds. http://maven.apache.org/guides/introduction/introduction-to-profiles.html On Sat, Sep 19, 2009 at 6:28 PM, Indrajit Raychaudhuri indraj...@gmail.comwrote: 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 activeByDefaultfalse/activeByDefault /activation dependencies dependency groupIdnet.liftweb/groupId artifactIdlift-actor/artifactId version1.1-SNAPSHOT/version classifierdpp/classifier /dependency /dependencies /profile /profiles See http://maven.apache.org/pom.html#Profiles for more. Now if you invoke mvn -Pdppactor compile, the dependency would be on lift-actor-1.1-SNAPSHOT-dpp.jar! To create lift-actor-1.1-SNAPSHOT-dpp.jar, you can follow the same technique (another profile). Just use the optional config parameter 'classifier' See: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#classifier Now Hudson build would just need the extra param (-P) to do the needful. Hope this helps. Cheers, Indrajit On Sep 19, 4:38 am, David Pollak 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 Beginning Scalahttp://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 -~--~~~~--~~--~--~---
[Lift] Re: Alternate Lift builds?
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 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: http://maven.apache.org/guides/introduction/introduction-to-profiles.html It doesn't make a great deal of difference at this level, but I've found it can really make things a lot more flexible if you want to start mixing in configurations based on architecture or JVM version, or if you're working with multi-module builds. http://maven.apache.org/guides/introduction/introduction-to-profiles.html On Sat, Sep 19, 2009 at 6:28 PM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.com wrote: 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 activeByDefaultfalse/activeByDefault /activation dependencies dependency groupIdnet.liftweb/groupId artifactIdlift-actor/artifactId version1.1-SNAPSHOT/version classifierdpp/classifier /dependency /dependencies /profile /profiles See http://maven.apache.org/pom.html#Profiles for more. Now if you invoke mvn -Pdppactor compile, the dependency would be on lift-actor-1.1-SNAPSHOT-dpp.jar! To create lift-actor-1.1-SNAPSHOT-dpp.jar, you can follow the same technique (another profile). Just use the optional config parameter 'classifier' See: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#classifier Now Hudson build would just need the extra param (-P) to do the needful. Hope this helps. Cheers, Indrajit On Sep 19, 4:38 am, 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 -~--~~~~--~~--~--~---
[Lift] Re: Alternate Lift builds?
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 wrote: 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 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: http://maven.apache.org/guides/introduction/introduction-to-profiles.html It doesn't make a great deal of difference at this level, but I've found it can really make things a lot more flexible if you want to start mixing in configurations based on architecture or JVM version, or if you're working with multi-module builds. http://maven.apache.org/guides/introduction/introduction-to-profiles.html On Sat, Sep 19, 2009 at 6:28 PM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.com wrote: 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 activeByDefaultfalse/activeByDefault /activation dependencies dependency groupIdnet.liftweb/groupId artifactIdlift-actor/artifactId version1.1-SNAPSHOT/version classifierdpp/classifier /dependency /dependencies /profile /profiles See http://maven.apache.org/pom.html#Profiles for more. Now if you invoke mvn -Pdppactor compile, the dependency would be on lift-actor-1.1-SNAPSHOT-dpp.jar! To create lift-actor-1.1-SNAPSHOT-dpp.jar, you can follow the same technique (another profile). Just use the optional config parameter 'classifier' See: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#classifier Now Hudson build would just need the extra param (-P) to do the needful. Hope this helps. Cheers, Indrajit On Sep 19, 4:38 am, 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 -- Lift, the simply functional web framework http://liftweb.net Beginning Scala 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 -~--~~~~--~~--~--~---
[Lift] Re: Alternate Lift builds?
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 version to our version. I personally don't like classifiers as you'd have to make all your nested dependencies also use the same classifier to really test the system. - Josh On Sat, Sep 19, 2009 at 3:49 PM, Kevin Wright kev.lee.wri...@googlemail.com wrote: 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: http://maven.apache.org/guides/introduction/introduction-to-profiles.html It doesn't make a great deal of difference at this level, but I've found it can really make things a lot more flexible if you want to start mixing in configurations based on architecture or JVM version, or if you're working with multi-module builds. http://maven.apache.org/guides/introduction/introduction-to-profiles.html On Sat, Sep 19, 2009 at 6:28 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: 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 activeByDefaultfalse/activeByDefault /activation dependencies dependency groupIdnet.liftweb/groupId artifactIdlift-actor/artifactId version1.1-SNAPSHOT/version classifierdpp/classifier /dependency /dependencies /profile /profiles See http://maven.apache.org/pom.html#Profiles for more. Now if you invoke mvn -Pdppactor compile, the dependency would be on lift-actor-1.1-SNAPSHOT-dpp.jar! To create lift-actor-1.1-SNAPSHOT-dpp.jar, you can follow the same technique (another profile). Just use the optional config parameter 'classifier' See: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#classifier Now Hudson build would just need the extra param (-P) to do the needful. Hope this helps. Cheers, Indrajit On Sep 19, 4:38 am, David Pollak 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 Beginning Scalahttp://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 -~--~~~~--~~--~--~---
[Lift] Re: Alternate Lift builds?
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 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 framework http://liftweb.net Beginning Scala 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 -~--~~~~--~~--~--~---
