> -----Original Message----- > From: Jörg Schaible [mailto:[EMAIL PROTECTED] > Sent: Friday, December 17, 2004 9:07 AM > To: Maven Users List > Subject: RE: changing version of module and dependent modules > > > Maczka Michal wrote on Thursday, December 16, 2004 1:58 PM: > > > I've trying to find a nice solution for that issue since a > > long time (sometimes I have up to 40 projects using the same > > artifacts!). I come into the conclusion that any way of using > > version pointers in poms (e.g. xml entities or jar > > overriding) is bad thing as it might be against the > > repreductability of builds (unless modified poms with > > "inlined" information are deployed to the repository, but > > this creates other problems!!) > > Only thing which can really solve that complexivity is a tool > > (GUI), which will help to make a quick migration to the given > > version of the given artifact for group of projects. My > > colleagues from work have developed the maven plugin which > > helps to do this migration - it is already quite useful for > > them, but not fully operational and it requires other our > > plugins therefore it will be useless for somebody else, but > > it is not hard to write your own plugin with similar > functionality... > > Sorry, but I really want to know, how to do this in a company > with a lot of multiprojects. We're using entities heavily and > keep all our project in this way in sync (yes, all the > project share the same entity definitions, although the > versions can be overridden locally and individually). Nobody > has all projects checked out. In such a scenario neither a > GUI tool nor a plugin does help. >
I am pretty sure GUI will help here. One of things which is possible with maven is a database of all your projects. Together with continuus integration system it will enable a lot of really cool and fascinating things. For example once you will make a point release of a module - continous integration system can build and test all modules which were using older version of that module agaist this new release. You will be able to see a report which of them worked, what was the impact on performance and for example recieve a proposition to upgrade some/all of them to this new version. You won't be required to directly work with scm systems or even touch xml files or files with entities. This is of course just hypotetical scenario - but I am pretty sure that the level abstraction of project, xml files, entities is too low to deal with such complex problems. We really need tools which will aggregate that rich knowlege which sits in poms to do interesting things and save hours of our time! > How do we ensure reproducability? The entities are also kept > in a CVS repository and every time a project is tagged, the > repo with the entities is tagged also. > > If you really drop entitity support completely, this will be > a desaster for our company. > We understand that problem. If we will deprecate entities or stop supporting them we will need to propose working replacement. At the moment jar overriding facility is the only alternative which we have. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
