Maven profiles & the experimental m2 project support
Locked
 
|
|
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. 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. 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) |
|
|
|
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] |
|
|
|
|
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. > - 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] |
|
|
|
|
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. 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] |
Loading...
| Powered by Nabble | See how NAML generates this page |
