You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Vic <tv...@mail.ru> on 2008/08/04 10:02:09 UTC

Re[2]: Maven gurus, may be I do not understand something ...

It works, but we have to support it and now we just would like to measure costs of migration to maven. 
So it would be nice if you can explain me how we could map our developement process to maven.
Thanks
 
> If it is not broken, don't fix it!
> 
> What you have sounds like it works for you.... and solves the problems you
> have encountered.
> 
> If you have a working dependency management system that does not have any
> problems... leave it working.
> 
> If, however, you have problems, then Maven could well have the answer for
> you.
> 
> Just my  0.02
> 
> -Stephen
> 
> On Fri, Aug 1, 2008 at 2:26 PM, Vic <tv...@mail.ru> wrote:
> 
> > We have our own dependency management system (DMS) integrated in our own
> > build server. Yes, our own, it was developed about 3-4 years ago (in this
> > time we did not find anything acceptable) and it works fine, but we would
> > like to use maven and I spent about a week on research. Unfortunately it I
> > did not understand how could we apply maven. I will try to describe some
> > phases in our development process and I hope somebody maps our process to
> > maven.
> > Now we have about 150+ components/modules in our repository and may be the
> > same number of third party libraries, so you can imaging - it is really big
> > 1. Developer sends request to integration team about new module.
> > Integration team create place in CVS repository and append new module into
> > repository (it is just a description/metainformation, no jars or something
> > else)
> > 2. Developer implements some functionality in module creates buidl.xml for
> > module. Build.xml has standard tags such as clean, init, compile, test
> > ...... By the way if you produce just a simple jar file you can reduce
> > buidl.xml significantly with usage of Ant import task. Also developer
> > describes dependency in special file. Our DMS supports transitive
> > dependencies and do not allow cyclic dependencies.
> > 3. Developers build and test developed functionality. For builds they use a
> > snapshot of repository based on some integration build. Every integration
> > builds places compiled modules in special folder and this folder can be used
> > locally by every developer.
> > 4. Developer commits source code to CVS and creates a tag. Created tag is
> > described what was done, implemented, fixed etc.
> > 5. Integration team integrates new tags into release build. They use
> > previous build as a pattern and just change version of integrated
> > components. Finally DMS creates big ant file (automatically) and starts
> > build process. DMS looks at repository from previous build (since it is used
> > as a parent) and rebuilds new modules or uses jars for unchanged ones
> > Of course there are a lot of other features but if about dependency
> > management - that is all.
> > I have spent about a week on research, but it looks like maven has another
> > ideology. It is oriented on jars placed into repository and if there is no
> > such artifact it is not able to resolve dependencies. May be I am wrong but
> > I would like to use the same strategy as we use now but I do not understand
> > how.
> > Thanks
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org