[jira] Commented: (CONTINUUM-384) Build Error while queueing projects to be built
[ http://jira.codehaus.org/browse/CONTINUUM-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103581 ] Julien S commented on CONTINUUM-384: I seem to have the same issue with continuum 1.1-beta1 >From what I could observe, it seems that the build fails when an scm update is >being performed while the scheduler triggers a new build. > Build Error while queueing projects to be built > --- > > Key: CONTINUUM-384 > URL: http://jira.codehaus.org/browse/CONTINUUM-384 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.0 > Environment: Linux running JDK 1.5.0_01 >Reporter: Bob Allison > Fix For: Future > > Attachments: amm_continuum.log, wrapper.log > > > I get periodic deadlock exceptions from Derby while building projects. It > does not happen regularly, just occasionally. I have two projects (IDs 1 and > 7) which are on a schedule to run every 15 minutes, and I have had the > problem occur four times in the last 18 hours. I have a third project (ID 6) > which runs once each day; there was no problem at the time it was scheduled > to run. Attached is a file with snippets from wrapper.log which show the > entire log from the four runs of the schedule which had a failure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1384) Build error when enqueing happens during SCM update
Build error when enqueing happens during SCM update --- Key: CONTINUUM-1384 URL: http://jira.codehaus.org/browse/CONTINUUM-1384 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-1 Reporter: Julien S I've noticed on several occasions that a project is suddenly marked as "Error" without any change on the project itself. The error is displayed on the global summary and in the project group summary, but it does not appear on the builds page of the project. There is no error in the logs. As it happens quite often, I've finally noticed that the "trigger" to this issue seem to be the following: When a schedule runs to enqueue project while one of them is being updated from its SCM (even when there is no change), the project is then marked as error as described above. More specifically, it seems that the log pattern common to these build failure is: 377162928 [pool-1-thread-1] INFO org.apache.maven.scm.manager.ScmManager:default - Executing: /bin/bash -c "cd /drive/continuum-1.1-beta-1/work/55 && cvs -z3 -f -q update -d" 377162928 [pool-1-thread-1] INFO org.apache.maven.scm.manager.ScmManager:default - Working directory: /drive/continuum-1.1-beta-1/work/55 377163028 [defaultScheduler_Worker-1] INFO org.apache.maven.continuum.build.settings.SchedulesActivator:default - > Executing build job (DEFAULT_SCHEDULE)... 377163307 [pool-1-thread-1] INFO org.apache.maven.continuum.buildcontroller.BuildController:default - Merging SCM results -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1384) Build error when enqueing happens during SCM update
[ http://jira.codehaus.org/browse/CONTINUUM-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106271 ] Julien S commented on CONTINUUM-1384: - Indeed, I've been testing with beta-2 with a similar setup for a couple of days, and was about to comment that the issue seems to be fixed for us in beta-2 too. Thank you for the fix. > Build error when enqueing happens during SCM update > --- > > Key: CONTINUUM-1384 > URL: http://jira.codehaus.org/browse/CONTINUUM-1384 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-1 >Reporter: Julien S >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-3 > > > I've noticed on several occasions that a project is suddenly marked as > "Error" without any change on the project itself. > The error is displayed on the global summary and in the project group > summary, but it does not appear on the builds page of the project. > There is no error in the logs. > As it happens quite often, I've finally noticed that the "trigger" to this > issue seem to be the following: > When a schedule runs to enqueue project while one of them is being updated > from its SCM (even when there is no change), the project is then marked as > error as described above. > More specifically, it seems that the log pattern common to these build > failure is: > 377162928 [pool-1-thread-1] INFO > org.apache.maven.scm.manager.ScmManager:default - Executing: /bin/bash -c > "cd /drive/continuum-1.1-beta-1/work/55 && cvs -z3 -f -q update -d" > 377162928 [pool-1-thread-1] INFO > org.apache.maven.scm.manager.ScmManager:default - Working directory: > /drive/continuum-1.1-beta-1/work/55 > 377163028 [defaultScheduler_Worker-1] INFO > org.apache.maven.continuum.build.settings.SchedulesActivator:default - > > Executing build job (DEFAULT_SCHEDULE)... > 377163307 [pool-1-thread-1] INFO > org.apache.maven.continuum.buildcontroller.BuildController:default - Merging > SCM results -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1528) Continuum gets slower over time and eventually crashes
[ http://jira.codehaus.org/browse/CONTINUUM-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110444 ] Julien S commented on CONTINUUM-1528: - We have about 260 projects built every 15 minutes. I fully believe you do not run into the problem, but we have reproduced it 3 times already. Maybe could it be caused by the xmlrpc component? We are doing a pretty heavy usage of it (called every minute to check that every build is working). > Continuum gets slower over time and eventually crashes > -- > > Key: CONTINUUM-1528 > URL: http://jira.codehaus.org/browse/CONTINUUM-1528 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Julien S >Priority: Critical > > Our instance of continuum gets slower over time. > We counted the time needed to verify all projects at night when nothing has > changed in the SCM (hence, nothing is built). > During day time, the usage was quite intensive, however. > On day 1, it was about 3 minutes > On day 2, it was about 7 minutes > On day 3, it was about 10 minutes > And after a few more days (perhaps a week or so), Continuum would constantly > generate OutOfMemoryError and stop working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1528) Continuum gets slower over time and eventually crashes
[ http://jira.codehaus.org/browse/CONTINUUM-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110453 ] Julien S commented on CONTINUUM-1528: - The two servers are alongside. The full check takes about 3 to 4 minutes when nothing is built. I agree that's a fairly heavy load. But the two servers seem to be able to cope with it. We do not do fresh builds of course ! Usually during day time, in a 15m interval there are just a few commits. Continuum rebuilds them (and projects which depends on them) immediatly. You seem to suggest that the queue would fill up till exhaustion ? It is true that sometimes, the "next" schedule is triggered before the first one is completed, but at night (when there is no commit), Continuum seem to be able to process all the queue as it stops building and checking out projects (well, before the next schedule, I mean). > Continuum gets slower over time and eventually crashes > -- > > Key: CONTINUUM-1528 > URL: http://jira.codehaus.org/browse/CONTINUUM-1528 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Julien S >Priority: Critical > > Our instance of continuum gets slower over time. > We counted the time needed to verify all projects at night when nothing has > changed in the SCM (hence, nothing is built). > During day time, the usage was quite intensive, however. > On day 1, it was about 3 minutes > On day 2, it was about 7 minutes > On day 3, it was about 10 minutes > And after a few more days (perhaps a week or so), Continuum would constantly > generate OutOfMemoryError and stop working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1528) Continuum gets slower over time and eventually crashes
Continuum gets slower over time and eventually crashes -- Key: CONTINUUM-1528 URL: http://jira.codehaus.org/browse/CONTINUUM-1528 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-3 Reporter: Julien S Priority: Critical Our instance of continuum gets slower over time. We counted the time needed to verify all projects at night when nothing has changed in the SCM (hence, nothing is built). During day time, the usage was quite intensive, however. On day 1, it was about 3 minutes On day 2, it was about 7 minutes On day 3, it was about 10 minutes And after a few more days (perhaps a week or so), Continuum would constantly generate OutOfMemoryError and stop working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1528) Continuum gets slower over time and eventually crashes
[ http://jira.codehaus.org/browse/CONTINUUM-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien S updated CONTINUUM-1528: Attachment: ci.png > Continuum gets slower over time and eventually crashes > -- > > Key: CONTINUUM-1528 > URL: http://jira.codehaus.org/browse/CONTINUUM-1528 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Julien S >Priority: Critical > Attachments: ci.png > > > Our instance of continuum gets slower over time. > We counted the time needed to verify all projects at night when nothing has > changed in the SCM (hence, nothing is built). > During day time, the usage was quite intensive, however. > On day 1, it was about 3 minutes > On day 2, it was about 7 minutes > On day 3, it was about 10 minutes > And after a few more days (perhaps a week or so), Continuum would constantly > generate OutOfMemoryError and stop working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1528) Continuum gets slower over time and eventually crashes
[ http://jira.codehaus.org/browse/CONTINUUM-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110837 ] Julien S commented on CONTINUUM-1528: - Most projects have one build result (but we also deploy sites), so we deploy one artifact and one site. A few projects have several artifacts. I have attached a image of the memory heap over time. I will attach an other one in a few days. There seem to be a upward trend, but it may be too early to confirm it. > Continuum gets slower over time and eventually crashes > -- > > Key: CONTINUUM-1528 > URL: http://jira.codehaus.org/browse/CONTINUUM-1528 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Julien S >Priority: Critical > Attachments: ci.png > > > Our instance of continuum gets slower over time. > We counted the time needed to verify all projects at night when nothing has > changed in the SCM (hence, nothing is built). > During day time, the usage was quite intensive, however. > On day 1, it was about 3 minutes > On day 2, it was about 7 minutes > On day 3, it was about 10 minutes > And after a few more days (perhaps a week or so), Continuum would constantly > generate OutOfMemoryError and stop working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1528) Continuum gets slower over time and eventually crashes
[ http://jira.codehaus.org/browse/CONTINUUM-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien S updated CONTINUUM-1528: Attachment: ci2.png > Continuum gets slower over time and eventually crashes > -- > > Key: CONTINUUM-1528 > URL: http://jira.codehaus.org/browse/CONTINUUM-1528 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Julien S >Priority: Critical > Attachments: ci.png, ci2.png > > > Our instance of continuum gets slower over time. > We counted the time needed to verify all projects at night when nothing has > changed in the SCM (hence, nothing is built). > During day time, the usage was quite intensive, however. > On day 1, it was about 3 minutes > On day 2, it was about 7 minutes > On day 3, it was about 10 minutes > And after a few more days (perhaps a week or so), Continuum would constantly > generate OutOfMemoryError and stop working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1528) Continuum gets slower over time and eventually crashes
[ http://jira.codehaus.org/browse/CONTINUUM-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110943 ] Julien S commented on CONTINUUM-1528: - I have attached an other picture, which is confirming the likelihood of a "memory leak". Isn't possible that you keep in memory some data for every build result ? I will increase the maxmemory parameter in the wrapper as you suggested, but if there is indeed a "memory leaf", it will just save me a few days :) Otherwise, I'll do my best to try the latest snapshot, but, even with our heavy schedule, I will most likely need at least 4 days or so to test. I will keep you posted. > Continuum gets slower over time and eventually crashes > -- > > Key: CONTINUUM-1528 > URL: http://jira.codehaus.org/browse/CONTINUUM-1528 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Julien S >Priority: Critical > Attachments: ci.png, ci2.png > > > Our instance of continuum gets slower over time. > We counted the time needed to verify all projects at night when nothing has > changed in the SCM (hence, nothing is built). > During day time, the usage was quite intensive, however. > On day 1, it was about 3 minutes > On day 2, it was about 7 minutes > On day 3, it was about 10 minutes > And after a few more days (perhaps a week or so), Continuum would constantly > generate OutOfMemoryError and stop working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-285) regression: duplicate files added to the assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150038#action_150038 ] Julien S commented on MASSEMBLY-285: I just to give one more voice on the topic, I also strongly agree that the "normal" behavior is not to duplicate files. > regression: duplicate files added to the assembly > - > > Key: MASSEMBLY-285 > URL: http://jira.codehaus.org/browse/MASSEMBLY-285 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Brett Porter >Assignee: John Casey >Priority: Blocker > Fix For: 2.2-beta-3 > > > I found that it was possible to add a file twice to the assembly through > different filesets (a zip file) so that when it extracted it prompted for > overwrite. > It should error out or collapse the entries (as 2.1 did). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-136) when inheriting site.xml the expands to a menu with links for *all* ancestors and not just the immediate parent
[ http://jira.codehaus.org/browse/MSITE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99311 ] Julien S commented on MSITE-136: I had the same problem (but not in all cases). In a local build, everything works fine, but in a continuum based build, I encountered this bug. I believe the reason is the following: if the parent pom (and the corresponding site descriptor) cannot be found from the filesystem, it attempts to retrieve it from a repository. However, in the repository, the modules and parents paragraphs are _already_ expanded, and these expanded versions seem to serve as a base for the current site generation. > when inheriting site.xml the expands to a menu with links > for *all* ancestors and not just the immediate parent > --- > > Key: MSITE-136 > URL: http://jira.codehaus.org/browse/MSITE-136 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: 2.0.4 >Reporter: John Allen > Fix For: 2.0-beta-7 > > > multi-project environment; root project provides site.xml > root/sub1/sub2/sub3/sub4 site pages get rendered with parent menu containing > links for all the ancestors and not just the immediate sub3 parent. > copying root's site.xml into sub4 results in parent being correctly rendered. > did not test the results of copying site.xml into the middle of the ancestry > so cant say whether the parents list starts at the project that defines the > site.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-126) Add the ability to load the stylesheet from a jar (resource)
Add the ability to load the stylesheet from a jar (resource) Key: MJAVADOC-126 URL: http://jira.codehaus.org/browse/MJAVADOC-126 Project: Maven 2.x Javadoc Plugin Issue Type: Wish Affects Versions: 2.2 Reporter: Julien S Priority: Minor Currently, the stylesheetfile has to be given as a path on the filesystem, which makes sharing quite difficult. It would be nice to be able to retrieve it from a jar (like the checkstyle and the pmd plugins). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1312) Build trigger issue in multimodule project
Build trigger issue in multimodule project -- Key: CONTINUUM-1312 URL: http://jira.codehaus.org/browse/CONTINUUM-1312 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-alpha-2 Reporter: Julien S If you have a multimodule project with the parent pom at the top level directory, e.g.: + pom.xml +- module1 +- pom.xml +- module2 +- pom.xml Etc Then, a modification to any module will trigger the build of ALL modules. This is obviously because a change in a module will be detected at the top level, and that if the top level is modified, all its subprojects are rebuilt. A solution may be to put the parent POM at the same level as the others, but this triggers other problems... It would be nice to a solution at the continuum level. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99870
]
Julien S commented on MSITE-129:
I would also be interested in having this issue fixed.
I also have two different poms. One parent pom (totally outside the hierarchy)
and an aggregator POM (one directory above the modules in the filesystem
hierarchy), which is only responsible for the WEB site.
So far, this is the only way I found to make continuum happy and to avoid
triggering the rebuild of all my modules each time there is a commit in any of
them...
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1318) Add the ability to use different colors for SNAPSHOT and stable projects
Add the ability to use different colors for SNAPSHOT and stable projects Key: CONTINUUM-1318 URL: http://jira.codehaus.org/browse/CONTINUUM-1318 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1-alpha-2 Reporter: Julien S Priority: Minor When you want to release a large project, it really helps to be able to figure in a glimpse which projects are in development, so it would be nice if the lines corresponding to "SNAPSHOT" projects were in a different color. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1319) Add a link to the project web page when available.
Add a link to the project web page when available. -- Key: CONTINUUM-1319 URL: http://jira.codehaus.org/browse/CONTINUUM-1319 Project: Continuum Issue Type: Improvement Components: Web interface Reporter: Julien S Priority: Minor On the group summary page, a icon link to the project WEB page would be a worthwhile addition, when the project URL is known (e.g. for Maven1 / 2). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2795) Classloader problem loading a resource from a build extension Jar : difference between 2.0.4 and (future) 2.0.5
[ http://jira.codehaus.org/browse/MNG-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100025 ] Julien S commented on MNG-2795: --- I believe I has the same issue as reported by Fabrice, in a very similar setting (own conventions.xml and custom checker). However, the funny part is: mvn checkstyle:checkstyle works mvn site fails with the above error mvn checkstyle:checkstyle site works I should also say and moved my custom jar from an extension to a plugin dependency too. Hope this helps. > Classloader problem loading a resource from a build extension Jar : > difference between 2.0.4 and (future) 2.0.5 > --- > > Key: MNG-2795 > URL: http://jira.codehaus.org/browse/MNG-2795 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.5 >Reporter: Fabrice BELLINGARD >Assignee: Jason van Zyl > Fix For: 2.0.5 > > Attachments: Checkstyle-2.0.4.txt, Checkstyle-2.0.5.txt, > Test-BuildExtension.zip > > > I had a problem when executing the Checkstyle plugin (version 2.1) with the > pre-release of Maven 2.0.5. So I dug a bit to see if this could be related to > maven core or not, and here is what I found. > I isolated the code that breaks the build in the checkstyle plugin: it > happens when the plugin tries to load my Checkstyle configuration file, which > is actually located in a JAR that is specified in the build extensions. The > code lies in the Locator#resolveLocation() method: > // Attempt a Resource. > URL url = this.getClass().getClassLoader().getResource( > location ); > This code returns null for the "url" variable, which in turns breaks the > plugin because it doesn't find any configuration file. > I haven't had the time to dig more into it, but I found the following issue > that might be related to this problem: "MNG-2228 : Classloader problem > loading jars from build extensions". Brett and Carlos worked on it and fixed > it, so maybe they could tell more about it. > I attached the logs of the execution with Maven 2.0.4 (which works fine) and > Maven 2.0.5 (which breaks). I haven't had the time yet to dig further into > that problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1323) Checked out shell script should be made executable prior to execution
Checked out shell script should be made executable prior to execution - Key: CONTINUUM-1323 URL: http://jira.codehaus.org/browse/CONTINUUM-1323 Project: Continuum Issue Type: Bug Components: Integration - Shell Affects Versions: 1.1-alpha-2 Reporter: Julien S I had the issue with cvs, I do not know if it also happens with other SCM. I created my shell script, chmoded it 755 under Unix, and added it to my cvs repository. When I checkout the script from somewhere else, it has the right mode, however, when continuum checks it out, it is not executable, triggering a build failure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1324) Show all projects on a single page
Show all projects on a single page -- Key: CONTINUUM-1324 URL: http://jira.codehaus.org/browse/CONTINUUM-1324 Project: Continuum Issue Type: Wish Components: Web interface Affects Versions: 1.1-alpha-2 Reporter: Julien S Priority: Minor It would be nice to have the ability to see all projects (grouped by group) under a web page. There could for instance be a way to expand/collapse all groups from the groupSummary page or possibly a way to expand/collapse a subset of these project groups. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1528) Continuum gets slower over time and eventually crashes
[ http://jira.codehaus.org/browse/CONTINUUM-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120368 ] Julien S commented on CONTINUUM-1528: - I have found some time to profile continuum 1.1. As seen in the third attachment, it would appear that the memory is still used up (albeit more slowly than previously). Unfortunately, it is very difficult to figure out what could cause this... > Continuum gets slower over time and eventually crashes > -- > > Key: CONTINUUM-1528 > URL: http://jira.codehaus.org/browse/CONTINUUM-1528 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Julien S >Priority: Critical > Fix For: 1.2 > > Attachments: ci.png, ci2.png, ci3.png > > > Our instance of continuum gets slower over time. > We counted the time needed to verify all projects at night when nothing has > changed in the SCM (hence, nothing is built). > During day time, the usage was quite intensive, however. > On day 1, it was about 3 minutes > On day 2, it was about 7 minutes > On day 3, it was about 10 minutes > And after a few more days (perhaps a week or so), Continuum would constantly > generate OutOfMemoryError and stop working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1528) Continuum gets slower over time and eventually crashes
[ http://jira.codehaus.org/browse/CONTINUUM-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien S updated CONTINUUM-1528: Attachment: ci3.png > Continuum gets slower over time and eventually crashes > -- > > Key: CONTINUUM-1528 > URL: http://jira.codehaus.org/browse/CONTINUUM-1528 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.1-beta-3 >Reporter: Julien S >Priority: Critical > Fix For: 1.2 > > Attachments: ci.png, ci2.png, ci3.png > > > Our instance of continuum gets slower over time. > We counted the time needed to verify all projects at night when nothing has > changed in the SCM (hence, nothing is built). > During day time, the usage was quite intensive, however. > On day 1, it was about 3 minutes > On day 2, it was about 7 minutes > On day 3, it was about 10 minutes > And after a few more days (perhaps a week or so), Continuum would constantly > generate OutOfMemoryError and stop working. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
