Hi Martin, Perhaps it's a dumb idea, but why not create the jumbo jar and then as a separate step split it apart into separate jars by filtering on package names? It seems to me that the multiple jar files is more of a deployment issue then anything else. It might be possible to use tools like rsync to send deltas of the jumbo jar file eliminating the need to split it up. If not rsync there are commercial tools that might do this (Marimba). This makes dependency issues simpler.
Regards, C. Helck -----Original Message----- From: martin_CY [mailto:[EMAIL PROTECTED] Sent: Thursday, June 28, 2007 9:36 AM To: users@maven.apache.org Subject: migrating to Maven2, but some issues. Hi, I've been put in charge of investigating the possibilities to migrate to Maven 2 for my company. we have been using ant up until now and it has worked pretty well, except that about a year ago we started to make part of our java application functionality available on the net using Tapestry. (which is very cool btw) and now that Tapestry has moved to maven we feel we need to do it as well, and beside the 31 jars we got in our lib/ is not all that fun to keep track of. During the last 3 days I've been reading and messing around with Maven trying to get it to work with our current source structure, but I'm more or less about to give up. reason is that some 3 years ago our main application was deemed too big to be distributed on its own (at the time around 6-7 megs) and was split into multiple jars for easy distribution and frequent patching, as the application is provided through java web start across the whole world (offices in San Fransisco, London, Tokyo, Hong Kong) and multiple of the users working from home all over the world. So patching a 6-7 meg jar every week or two was not any option any more and it was decided to split up into 7 jars. if something needs to be patched just one of the smaller jars could be sent out. These 7 jars are very interlinked, its circular dependencies all over, since really it is just one big application that is split into smaller pieces (currently its around 14 megs in total, so making it into one jar is just not possible due to the bandwidth required, and with around 2000 .java files its no small task to make the 7 jars into individual modules independent enough to not have any circular dependencies. As i said before, currently we are using an ant script with includes and excludes, but since it has the whole source three in its path while building the jars that work fine. I just wonder how I should proceed. Because we really don't like dealing with all the jars in the lib/ !! and also having the main application's jars versioned and in an internal repository would make life a lot easier for the web/Tapestry project to handle its dependencies on the main project. I know the "correct" thing to do is to make it into proper modules, but that is probably at least 1 month work for 2-3 people, and well hard to sell to management.. and since we already got a work Ant script, spending that much time to reorganize for maven using Ant + Ivy might be suggested as an alternative. from my googling, some alternatives did come up.. e.g. using maven for just handling all the dependencies, and using ant for the actually building.. any advice would be appreciated. regards Martin -- View this message in context: http://www.nabble.com/migrating-to-Maven2%2C-but-some-issues.-tf3994413s 177.html#a11343187 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ********************************************************************** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the "Information") is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates ("ICAP") or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
