[Patch] Missing dependency in continuum-trunk
Hi all, There is a missing dependency on activation.jar within continuum-war. The following patch fixes it. Index: continuum-webapp/pom.xml === --- continuum-webapp/pom.xml(revision 472890) +++ continuum-webapp/pom.xml(working copy) @@ -200,6 +200,12 @@ version1.0-alpha-2/version /dependency dependency + groupIdjavax.activation/groupId + artifactIdactivation/artifactId + version1.1/version + scopeprovided/scope +/dependency +dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.4/version Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: build scheduling issues
sorry, once changed how? once the group dependencies are sorted out? if we are taking all projects across all groups and trying to generate a cycle free graph then cycles are potentially a problem. just so we are clear in my mind: * grab all projects across all groups * attempt to sort * if success, build normally * if failure, notify of cycle and proceed to sequentially process groups, sorting projects in that group only and building * if cycle detected in that group then build all projects in that group in any old order that comes out of the database The difference between this and what used to exist before my group changes is that it will attempt to order inside the group and build as opposed to before where it would just failover to building all projects in whatever order came from the db. is that where we are with this? jesse On 11/8/06, Brett Porter [EMAIL PROTECTED] wrote: That's a cycle between the groups, not the projects, so shouldn't be a problem once changed. - Brett On 09/11/2006, at 1:57 AM, Jesse McConnell wrote: the issue isn't cycles within a normal m2 build, but when you shove 4 or 5 of them together into one continuum instance and then ask them all to play together. For example if you shoved continuum, maven-shared and archiva all into the same continuum instance and triggered a build with all of them in the same directed graph then we have had instances of cycles in the past (not sure about right now, mpir cycle might be refactored out thanks to joakim). emm had another example last night when we were talking about it as well. jesse On 11/8/06, Brett Porter [EMAIL PROTECTED] wrote: Sorry, am I missing something? How do we end up with a cycle in Continuum? Is there a specific example? I know it's possible - we had to allow it in the repository (eg, dom4j - jaxen), but it is certainly undesirable and honestly should be rare, especially in m2 built artifacts. Should it produce a build warning? Basically, the treatment there is to just stop following the tree when you hit the cycle, rather than changing the way things are ordered. So it's really arbitrary which might come first, but isn't really a concern there. Anyway, just wondering. Cheers, Brett On 08/11/2006, at 11:46 PM, Emmanuel Venisse wrote: Yes Jesse McConnell a écrit : we should add a page that analyzes each schedule for cycles...that would be a cool little feature On 11/8/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: Yes, we need a global ordering, so projects will be build independently of groups, because in some case a cycle can be created between groups (not necessary between projects). In case a cycle is detected between projects, continuum can't find the build order. In this case, I think we need to sort a little project so will reduce build errors. So if we have a cycle, we can sort projects in a group and build them. In most of case (maven projects), we don't have a cycle in a group. Emmanuel Brett Porter a écrit : I think you want global ordering. Grouping should just be a display/management technique, not anything that changes how projects are handled. However, this needs to be reviewed as a whole (which I think Emmanuel is doing), such that builds can be triggered when their dependencies change which will help with the ordering as it won't be dependant on them all being triggered at the same time? - Brett On 08/11/2006, at 9:51 AM, Jesse McConnell wrote: I was reading through the DefaultContinuum.buildProjects ( Schedule id ) method and after discussing some things with Emmanuel...I think we have a problem here. When I went through and refactored things to support a more Project Group centric setup with continuum I changed this method a bit. Originally, this method would gather up all projects that would be triggered by that schedule, run them all through the project sorter and then build each in sequence. When I added the project groups to this mix, I changed things to be on a project group basis, so that on a project group by project group basis it would order the projects and build them. At the time I thought this was the way to go...but maybe not. 17:14 evenisse we need to take all projects from all groups, sort them 17:15 evenisse if we don't have a cycle, it's ok and we build all 17:15 evenisse if it isn't ok, we sort project by group For example, if we loaded up a Plexus group and a Maven group...the way it currently is (with my change) it would process all triggered builds within one group and then process all triggered builds in the other group. This would not take into account potential dependencies between the two. Does anyone have any thoughts on this? I am inclined to fix it up so its like it used to be where all projects across all project groups
Re: [Patch] Missing dependency in continuum-trunk
hm, someone else seeing this Christian! your not the only one now! graham, what o/s and version of maven and jdk are you using? jesse On 11/9/06, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, There is a missing dependency on activation.jar within continuum-war. The following patch fixes it. Index: continuum-webapp/pom.xml === --- continuum-webapp/pom.xml(revision 472890) +++ continuum-webapp/pom.xml(working copy) @@ -200,6 +200,12 @@ version1.0-alpha-2/version /dependency dependency + groupIdjavax.activation/groupId + artifactIdactivation/artifactId + version1.1/version + scopeprovided/scope +/dependency +dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.4/version Regards, Graham -- -- jesse mcconnell [EMAIL PROTECTED]
Re: [Patch] Missing dependency in continuum-trunk
Jesse McConnell wrote: hm, someone else seeing this Christian! your not the only one now! graham, what o/s and version of maven and jdk are you using? maven v2.0.4 on JDK v1.5 (latest MacosX). Not that it should make a difference on any platform - one of the class files references javax.activation, and javax.activation isn't a dependency in the pom. Probably caused by a modified pom.xml that wasn't checked in. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Continuum-trunk notifiers toasted on startup
Hi all, I am getting the following exception on continuum trunk webapp startup, which prevents it working: java.lang.ClassNotFoundException: org.codehaus.plexus.mailsender.javamail.JavamailMailSender This exception seems to be the last exception in the very long chain of exceptions below: Any ideas? 2006-11-09 18:05:01,027 [main] INFO PlexusContainer- Loading on start [role,roleHint]: [org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor,build-project] - this realm = plexus.core Number of imports: 0 - 2006-11-09 18:05:01,504 [main] ERROR [/continuum] - Exception sending context initialized event to listener instance of class org.codehaus.plexus.xwork.PlexusLifecycleListener java.lang.RuntimeException: org.codehaus.plexus.PlexusContainerException: Error initializaing container in [EMAIL PROTECTED] at org.codehaus.plexus.xwork.PlexusLifecycleListener.contextInitialized(PlexusLifecycleListener.java:65) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3763) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4211) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:608) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) Caused by: org.codehaus.plexus.PlexusContainerException: Error initializaing container in [EMAIL PROTECTED] at org.codehaus.plexus.DefaultPlexusContainer.initializePhases(DefaultPlexusContainer.java:614) at org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:564) at org.codehaus.plexus.DefaultPlexusContainer.init(DefaultPlexusContainer.java:235) at org.codehaus.plexus.DefaultPlexusContainer.init(DefaultPlexusContainer.java:197) at org.codehaus.plexus.xwork.PlexusLifecycleListener.contextInitialized(PlexusLifecycleListener.java:59) ... 24 more Caused by: org.codehaus.plexus.container.initialization.ContainerInitializationException: Error looking up load-on-start component. at org.codehaus.plexus.container.initialization.StartLoadOnStartComponentsPhase.execute(StartLoadOnStartComponentsPhase.java:57) at org.codehaus.plexus.DefaultPlexusContainer.initializePhases(DefaultPlexusContainer.java:610) ... 28 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Unable to lookup component 'org.codehaus.plexus.taskqueue.execution.TaskQueueExecutorbuild-project', it could not be started at org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:86) at org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:191) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:265) at org.codehaus.plexus.container.initialization.StartLoadOnStartComponentsPhase.execute(StartLoadOnStartComponentsPhase.java:52) ... 29 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLifecycleException: Error starting component at
Re: svn commit: r473012 - /maven/continuum/trunk/continuum-webapp/pom.xml
Doesn't the plexus-runtime need it too? Christian. [EMAIL PROTECTED] wrote: Author: jmcconnell Date: Thu Nov 9 10:39:25 2006 New Revision: 473012 URL: http://svn.apache.org/viewvc?view=revrev=473012 Log: added activation dependency, it appears that WorkingCopyAction brings in this dependency so it ought to be marked as such, thanks to graham for noticing this Modified: maven/continuum/trunk/continuum-webapp/pom.xml Modified: maven/continuum/trunk/continuum-webapp/pom.xml URL: http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-webapp/pom.xml?view=diffrev=473012r1=473011r2=473012 == --- maven/continuum/trunk/continuum-webapp/pom.xml (original) +++ maven/continuum/trunk/continuum-webapp/pom.xml Thu Nov 9 10:39:25 2006 @@ -416,5 +416,11 @@ artifactIdcommons-lang/artifactId version2.1/version /dependency +dependency + groupIdjavax.activation/groupId + artifactIdactivation/artifactId + version1.1/version + scopeprovided/scope +/dependency /dependencies /project -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
Re: build scheduling issues
I'm lost :) My point below was that if you just took all the projects and sorted them, there is no cycle in the example you gave. The cycle would come if you tried to order them by groups, because there are dependencies between projects within the groups in both directions. so... In 1.0.3, scheduling a project didn't build any dependencies, but if you scheduled a bunch then they were built in order. I don't know what happened if there were cycles. In trunk, it does what is below, or is that where you want to go with it? And building dependencies is a next step on top of that? Honestly, I'm not seeing where cycles are going to be a common case, and when they occur I don't think we need to be too concerned about the order they build in. I have been extremely dense recently though so I'm sure I'm missing something :) Cheers, Brett On 10/11/2006, at 2:20 AM, Jesse McConnell wrote: sorry, once changed how? once the group dependencies are sorted out? if we are taking all projects across all groups and trying to generate a cycle free graph then cycles are potentially a problem. just so we are clear in my mind: * grab all projects across all groups * attempt to sort * if success, build normally * if failure, notify of cycle and proceed to sequentially process groups, sorting projects in that group only and building * if cycle detected in that group then build all projects in that group in any old order that comes out of the database The difference between this and what used to exist before my group changes is that it will attempt to order inside the group and build as opposed to before where it would just failover to building all projects in whatever order came from the db. is that where we are with this? jesse On 11/8/06, Brett Porter [EMAIL PROTECTED] wrote: That's a cycle between the groups, not the projects, so shouldn't be a problem once changed. - Brett On 09/11/2006, at 1:57 AM, Jesse McConnell wrote: the issue isn't cycles within a normal m2 build, but when you shove 4 or 5 of them together into one continuum instance and then ask them all to play together. For example if you shoved continuum, maven-shared and archiva all into the same continuum instance and triggered a build with all of them in the same directed graph then we have had instances of cycles in the past (not sure about right now, mpir cycle might be refactored out thanks to joakim). emm had another example last night when we were talking about it as well. jesse On 11/8/06, Brett Porter [EMAIL PROTECTED] wrote: Sorry, am I missing something? How do we end up with a cycle in Continuum? Is there a specific example? I know it's possible - we had to allow it in the repository (eg, dom4j - jaxen), but it is certainly undesirable and honestly should be rare, especially in m2 built artifacts. Should it produce a build warning? Basically, the treatment there is to just stop following the tree when you hit the cycle, rather than changing the way things are ordered. So it's really arbitrary which might come first, but isn't really a concern there. Anyway, just wondering. Cheers, Brett On 08/11/2006, at 11:46 PM, Emmanuel Venisse wrote: Yes Jesse McConnell a écrit : we should add a page that analyzes each schedule for cycles...that would be a cool little feature On 11/8/06, Emmanuel Venisse [EMAIL PROTECTED] wrote: Yes, we need a global ordering, so projects will be build independently of groups, because in some case a cycle can be created between groups (not necessary between projects). In case a cycle is detected between projects, continuum can't find the build order. In this case, I think we need to sort a little project so will reduce build errors. So if we have a cycle, we can sort projects in a group and build them. In most of case (maven projects), we don't have a cycle in a group. Emmanuel Brett Porter a écrit : I think you want global ordering. Grouping should just be a display/management technique, not anything that changes how projects are handled. However, this needs to be reviewed as a whole (which I think Emmanuel is doing), such that builds can be triggered when their dependencies change which will help with the ordering as it won't be dependant on them all being triggered at the same time? - Brett On 08/11/2006, at 9:51 AM, Jesse McConnell wrote: I was reading through the DefaultContinuum.buildProjects ( Schedule id ) method and after discussing some things with Emmanuel...I think we have a problem here. When I went through and refactored things to support a more Project Group centric setup with continuum I changed this method a bit. Originally, this method would gather up all projects that would be triggered by that schedule, run them all through the project sorter and then build each in sequence.
