Hi Dave, Sounds like a slightly tricky deployment issue... With the few applets we have we use progaurd to pack our code and all libraries into a single jar that can then be referenced in the applet tag. The name of this jar never needs to change even if it has different versions of the artifacts inside it. You project may become ivy.xml + progaurd conf = applet.jar
The other advantage of proguard for us was a huge reduction in the size of the download for the client. If your are progaurding jars then you have to unpack them first for some reason. If you choose to go this way get in touch if you'd like to see our ant tasks. Their web site is a little squiffy at the mo but here is a link to the manual http://proguard.sourceforge.net/manual/introduction.html The other option seems to be to have the projects that have applet tags etc have an ivy.xml that gives full dependency specification with version numbers. When you build and deploy (which may be no more thean get pages and jars into the correct place) the resolve for this project could fetch the jars from a repo and rename them to remove the version number as part of the ivy resolve. As a general comment - when we rename jars, or build our own, to not have version numbers as part of the name we're very careful to make sure the manifest has the versions in it incase we need to identify them later... Cheers, Geoff On Sat, Aug 22, 2009 at 4:09 AM, Dave Brosius<[email protected]> wrote: > Greetings, > > I work on a big legacy ant project that has jars checked in to source > control. I am investigating what it would take to stop doing that, and > looking at ivy. The switch over to use ivy seems pretty trivial, although > perhaps time consuming given the size of the project. But here's a question > that hopefully others have thought about - resolved. > > We have more than a few <applet tag>/<jnlp>'s etc that reference jar files > by name. In the past we just checked in jar files without version numbers so > for instance, we had commons-lang.jar, and when a new version came out, we > just updated this jar in source control, again, by stripping the version > number from the jar file name. > > Now when moving to maven or ivy, this seems more problematic. Perhaps i'm not > seeing the correct solution, but ivy uses version number'ed names as gotten > from the repo, and so anytime we want to upgrade our jar versions, we've got > to go looking for all the references to them in <archive> tags, or jnlp > files, or who knows where else. The chances are high that we will forget to > update references some where. > > What is the preferred solution for this? I really don't want to have to do > that any time we upgrade jar files. > > >
