Re: Shared projects and Maven best practice
That solution sounds reasonable. I misunderstood your problem. I though it was abnormal release cycles, not abnormal CVS setup. Eric On 4/6/06, Mang Jun Lau <[EMAIL PROTECTED]> wrote: > > "Eric Redmond" <[EMAIL PROTECTED]> wrote on 04/06/2006 09:40:38 AM: > > > > > I created an alternate repository named "TAG" (whatever your tag is) and > > pointed apache to it. For example, if your corporate repo is > > http://corp/repo1, then create another repository named > > http://corp/repo1-TAG, and continuum can build only specific projects > that > > should be overridden. This repository was populated solely with a > specific > > tagged cut of the code. Then your team can depend upon the repositories > of > > both. When they point to Utility 1.0.0, they should pick it up from TAG. > > Isn't creating another repository too much overhead and a little overkill? > Currently, we build the applications from RAD with the Utility project > source. If an application needs to rely on older Utility source, we > simply check out a tagged version of it into the workspace. Now, with > Maven and Continuum, it gets a bit messy when you want to build your whole > application together along with the Utility jars since we don't use Maven > conventions with regards to CVS modules (i.e. each project is a separate > module so the whole application has many CVS modules and not just one). To > build properly using Continuum, I had to symlink all the modules into one > so that Continuum can check it out properly. So the problem is that I > can't mix and match CVS tags in one build. > > > Now, in my defense, this strategy was employed to work on top of a very > > legacy build/deploy system that knew only of SNAPSHOTs (and nothing > else... > > so its not really fair to even call it a versioning system). It sounds > like > > you guys have an equally goofy system. Are you guys supporting legacy > > version in tandem? Meaning, do you branch 1.0 and continue working on > it, > > and then also work on 1.1? This was actually our big problem. > > We don't tend to do branching and we usually work off of HEAD. When we > release, we tag everything in our existing workspace and continue to work > off HEAD for the next release. > > Right now, the solution for us may be to mix and match tags in the RAD > workspace to your liking, then tag your entire workspace, then in > Continuum, build from that tag. > > > _Mang >
Re: Shared projects and Maven best practice
"Eric Redmond" <[EMAIL PROTECTED]> wrote on 04/06/2006 09:40:38 AM: > > I created an alternate repository named "TAG" (whatever your tag is) and > pointed apache to it. For example, if your corporate repo is > http://corp/repo1, then create another repository named > http://corp/repo1-TAG, and continuum can build only specific projects that > should be overridden. This repository was populated solely with a specific > tagged cut of the code. Then your team can depend upon the repositories of > both. When they point to Utility 1.0.0, they should pick it up from TAG. Isn't creating another repository too much overhead and a little overkill? Currently, we build the applications from RAD with the Utility project source. If an application needs to rely on older Utility source, we simply check out a tagged version of it into the workspace. Now, with Maven and Continuum, it gets a bit messy when you want to build your whole application together along with the Utility jars since we don't use Maven conventions with regards to CVS modules (i.e. each project is a separate module so the whole application has many CVS modules and not just one). To build properly using Continuum, I had to symlink all the modules into one so that Continuum can check it out properly. So the problem is that I can't mix and match CVS tags in one build. > Now, in my defense, this strategy was employed to work on top of a very > legacy build/deploy system that knew only of SNAPSHOTs (and nothing else... > so its not really fair to even call it a versioning system). It sounds like > you guys have an equally goofy system. Are you guys supporting legacy > version in tandem? Meaning, do you branch 1.0 and continue working on it, > and then also work on 1.1? This was actually our big problem. We don't tend to do branching and we usually work off of HEAD. When we release, we tag everything in our existing workspace and continue to work off HEAD for the next release. Right now, the solution for us may be to mix and match tags in the RAD workspace to your liking, then tag your entire workspace, then in Continuum, build from that tag. _Mang
Re: Shared projects and Maven best practice
Oh, its unfortunate that I have run across this interesting thread just now. I actually ran across the exact same issue. Here's what I did (note this may not be the most elegant solution, however, it worked well, and was the easiest to implement). Since you mentioned that this is merely for rapid development, it is presumed that you will eventually update everyone to the newest version. I created an alternate repository named "TAG" (whatever your tag is) and pointed apache to it. For example, if your corporate repo is http://corp/repo1, then create another repository named http://corp/repo1-TAG, and continuum can build only specific projects that should be overridden. This repository was populated solely with a specific tagged cut of the code. Then your team can depend upon the repositories of both. When they point to Utility 1.0.0, they should pick it up from TAG. Now, in my defense, this strategy was employed to work on top of a very legacy build/deploy system that knew only of SNAPSHOTs (and nothing else... so its not really fair to even call it a versioning system). It sounds like you guys have an equally goofy system. Are you guys supporting legacy version in tandem? Meaning, do you branch 1.0 and continue working on it, and then also work on 1.1? This was actually our big problem. Eric On 4/4/06, Mang Jun Lau <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > I just want to spark a discussion here on the list. I want to know if you > guys/girls have encountered a simliar problem to what I'm having now. So > here goes: > > At our company we have two J2EE applications that are fairly large with > many projects. We operate in a RAD/Eclipse environment with CVS as our > SCM. There are shared projects (e.g. Utility projects) between the two > applications. These shared projects are developed more or less separately > from the two main applications. It is ideal for the two big applications > to depend on the latest (i.e. HEAD) of the utility projects. However, > sometimes when deadlines are looming, and there's no time to test these > latest changes, one or both of our applications will want to depend on an > older, CVS tagged version of these utility projects. > > So the question is, how can I design my POM for these Utility projects so > that I can build the application despite using a CVS tagged version? > > What I have now: > - App 1 depends on Utility 1.1.0 (HEAD) > - App 2 depends on Utility 1.0.0 (old CVS tagged version) > - Continuum 1.0.2 > - Utility pom.xml at HEAD is 1.1.0 > - Utility pom.xml at tag is 1.0.0 > - both applications are in Continuum, modules are symlinked in CVS so that > Continuum can check them all out at once. Utility project included with > each application checkout. > > So really I guess that if there's a way to checkout an older version of > the Utility project but HEAD of everything else, then I'm fine. Is there > a way to do this? Or am I using Maven incorrectly? If I'm unclear, please > ask and I'll try my best to clarify what I have. > > Thanks so much. > > > _Mang Lau >
Re: Shared projects and Maven best practice
Yes, you can override both version and scope in the child POM. -Stephen On 4/4/06, Arnaud Bailly <[EMAIL PROTECTED]> wrote: > Didn't know about this tag. This allows to > specify default characteristics for a dependency that may be overriden > by a pom ? > > > -- > Arnaud Bailly, Dr. - Ingénieur de Recherche > NORSYS > 1, rue de la Cense des Raines > ZAC du Moulin > 59710 ENNEVELIN > Tel : (33) 3 28 76 56 76 > Mob : (33) 6 17 12 19 78 > Fax : (33) 3 28 76 57 00 > Web : http://www.norsys.fr > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Stephen Duncan Jr www.stephenduncanjr.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared projects and Maven best practice
I've never tried overriding the version number in a child pom but I'd guess it works. Give it a try and find out! Basically dependencyManagement lets you specify... parent-pom.xml junit junit 3.8.1 log4j log4j 1.2.13 child-pom.xml (note, no version #s specified) junit junit log4j log4j So the children all inherit the version # from the depMgmt in the parent. You can also use this in profiles to specify exact version #s for dependencies in specific profiles -- and can even change the scope, so for profile=dev your commons-logging.jar is compile scope, but profile=prod it uses provided, etc. We've talked about this and provided a few examples on the user@ list lately, so go search the archive and I'm sure you'll find lots more info... Wayne On 4/4/06, Mang Jun Lau <[EMAIL PROTECTED]> wrote: > Yes I believe so. > > > _Mang Lau > > > > > > Arnaud Bailly <[EMAIL PROTECTED]> > 04/04/2006 04:37 PM > Please respond to > "Maven Users List" > > > To > "Maven Users List" > cc > > Subject > Re: Shared projects and Maven best practice > > > > > > > Didn't know about this tag. This allows to > specify default characteristics for a dependency that may be overriden > by a pom ? > > > -- > Arnaud Bailly, Dr. - Ingénieur de Recherche > NORSYS > 1, rue de la Cense des Raines > ZAC du Moulin > 59710 ENNEVELIN > Tel : (33) 3 28 76 56 76 > Mob : (33) 6 17 12 19 78 > Fax : (33) 3 28 76 57 00 > Web : http://www.norsys.fr > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > >
Re: Shared projects and Maven best practice
Yes I believe so. _Mang Lau Arnaud Bailly <[EMAIL PROTECTED]> 04/04/2006 04:37 PM Please respond to "Maven Users List" To "Maven Users List" cc Subject Re: Shared projects and Maven best practice Didn't know about this tag. This allows to specify default characteristics for a dependency that may be overriden by a pom ? -- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared projects and Maven best practice
Didn't know about this tag. This allows to specify default characteristics for a dependency that may be overriden by a pom ? -- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared projects and Maven best practice
yea you're right. I totally forgot about . Thanks :) _Mang Lau "Wayne Fay" <[EMAIL PROTECTED]> 04/04/2006 12:41 PM Please respond to "Maven Users List" To "Maven Users List" cc Subject Re: Shared projects and Maven best practice > release a version of the Utility project. As a result of this release, we > would have to manually update all the POMs dependent on the Utility > project with the specific version number being released. Then, we would > have to manually update all the POMs from the other application that needs > to depend on the new snapshot number since it is now incremented. This Can you not utilize and then change the Utility version in one parent POM for each project, rather than in "every pom file" in the project? This doesn't seem unreasonable to me... Wayne
RE: Shared projects and Maven best practice
Yes this seems feasible. The only thing is that changing the utility project requires a new deploy but it doesn't change that often anyways. Thanks for your input Daniel, I might end up implementing your suggestion depending on the consensus from others. _Mang Lau "Siegmann Daniel, NY" <[EMAIL PROTECTED]> 04/04/2006 12:14 PM Please respond to "Maven Users List" To 'Maven Users List' cc Subject RE: Shared projects and Maven best practice > Do I make sense or am I missing something? > > Thanks again for your reply. > > > _Mang Lau This is only true if you have to change the snapshot version. I don't know much about snapshots, particularly in Maven2, but I would assume you could just have a snapshot version "1-SNAPSHOT" and then have versions "1.0.0", "1.0.1", "1.1.0", and so on. A project which was working on HEAD would just use "1-SNAPSHOT" as the dependency. This way only the project which moved off of HEAD would have to list a specific version. There is one disadvantage to this if you work in Eclipse: you can't modify the utility code from the application project b/c it's in a jar file, and changes to the utility code won't affect the application projects until you update the jar. You'd have to make changes to the utility code and then run install on the utility project. Or if you need to make some quick changes to continue your work, just copy the relevant source code into your application project temporarily (this should override the version in the jar). Still, it is probably not impossible for you to continue working the way you do now. I am not familiar with Continuum, but I think this would be easy enough to do with CruiseControl. I would just check out a copy from the tag (in a different directory) for CC, and then update the application project's entry in CC's config.xml to point to the new checkout. Perhaps someone familiar with Continuum will know how you can achieve what you're looking for. -- Daniel Siegmann FJA-US, Inc. (212) 840-2618 ext. 139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared projects and Maven best practice
I may be misunderstanding something, as I have still some problems understanding artifact resolution in m2, but I thing the LATEST keyword is useful in such a situation. AFAIK, the maven-metadata in the repos contains pointers for latest (and release ?). This seems to work for a whole artifact, whatever its version is. This may means that if you need latest from head, you could say org.codehaus.mojo surefire-report-maven-plugin and it would be resolved using the metadata which may contain : org.codehaus.mojo surefire-report-maven-plugin 2.0-beta-1 2.0-beta-1 2.0-beta-1 2.0-beta-1 2.0 20051005032907 OTOH, if you need a specific version, you can just tell it in the pom org.codehaus.mojo surefire-report-maven-plugin 2.0 Not sure this means something, but the discussion is open... -- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared projects and Maven best practice
> release a version of the Utility project. As a result of this release, we > would have to manually update all the POMs dependent on the Utility > project with the specific version number being released. Then, we would > have to manually update all the POMs from the other application that needs > to depend on the new snapshot number since it is now incremented. This Can you not utilize and then change the Utility version in one parent POM for each project, rather than in "every pom file" in the project? This doesn't seem unreasonable to me... Wayne
RE: Shared projects and Maven best practice
> Do I make sense or am I missing something? > > Thanks again for your reply. > > > _Mang Lau This is only true if you have to change the snapshot version. I don't know much about snapshots, particularly in Maven2, but I would assume you could just have a snapshot version "1-SNAPSHOT" and then have versions "1.0.0", "1.0.1", "1.1.0", and so on. A project which was working on HEAD would just use "1-SNAPSHOT" as the dependency. This way only the project which moved off of HEAD would have to list a specific version. There is one disadvantage to this if you work in Eclipse: you can't modify the utility code from the application project b/c it's in a jar file, and changes to the utility code won't affect the application projects until you update the jar. You'd have to make changes to the utility code and then run install on the utility project. Or if you need to make some quick changes to continue your work, just copy the relevant source code into your application project temporarily (this should override the version in the jar). Still, it is probably not impossible for you to continue working the way you do now. I am not familiar with Continuum, but I think this would be easy enough to do with CruiseControl. I would just check out a copy from the tag (in a different directory) for CC, and then update the application project's entry in CC's config.xml to point to the new checkout. Perhaps someone familiar with Continuum will know how you can achieve what you're looking for. -- Daniel Siegmann FJA-US, Inc. (212) 840-2618 ext. 139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shared projects and Maven best practice
Thanks for the reply. I actually thought of this idea too so I had a hard time coming up with why it doesn't work or why it's hard. I think we depend on CVS naturally because we use RAD as our environment and it's just easier to do so. Anyways, the solution that you have come up with is hard because we have two applications. So say both the applications are using the latest snapshot version of the utility project. Then, one wants to stop using HEAD while the other application continues to use HEAD/snapshot. So we release a version of the Utility project. As a result of this release, we would have to manually update all the POMs dependent on the Utility project with the specific version number being released. Then, we would have to manually update all the POMs from the other application that needs to depend on the new snapshot number since it is now incremented. This means that we would have to coordinate between the two application teams while really it should only affect one team. Do I make sense or am I missing something? Thanks again for your reply. _Mang Lau "Siegmann Daniel, NY" <[EMAIL PROTECTED]> 04/04/2006 10:36 AM Please respond to "Maven Users List" To 'Maven Users List' cc Subject RE: Shared projects and Maven best practice I'm afraid I can't help with your problem exactly, but since you wanted to spark a discussion... > So really I guess that if there's a way to checkout an older > version of > the Utility project but HEAD of everything else, then I'm > fine. Is there > a way to do this? Or am I using Maven incorrectly? If I'm > unclear, please > ask and I'll try my best to clarify what I have. > > Thanks so much. > > > _Mang Lau Why are you having your applications depend on CVS at all? I would think it would be best to build Utility as its own jar, which would by deployed to your central repository. Each release (tagged version) would exist as a jar in your repository, and you could approximate CVS HEAD by deploying snapshots. Then you can set the dependencies in your applications to whichever versions you wish (an exact version for a tag, and a snapshot for HEAD). Unless I'm missing a reason why this wouldn't work? -- Daniel Siegmann FJA-US, Inc. (212) 840-2618 ext. 139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Shared projects and Maven best practice
I'm afraid I can't help with your problem exactly, but since you wanted to spark a discussion... > So really I guess that if there's a way to checkout an older > version of > the Utility project but HEAD of everything else, then I'm > fine. Is there > a way to do this? Or am I using Maven incorrectly? If I'm > unclear, please > ask and I'll try my best to clarify what I have. > > Thanks so much. > > > _Mang Lau Why are you having your applications depend on CVS at all? I would think it would be best to build Utility as its own jar, which would by deployed to your central repository. Each release (tagged version) would exist as a jar in your repository, and you could approximate CVS HEAD by deploying snapshots. Then you can set the dependencies in your applications to whichever versions you wish (an exact version for a tag, and a snapshot for HEAD). Unless I'm missing a reason why this wouldn't work? -- Daniel Siegmann FJA-US, Inc. (212) 840-2618 ext. 139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shared projects and Maven best practice
Hi everyone, I just want to spark a discussion here on the list. I want to know if you guys/girls have encountered a simliar problem to what I'm having now. So here goes: At our company we have two J2EE applications that are fairly large with many projects. We operate in a RAD/Eclipse environment with CVS as our SCM. There are shared projects (e.g. Utility projects) between the two applications. These shared projects are developed more or less separately from the two main applications. It is ideal for the two big applications to depend on the latest (i.e. HEAD) of the utility projects. However, sometimes when deadlines are looming, and there's no time to test these latest changes, one or both of our applications will want to depend on an older, CVS tagged version of these utility projects. So the question is, how can I design my POM for these Utility projects so that I can build the application despite using a CVS tagged version? What I have now: - App 1 depends on Utility 1.1.0 (HEAD) - App 2 depends on Utility 1.0.0 (old CVS tagged version) - Continuum 1.0.2 - Utility pom.xml at HEAD is 1.1.0 - Utility pom.xml at tag is 1.0.0 - both applications are in Continuum, modules are symlinked in CVS so that Continuum can check them all out at once. Utility project included with each application checkout. So really I guess that if there's a way to checkout an older version of the Utility project but HEAD of everything else, then I'm fine. Is there a way to do this? Or am I using Maven incorrectly? If I'm unclear, please ask and I'll try my best to clarify what I have. Thanks so much. _Mang Lau
