Maven profiles & the experimental m2 project support

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven profiles & the experimental m2 project support

Rhett Sutphin
Hi,

I first tried Hudson out a for the first time a couple of hours ago  
and I've already got a small (3 module) maven project building with  
the native m2 project support.  Thanks for creating such an  
immediately-useful, self-documenting tool.

I'm now trying to get a somewhat more complex multimodule project  
building.  The snag I'm running into is that one of the modules needs  
to have a profile selected.  The profiles are defined in Maven's  
standard profiles.xml in the same directory as the module's pom.  For  
the record, I'm trying this list of goals:

clean bering:hsqldb deploy -P hsqldb

The build runs fine up to the tests, which fail because some  
properties (set in the profile) are not filtered into a necessary  
resource.  I've seen other reports of similar problems ( e.g.,  
https://hudson.dev.java.net/issues/show_bug.cgi?id=312 ), so I  
understand that this isn't working yet in the embedded maven system.

I was wondering if it might be possible to split up the functionality  
of the experimental maven project support so that it would still be  
responsible for automatically creating all the modules & inter-module  
dependencies, and letting you use a single checkout workspace, etc.,  
but an individual module could be configured to build using an  
external maven installation (a la the freestyle build option).  Not  
knowing about the internals of maven or hudson, I'm not sure if this  
would actually be easier than adding full profile support to the  
embedded instance, but I thought I'd bring it up in case it hadn't  
been considered.

Thanks again,
Rhett Sutphin
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven profiles & the experimental m2 project support

Kohsuke Kawaguchi-2
Rhett Sutphin wrote:
> Hi,
>
> I first tried Hudson out a for the first time a couple of hours ago  
> and I've already got a small (3 module) maven project building with  
> the native m2 project support.  Thanks for creating such an  
> immediately-useful, self-documenting tool.

Thanks. Just be warned that the native m2 support is still very much a
work in progress (hence 'alpha'.) For that reason I appreciate that you
are trying it.

The free-style project can also build maven project just fine, just so
you know.

> I'm now trying to get a somewhat more complex multimodule project  
> building.  The snag I'm running into is that one of the modules needs  
> to have a profile selected.  The profiles are defined in Maven's  
> standard profiles.xml in the same directory as the module's pom.  For  
> the record, I'm trying this list of goals:
>
> clean bering:hsqldb deploy -P hsqldb
>
> The build runs fine up to the tests, which fail because some  
> properties (set in the profile) are not filtered into a necessary  
> resource.  I've seen other reports of similar problems ( e.g.,  
> https://hudson.dev.java.net/issues/show_bug.cgi?id=312 ), so I  
> understand that this isn't working yet in the embedded maven system.
In the upcoming 1.85 release, I changed the way Maven is launched, so
all the command line options of Maven should work, including profiles.

In 1.84 all the tokens are interpreted as goals and phases. You simply
didn't get the error because the build failed trying to achieve the
"deploy" phase, so it hasn't tried to parse "-P" as a goal or phase
name. So you are right that this is the same problem as issue #312.

I recommend trying 1.85 when it's released. I plan to do so tonight or
tomorrow.

> I was wondering if it might be possible to split up the functionality  
> of the experimental maven project support so that it would still be  
> responsible for automatically creating all the modules & inter-module  
> dependencies, and letting you use a single checkout workspace, etc.,  
> but an individual module could be configured to build using an  
> external maven installation (a la the freestyle build option).  Not  
> knowing about the internals of maven or hudson, I'm not sure if this  
> would actually be easier than adding full profile support to the  
> embedded instance, but I thought I'd bring it up in case it hadn't  
> been considered.
I think the changes in 1.85 is in this direction. I stopped using
embedder and launching Maven as a separate process, in a way very close
to how mvn CLI does (except that I put hooks so that hudson can inject
its own code to monitor the execution.)

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Maven profiles & the experimental m2 project support

Rhett Sutphin
Hi,

> The free-style project can also build maven project just fine, just  
> so you know.

Right -- I tried that out.  It's just that the automatic build  
dependency detection in the native m2 module is so cool.

> In the upcoming 1.85 release, I changed the way Maven is launched,  
> so all the command line options of Maven should work, including  
> profiles.

That's excellent news.  I just tried the 1.85 nightly and that  
problematic module deployed fine.

Thanks again, again,
Rhett

On Mar 5, 2007, at 6:09 PM, Kohsuke Kawaguchi wrote:

> Rhett Sutphin wrote:
>> Hi,
>> I first tried Hudson out a for the first time a couple of hours  
>> ago  and I've already got a small (3 module) maven project  
>> building with  the native m2 project support.  Thanks for creating  
>> such an  immediately-useful, self-documenting tool.
>
> Thanks. Just be warned that the native m2 support is still very  
> much a work in progress (hence 'alpha'.) For that reason I  
> appreciate that you are trying it.
>
> The free-style project can also build maven project just fine, just  
> so you know.
>
>> I'm now trying to get a somewhat more complex multimodule project  
>> building.  The snag I'm running into is that one of the modules  
>> needs  to have a profile selected.  The profiles are defined in  
>> Maven's  standard profiles.xml in the same directory as the  
>> module's pom.  For  the record, I'm trying this list of goals:
>> clean bering:hsqldb deploy -P hsqldb
>> The build runs fine up to the tests, which fail because some  
>> properties (set in the profile) are not filtered into a necessary  
>> resource.  I've seen other reports of similar problems ( e.g.,  
>> https://hudson.dev.java.net/issues/show_bug.cgi?id=312 ), so I  
>> understand that this isn't working yet in the embedded maven system.
>
> In the upcoming 1.85 release, I changed the way Maven is launched,  
> so all the command line options of Maven should work, including  
> profiles.
>
> In 1.84 all the tokens are interpreted as goals and phases. You  
> simply didn't get the error because the build failed trying to  
> achieve the "deploy" phase, so it hasn't tried to parse "-P" as a  
> goal or phase name. So you are right that this is the same problem  
> as issue #312.
>
> I recommend trying 1.85 when it's released. I plan to do so tonight  
> or tomorrow.
>
>> I was wondering if it might be possible to split up the  
>> functionality  of the experimental maven project support so that  
>> it would still be  responsible for automatically creating all the  
>> modules & inter-module  dependencies, and letting you use a single  
>> checkout workspace, etc.,  but an individual module could be  
>> configured to build using an  external maven installation (a la  
>> the freestyle build option).  Not  knowing about the internals of  
>> maven or hudson, I'm not sure if this  would actually be easier  
>> than adding full profile support to the  embedded instance, but I  
>> thought I'd bring it up in case it hadn't  been considered.
>
> I think the changes in 1.85 is in this direction. I stopped using  
> embedder and launching Maven as a separate process, in a way very  
> close to how mvn CLI does (except that I put hooks so that hudson  
> can inject its own code to monitor the execution.)
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven profiles & the experimental m2 project support

Kohsuke Kawaguchi-2
Rhett Sutphin wrote:
> Hi,
>
>> The free-style project can also build maven project just fine, just  
>> so you know.
>
> Right -- I tried that out.  It's just that the automatic build  
> dependency detection in the native m2 module is so cool.

Yes.

>> In the upcoming 1.85 release, I changed the way Maven is launched,  
>> so all the command line options of Maven should work, including  
>> profiles.
>
> That's excellent news.  I just tried the 1.85 nightly and that  
> problematic module deployed fine.

Cool. Thank you for a quick turn around. Sounds like 1.85 is ready to be
released.

Let me know if you experience other problems.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Maven profiles & the experimental m2 project support

Rhett Sutphin
> Let me know if you experience other problems.

Since you mention it ... there are a couple of things that don't work  
in the m2 native build that are keeping me from using it as the only  
build for my projects.  Some or all of these may be things you  
already know about (since it's an alpha), but just in case:

- E-mail notifications.  I'm not getting e-mail notifications for  
failed module builds, either through "notify the individual  
responsible" or through the blanket address list.  E-mail from  
freestyle builds does work, so I don't think it's my local  
configuration.
- Test results.  It looks like the test results for a module are only  
published when the build succeeds.  This means I have to go into the  
workspace and read the surefire reports to find out why the tests  
failed.

Something else which is bugging me but which appears to be the same  
between freestyle and m2 builds is this:  after a build fails, it  
doesn't get rebuilt until I manually request it or there's another  
commit.  The documentation and some configuration settings suggest  
that this shouldn't be the case -- that it should keep building (&  
sending e-mails) until the problem is fixed.  Am I misreading the  
docs?  Or is there a configuration option to enable to get this feature?

For reference, I'm using a nightly with this version string: "Hudson  
ver. 1.85-SNAPSHOT (private-03/04/2007 09:41-hudson)".

Thanks,
Rhett


On Mar 5, 2007, at 6:39 PM, Kohsuke Kawaguchi wrote:

> Rhett Sutphin wrote:
>> Hi,
>>> The free-style project can also build maven project just fine,  
>>> just  so you know.
>> Right -- I tried that out.  It's just that the automatic build  
>> dependency detection in the native m2 module is so cool.
>
> Yes.
>
>>> In the upcoming 1.85 release, I changed the way Maven is  
>>> launched,  so all the command line options of Maven should work,  
>>> including  profiles.
>> That's excellent news.  I just tried the 1.85 nightly and that  
>> problematic module deployed fine.
>
> Cool. Thank you for a quick turn around. Sounds like 1.85 is ready  
> to be released.
>
> Let me know if you experience other problems.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven profiles & the experimental m2 project support

Kohsuke Kawaguchi-2
Rhett Sutphin wrote:

>> Let me know if you experience other problems.
>
> Since you mention it ... there are a couple of things that don't work  
> in the m2 native build that are keeping me from using it as the only  
> build for my projects.  Some or all of these may be things you  
> already know about (since it's an alpha), but just in case:
>
> - E-mail notifications.  I'm not getting e-mail notifications for  
> failed module builds, either through "notify the individual  
> responsible" or through the blanket address list.  E-mail from  
> freestyle builds does work, so I don't think it's my local  
> configuration.
OK. I'll take a look.

> - Test results.  It looks like the test results for a module are only  
> published when the build succeeds.  This means I have to go into the  
> workspace and read the surefire reports to find out why the tests  
> failed.

I need to tell Maven not to fail if some tests fail, so that I can make
the build yellow.


> Something else which is bugging me but which appears to be the same  
> between freestyle and m2 builds is this:  after a build fails, it  
> doesn't get rebuilt until I manually request it or there's another  
> commit.  The documentation and some configuration settings suggest  
> that this shouldn't be the case -- that it should keep building (&  
> sending e-mails) until the problem is fixed.  Am I misreading the  
> docs?  Or is there a configuration option to enable to get this feature?

The behavior you are observing is the programmed behavior.

I'm curious. What's the point of keep rebuilding? Unless there's some
change, it's not going to suddenly work, right?

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Maven profiles & the experimental m2 project support

Rhett Sutphin
Hi,

Thanks for your replies.

> The behavior you are observing is the programmed behavior.

Okay.  The thing that made me think it was going to keep building was  
the "don't send e-mail for every unstable build" option, but in  
retrospect that fits with the actual behavior, too.

> I'm curious. What's the point of keep rebuilding? Unless there's  
> some change, it's not going to suddenly work, right?

Some of my builds depend on external resources being available --  
database servers, etc.  With my CruiseControl builds, I always set  
them to keep building so that if one of these external resources was  
unavailable at build time, CC would automatically rebuild, eventually  
getting a valid result when the resource became available.

This is less important with hudson (and, actually, recent versions of  
CC) because you can kick off a build manually.  It would be easy to  
restore the missing resource and then request a build.

Thanks,
Rhett

On Mar 6, 2007, at 8:16 PM, Kohsuke Kawaguchi wrote:

> Rhett Sutphin wrote:
>>> Let me know if you experience other problems.
>> Since you mention it ... there are a couple of things that don't  
>> work  in the m2 native build that are keeping me from using it as  
>> the only  build for my projects.  Some or all of these may be  
>> things you  already know about (since it's an alpha), but just in  
>> case:
>> - E-mail notifications.  I'm not getting e-mail notifications for  
>> failed module builds, either through "notify the individual  
>> responsible" or through the blanket address list.  E-mail from  
>> freestyle builds does work, so I don't think it's my local  
>> configuration.
>
> OK. I'll take a look.
>
>> - Test results.  It looks like the test results for a module are  
>> only  published when the build succeeds.  This means I have to go  
>> into the  workspace and read the surefire reports to find out why  
>> the tests  failed.
>
> I need to tell Maven not to fail if some tests fail, so that I can  
> make the build yellow.
>
>
>> Something else which is bugging me but which appears to be the  
>> same  between freestyle and m2 builds is this:  after a build  
>> fails, it  doesn't get rebuilt until I manually request it or  
>> there's another  commit.  The documentation and some configuration  
>> settings suggest  that this shouldn't be the case -- that it  
>> should keep building (&  sending e-mails) until the problem is  
>> fixed.  Am I misreading the  docs?  Or is there a configuration  
>> option to enable to get this feature?
>
> The behavior you are observing is the programmed behavior.
>
> I'm curious. What's the point of keep rebuilding? Unless there's  
> some change, it's not going to suddenly work, right?
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven profiles & the experimental m2 project support

Kohsuke Kawaguchi-2
Rhett Sutphin wrote:

> Hi,
>
> Thanks for your replies.
>
>> The behavior you are observing is the programmed behavior.
>
> Okay.  The thing that made me think it was going to keep building was  
> the "don't send e-mail for every unstable build" option, but in  
> retrospect that fits with the actual behavior, too.
>
>> I'm curious. What's the point of keep rebuilding? Unless there's  
>> some change, it's not going to suddenly work, right?
>
> Some of my builds depend on external resources being available --  
> database servers, etc.  With my CruiseControl builds, I always set  
> them to keep building so that if one of these external resources was  
> unavailable at build time, CC would automatically rebuild, eventually  
> getting a valid result when the resource became available.
>
> This is less important with hudson (and, actually, recent versions of  
> CC) because you can kick off a build manually.  It would be easy to  
> restore the missing resource and then request a build.
I see. In my production system, builds tend to break because someone
forgot to commit one of their changes. And often that is the last commit
that person made before he headed home.

So if Hudson keeps rebuilding, it'll just try all night to no avail.

If anything, it might be worthwhile to write a plugin that retries a few
times after a failed build. That sounds like useful.

Would you be interested in writing it :-) :-)

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment