You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Mang Jun Lau <Ma...@otpp.com> on 2006/04/04 15:55:59 UTC
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
Re: Shared projects and Maven best practice
Posted by Eric Redmond <er...@gmail.com>.
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 <Ma...@otpp.com> wrote:
>
> "Eric Redmond" <er...@gmail.com> 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
Posted by Mang Jun Lau <Ma...@otpp.com>.
"Eric Redmond" <er...@gmail.com> 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
Posted by Eric Redmond <er...@gmail.com>.
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 <Ma...@otpp.com> 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
>