Hi Stefan, I have not used it by myself, but that SHOULD be possible using different main projects for different customers.
In fact, you should be able to do something like this : - You will have a "main" artifact for your project, the root of your dependency tree. - The you will have a number of dependencies resolved transitively, creating the tree - One leaf node of the tree has to use a different version (build/branch) for customerA and customerB, while all other customers will go with the "default" one. - Create a new pom project for customerA - This project will have only one dependency on the main artifact of your project - There is way to specify that you want a certain version of a sub-dependency, so to say that you want the -customerA version of that leaf node. Then, building this pom project, will assemble the the product with a different jar for that specific leaf dependency. Unfortunately, there are a number of things that will make this more or less easy to do. As I said, I've not used this, so I'm talking theoretically. For example, if you project is a WAR file, then probably simply creating a pom project having the real WAR packaged project as a dependency could not work, cause the war would be taken already packaged and (at least last time i investigated it) JAR replace inside a WAR dependency was not used. Anyway, except for projects with special packaging/assembly, this way could be a way to do what you're talking about. Hope this helps, Simone Stefan Fritz wrote: > Hi Simone, > > Thanks a lot haven't thought about ranges for this but now it seems to > be the obvious solution :-) > I still might have a challenge when I have multiple branches of one > artifact (e.g. 1.0-patch-customer1, 1.0-patch-customer2) but in all > the other cases it should solve my problem. > > Regards > Stefan > > Simone Gianni wrote: >> Hi Stefan, >> I don't know if I got the problem right and if this could be a solution, >> but I do as follows (obviously, we are talking about "maven branching", >> not SVN or CVS branching, which is another story) : >> - setup a developers only maven repository >> - setup a production only maven repository >> - use range versions instead of fixed ones >> .. This means that instead of having a dependency on artifact >> com.yourcompany:artifact:1.0.0 you have a dependency on >> com.yourcompany:artifact any version > 1.0.0 >> - when a subproject is buggy, a team (or single developer, or whatever) >> will start working on it >> - they will build it on their own computers (in their local repository), >> so no problem with them testing their own work >> - they will occasionally deploy it TO THE DEV ONLY repository >> .. deploying it there, will let the other teams use the new artifact and >> test that their own work is correct related to the new >> bugfixes/refactorings and so on >> .. obviously, when they deploy, they should increment the minor >> version/revision, but only on that project specific pom (for example >> 1.0.0-r1 1.0.0-r2 or 1.0.1 1.0.2 etc...) >> - when the bugs have been fixed, the deploy can be made on the >> production only maven repository >> - from there, a complete build and test of the application can be done, >> and final release (war, jars or whatever) created to send to customers >> >> This way, every project can have its own "lifecycle", its own releases, >> and probably its own SVN branches and so on. While using fixed version >> dependencies is a good practice when linking to something outside your >> control (artifacts on the main repo), for internal dependencies >> (artifacts produced inside your company/team) it is a maintenance >> nightmare and most of the time useless, cause you know when a new >> version will break compatibility and can adjust versioning only when >> that happens. >> >> Using SNAPSHOTS can save a bit of time making the "change the version >> when sending to other developers" step not necessary, but I think that >> it should be avoided when there is a high number of developers : that >> step can potentially break the build and stop other developers' work if >> the new package breaks compatibility when it should not or introduces >> more bugs than the previous one (which obviously happens :) ), and >> having also these "internal" releases versioned is IMHO more time-saving >> than using automagic snapshot updates. >> >> Hope this helps, >> Simone >> >> >> Stefan Fritz wrote: >> >>> Hi, >>> >>> We use Maven in an environment where we have ca. 150 projects. >>> One project is the toplevel project (= the final deliverable to the >>> customer/user). >>> This project has dependencies to 10 projects, which have dependencies >>> to other projects etc. In the end we have 150 different projects in >>> the dependency hierachy. >>> >>> The challange now is what happens if in one of the projects on the >>> lowest level is bug. >>> This means we have to branch from our released version to work on a >>> patch and then release the patched version. >>> >>> From my understanding the only way to do that is to branch all >>> projects which depend on the "buggy" project. And the same has to be >>> done for all levels up to toplevel project. >>> Most low level components are referenced by multiple projects and >>> therefore a patch-branch would afect ca. 30 projects :-( >>> As you can imagine this can end up in a nightmare of manual steps >>> and/or scripting. >>> Therefore I hope anybody has a better approach to that. >>> >>> Is there a simple way to do that? >>> Any automation in Maven? >>> Any best practices? >>> >>> Thanks >>> Stefan >>> >>> >>> --------------------------------------------------------------------- >>> 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] > -- Simone Gianni CEO Semeru s.r.l. Apache Committer MALE human being programming a computer http://www.simonegianni.it/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
