Re: Get thee to the Core...
Interesting thread. So we are using Splunk as our log viewer and it has built in ability to map message ids to the localized strings. But, it's expensive for Splunk to do this (both in $ and processing time). So while its architecturally more pure it requires a good log viewer that everyone has access to. On 6/10/11 10:45 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Actually, SLF4J's tie to Ceki's I18n project is one thing I really dislike. IMO, localization should be done at the last possible moment. If you really want an internationalized log then you should be logging message ids and data and then doing the localization in your log viewer, not as you are writing the records. Ralph On Jun 10, 2011, at 8:42 AM, Stephen Connolly wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
Re: Get thee to the Core...
Oops, sorry all. I was responding to Ralph about logging. This doesn't really have much to do with Maven. On 6/11/11 9:03 AM, Clark, Gil W. gil_cl...@intuit.com wrote: Interesting thread. So we are using Splunk as our log viewer and it has built in ability to map message ids to the localized strings. But, it's expensive for Splunk to do this (both in $ and processing time). So while its architecturally more pure it requires a good log viewer that everyone has access to. On 6/10/11 10:45 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Actually, SLF4J's tie to Ceki's I18n project is one thing I really dislike. IMO, localization should be done at the last possible moment. If you really want an internationalized log then you should be logging message ids and data and then doing the localization in your log viewer, not as you are writing the records. Ralph On Jun 10, 2011, at 8:42 AM, Stephen Connolly wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail
RE: Maven 2.2.2 soon?
Seems like you are looking for an osgi sort of function? -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Wednesday, December 30, 2009 9:03 AM To: Maven Developers List Subject: Re: Maven 2.2.2 soon? I don't know why you are trying to shut off this discussion. Of course we realize 3.0 is what it is. I'm not looking for 3.0 to sit in limbo longer. At the same time, I have wanted the feature below for years. It wasn't doable with the current code base. If 3.0 changes that then great, but if it isn't any more doable with 3.0 then I guess I'm not sure what was gained. Ralph On Dec 30, 2009, at 6:47 AM, Jason van Zyl wrote: Same thing, please focus on 3.0. On 2009-12-30, at 3:22 AM, Ralph Goers wrote: On Dec 29, 2009, at 5:45 PM, Jason van Zyl wrote: I don't agree with Ralph that there needs to be a general POM extension mechanism. It's going to happen primarily inside plugins. So what you are saying is that one extension point is in the plugin configuration. That's fine but it isn't enough. I am going to continue to argue that Maven is semi-broken until it can support the equivalent of http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html in the section on dependency tags. This absolutely requires a project descriptor change. Of course, it would make even more sense to specify plugins in the project based on the capabilities that are required, not the version. I've included an example below. Today this can't be implemented. However, if the descriptor was somehow extensible it could be. And even if this does get implemented someday, I'm absolutely sure that the next day someone is going to dream up something else that requires yet another change to the descriptor. In the past we have avoided this by resorting to hacks in the code and/or making spaghetti. IMO making the bold statement that extensions won't be needed is a sure way to box ourselves into a corner. Here is an example of what I am talking about. The example below shows the common case where a library uses commons-logging but the application actually wants to use slf4j. Today you either have to do some excludes or you have to use the commons-logging-99-does-not-exist hack. Instead, commons logging and SLF4J declare what version of the APIs they support. Spring then just requires the version of commons-logging-api it needs. By specifying SLF4J in the main project's dependency management commons-logging will not be included since the required component is specified in the parent project. Notice also that the spring project doesn't have to specify a provides element since the groupId + artifactId would implicitly be declared as being provided. project groupId=org.apache.commons artifactId=commons-logging version=1.2 provides provide id=commons-logging-api version=1.1/ provide id=commons-logging-api version=1.2/ /provides /project project groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0 provides provide id=commons-logging-api version=1.1/ /provides /project project groupId=com.mycorp.test artifactId=myapp version=1.0 dependencyManagement dependencies dependency groupId=org.slf4j artifactId=jcl-over-slf4j version=2.0/ /dependencies /dependencyManagement dependencies requires id=org.springsource.spring-core version compare=ge3.1/version /requires dependencies /project project groupId=org.springsource artifactId=spring-core version=3.1 dependencyManagement dependencies dependency groupId=org.apache.commons artifactId=commons-logging version=1.2/ /dependencies /dependencyManagement depencencies requires id=commons-logging-api version=1.1/ /dependencies /project Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: No more uber jar
Hey, so how's the vacation going? Will Mark still be contacting us after Oct 1? Gil -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2008 10:01 AM To: Maven Developers List Subject: No more uber jar I made the uber jar and I think it was a mistake. It's a complete PITA to swap in new jars and test and the shading can work on the JARs necessary. I would like to remove the uber jar in 2.1 and do it on the 2.2 branch as well. Any objections? Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mercury Version Ranges
Hi Oleg, This is great stuff. I've wanted quality ranges for a long time. What's the best way to jump on to the thread here? Respond to the dev list or add a comment to the codehaus discussion? BTW, are you still at Linked In? Thanks, Gil -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2008 10:02 AM To: Maven Developers List Subject: Re: Mercury Version Ranges I've implemented the solution to the problem - please see Solution to the above problem - Quality Range in the http://docs.codehaus.org/x/twDPBQ The solution turned to be a very nice feature to also use in the Repository, I am exploring that option, please keep an eye on http://docs.codehaus.org/x/4wDPBQ - this is where I track the Repository stuff. Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mercury Version Ranges
Woops, sorry all. I meant to send this just to Oleg. Still good work though. -Original Message- From: Clark, Gil W. [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2008 10:22 AM To: Maven Developers List Subject: RE: Mercury Version Ranges Hi Oleg, This is great stuff. I've wanted quality ranges for a long time. What's the best way to jump on to the thread here? Respond to the dev list or add a comment to the codehaus discussion? BTW, are you still at Linked In? Thanks, Gil -Original Message- From: Oleg Gusakov [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2008 10:02 AM To: Maven Developers List Subject: Re: Mercury Version Ranges I've implemented the solution to the problem - please see Solution to the above problem - Quality Range in the http://docs.codehaus.org/x/twDPBQ The solution turned to be a very nice feature to also use in the Repository, I am exploring that option, please keep an eye on http://docs.codehaus.org/x/4wDPBQ - this is where I track the Repository stuff. Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Remove auto-resolution of plugin versions from Maven 2.1
So, let me see if I understand: - Assigning arbitrary quality levels is hard to do. I agree. - Linking the version selection process to something quantitative like test results and coverage results is better. I also agree but this seems a ways off. The interface between test reporting and whatever sets the metadata used by version selection will have to happen somehow. Sounds like a case for a plugin perhaps. After the test phase this plugin (tailored to whatever testing system one is using) would make a pass at the test results and then assign a quality attribute in the metadata. Then, during version selection that quality attribute is examined depending on what the user is wanting to select. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 4:53 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 On 1 May 07, at 5:37 PM 1 May 07, Clark, Gil W. wrote: I know I'm getting into iffy territory here and my thoughts on this were kind of rejected on the users list but I think that if the version selection algorithm were to include some sort of quality identifier it would solve some of these problems. The idea here is that some folks are going to want latest regardless of the quality of the latest while others are going to want the latest, highest quality release of a plug-in or component. This can be used in conjunction with a version range. So I could say version[1.0-STABLE, 2.0-STABLE)/version and I'd only get stable releases. Or I could say version[1.0-WORKING, 2.0-STABLE)/version and I'd get defaulted to STABLE as long as there is a stable version within the numeric range or if none exists I'd get WORKING if a version at that quality level falls in the range. Or I could say versionWORKING/version if I only want the absolute latest working version of a component - kind of like SNAPSHOT. This allows a POM to be targeted at a particular level of quality while still leaving it open to select from a range of versions. For final releases of a project good practice dictates the version numbers be locked down for all dependencies. That does mean modifying the POM but that seems unavoidable. Of course, there may be multiple levels of quality like WORKING, TESTED, FOO, RELEASE, etc. This is the way Ivy works. Maven has the notion of pluggable version transformations. This is the mechanism which looks at the token SNAPSHOT and performs the necessary logic to examine the metadata and retrieve the last built version. It's technically not hard to look at an arbitrary token and perform some logic to change the version that is slotted in. The problem here is not a technical one of allowing any token, the problem is that what these things mean to people and the process they go through to arrive to determine the meaning will be arbitrary. I think what people really want here is something that has some functional improvements but are binary compatible with what I'm using. What WORKING, or RELEASE means vary. Especially in the case of a release as people currently have different processes. We have already standard testing patterns and surefire, and we are starting to see standard release procedures so what we want to move toward is the use of ranges which would be good but coupled with some criteria for quality. So you would simply say I want [1.0,) which is anything 1.0 or above that 1) is binary compatible with what I used last time (we go and find the last release and see what version was resolved), and 2) has the same or better coverage. This is the only way you can deterministically be safe of picking something further down in a range. Who's going to assign these arbitrary labels to releases? I mean who is doing this for Ivy? This stuff cannot be tacked on by the third party it simply is not scalable. Maven has the social capital (the necessary mass of users doing the same thing) to pull off these coverage and binary compatibility standards to make this transparent. That being said I still think people would benefit more from a daily report produced from a build server that pulled in new versions of dependencies that purport to work and actually run your tests. If successful then you click a button and your POMs are upgrade. The computer should do the crap work. We are really not that far away from something like this. The hardest part in all this is standardizing on these quality levels - t Bingo. This can only happen in a community like Maven where we have striven for standard everything from day one because this is the only way these types of things are possible. This will never be possible using Ant with Ivy, it was never the goal of Ant. They might say they can but that will require the addition of everything we already have. Then it will be converging toward what Maven
RE: Remove auto-resolution of plugin versions from Maven 2.1
I know I'm getting into iffy territory here and my thoughts on this were kind of rejected on the users list but I think that if the version selection algorithm were to include some sort of quality identifier it would solve some of these problems. The idea here is that some folks are going to want latest regardless of the quality of the latest while others are going to want the latest, highest quality release of a plug-in or component. This can be used in conjunction with a version range. So I could say version[1.0-STABLE, 2.0-STABLE)/version and I'd only get stable releases. Or I could say version[1.0-WORKING, 2.0-STABLE)/version and I'd get defaulted to STABLE as long as there is a stable version within the numeric range or if none exists I'd get WORKING if a version at that quality level falls in the range. Or I could say versionWORKING/version if I only want the absolute latest working version of a component - kind of like SNAPSHOT. This allows a POM to be targeted at a particular level of quality while still leaving it open to select from a range of versions. For final releases of a project good practice dictates the version numbers be locked down for all dependencies. That does mean modifying the POM but that seems unavoidable. Of course, there may be multiple levels of quality like WORKING, TESTED, FOO, RELEASE, etc. This is the way Ivy works. The hardest part in all this is standardizing on these quality levels - they can be dynamic - specified in the settings file or top level POM... -Original Message- From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 1:36 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Le mardi 1 mai 2007, Tomasz Pik a écrit : On 5/1/07, Hervé BOUTEMY [EMAIL PROTECTED] wrote: Le mardi 1 mai 2007, Jerome Lacoste a écrit : Maybe there could be an easy way to let users use the latest ? maybe something like mvn -L ... ( L for latest) that would ignore all specified versions, without requiring a POM change ? Maybe too radical. such a LATEST option would be very usefull, not only for plugins but for every dependencies, to do regression testing against latest development version of everything. It would be like if Gump was integrated into Maven: http://gump.apache.org/ I think we would need to differentiate plugin latest from dependencies latest. This LATEST thing is already in jira: http://jira.codehaus.org/browse/MNG-2431 And I think it would be very useful, both for plugins and for 'normal dependencies'. not exactly: - LATEST STABLE is not LATEST : LATEST doesn't try to differentiate STABLE or not, just get any change to check ASAP if it breaks something - mvn -L is on the command line, not in the pom : the pom refers to chosen versions, for normal builds, but mvn -L is for continuous builds, overriding chosen versions of the pom, to check if a dependency has an evolution that will break something. The artifact built with mvn -L is not intended for use, but only as a pro-active test against dependencies evolution Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question on building Maven 2.0.x
A couple weeks back I was successfully building Maven 2.0.x. The last stage of the build is to run mvn assembly:assembly in the maven-core directory. The resultant zip, gz, etc. contained the uberjar called maven-2.0.x-uber.jar which goes in the lib directory. Unzip it somewhere - everything runs fine. About 4 days ago the build mysteriously stopped building the uber jar. I've tried this on two different machines with the same result - I have no idea what changed - nothing I did (on purpose). Any help appreciated. Thanks
RE: Question on building Maven 2.0.x
Sorry to be naïve but is the shade work going to replace the way the uber jar was used? Thanks -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 8:23 AM To: Maven Developers List Subject: Re: Question on building Maven 2.0.x On 18 Apr 07, at 10:55 AM 18 Apr 07, Clark, Gil W. wrote: A couple weeks back I was successfully building Maven 2.0.x. The last stage of the build is to run mvn assembly:assembly in the maven-core directory. The resultant zip, gz, etc. contained the uberjar called maven-2.0.x-uber.jar which goes in the lib directory. Unzip it somewhere - everything runs fine. About 4 days ago the build mysteriously stopped building the uber jar. I've tried this on two different machines with the same result - I have no idea what changed - nothing I did (on purpose). A couple folks have been working on the shade plugin so I'll lock it down to a version as during alpha releases features have been added which changed the configuration. Jason. Any help appreciated. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Question on building Maven 2.0.x
I figured it out - I went back to v 1.4 of shade. -Original Message- From: Clark, Gil W. [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 8:53 AM To: Maven Developers List Subject: RE: Question on building Maven 2.0.x Sorry to be naïve but is the shade work going to replace the way the uber jar was used? Thanks -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 8:23 AM To: Maven Developers List Subject: Re: Question on building Maven 2.0.x On 18 Apr 07, at 10:55 AM 18 Apr 07, Clark, Gil W. wrote: A couple weeks back I was successfully building Maven 2.0.x. The last stage of the build is to run mvn assembly:assembly in the maven-core directory. The resultant zip, gz, etc. contained the uberjar called maven-2.0.x-uber.jar which goes in the lib directory. Unzip it somewhere - everything runs fine. About 4 days ago the build mysteriously stopped building the uber jar. I've tried this on two different machines with the same result - I have no idea what changed - nothing I did (on purpose). A couple folks have been working on the shade plugin so I'll lock it down to a version as during alpha releases features have been added which changed the configuration. Jason. Any help appreciated. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven's version resolution process
I've modified Maven's versioning scheme to fit our corporate version schema standard and to fit the way we need to choose components via a discrete set of quality test states. The mod preserves Maven's normal process so that plugins resolution still works but it will use the custom process for versions which have special quality state qualifiers attached to them. It works well but because I had to change the code at a deep level (DefaultArtifactVersion.java) I consider this a hack whereas if version resolution were plugable it would rather be an extension. I realize that changing this kind of this is not trivial but perhaps there is something the experts are thinking about that allows version selection to be extended based on individual software lifecycle processes? Thanks
