I use the same version across the board which reflects the version (including patchlevel) of the WebSphere distribution. I do not want to have to figure out which JARs have been updated for each corrective package I receive, so I blindly load them all from the distribution every time.
In my experience, vendors are not always very disciplined about including a proper manifest in their JARs that reflects the version number, so when I want to specify a version, I often resort to using the max date of the files timestamps in the jar, in the YYYYMMDD form. As per the dotted notation, it applies only to groupId, not artifactId. if your artifact is abc.def.ghi, in group com.somecorp, version 1.0, the jar in the repo will be at com/somecorp/abc.def.ghi/1.0/abc.def.ghi.jar I hope this helps. -Olivier On Wed, 2008-02-27 at 11:39 -0500, Brown, Carlton wrote: > Yes, we have a similar problem, not RAD but something like it. Your > solution below is more or less what I figure I'll have to do. It's a > variation on the other solutions mentioned, but it helps clear things up > for me. > > So if I'm reading below correctly, you're essentially ignoring the real > version of the artifact and mapping them all as version 6.3.9 (which is > presumably the version of RAD you're using)? > > If the virtual POM specifies a master version of (for example 6.3.9), I > guess one could install all the individual jars with their actual > version numbers (derived from the jar filename or manifest). It's just > a small additional effort if I've decided to throw in the towel and > script a mass install. > > Question: I notice that using dotted notation in groupId expands to a > directory structure during installation or deployment. Does this > behavior also hold for artifactId? > > -----Original Message----- > From: Olivier Dehon [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 26, 2008 9:48 PM > To: Maven Users List > Subject: Re: Best practice to represent an arbitrary collection of jars > asa single dependency? > > I had to resolve a similar issue when trying to compile RAD projects > with Maven. RAD comes with WebSphere runtime JARs in a specific > directory (which would be provided on the WebSphere server). By default, > RAD uses those runtime libraries without the need to specify the > dependency in the .classpath explicitly (RAD defines the concept of a > container for that purpose). > > To be able to build the RAD project with Maven, I uploaded all of the > runtime JARs as artifacts in my repository, and created a > "dependency-only" pom project that has all those dependencies. > > Then, to build the project with Maven, I simply have to add a dependency > on that pom project, and set it as provided scope to emulate in Maven > the RAD build environment. > > Once the project compiles ok, running "mvn dependency:analyze" helps > trimming down those provided dependencies to only the ones that are > actually needed. > > Uploading all jars from a directory to the repository is actually a very > easily scriptable task with a decent shell, if you are installing the > JARs with the same groupId and version for all of them. > > For example (untested, but you get the idea): > > for lib in *.jar; do > artifact=`basename $lib .jar` > mvn install:install-file \ > -DgroupId=com.somecorp -Dversion=6.3.9 \ > -DartifactId=$artifact \ > -Dpackaging=jar -Dfile=$lib > > echo "\<dependency\> > \<artifactId\>$artifact\</artifactId\> > \<groupId\>com.somecorp\</groupId\> > \<version\>6.3.9\</version\> > \</dependency\>" >> somecorp-meta.pom done > > Just edit somecorp-meta.pom after that to add header and footer and > install it with install:install-file also. > > I hope this helps. > > -Olivier > > On Tue, 2008-02-26 at 12:41 -0600, Wayne Fay wrote: > > This simply is not a feature that currently exists in Maven, and for a > > > lot of reasons, I don't see it being a feature that will be > > implemented any time soon. > > > > Your best bet is the "list all artifacts as dependencies in a pom, and > > > depend on it" option that I suggested earlier. This in combination > > with Archiva, Artifactory, Proximity etc would be the "right" solution > > > in my book. > > > > But, I don't think your projects actually need all 50 of those > > artifacts. So the best solution is to specify the proper dependencies > > explicitly in each project, and use a shared parent with a > > dependencyManagement section that helps you manage versions of > > artifacts. > > > > Wayne > > > > On 2/26/08, Brown, Carlton <[EMAIL PROTECTED]> wrote: > > > I want to take a single directory of ~50 jars and specify that as a > > > single dependency. > > > > > > I'm explicitly trying to avoid specifying them as 50 separate > > > dependencies in a pom file, or breaking them out in 50 different > > > module subdirectories under an internal Archiva repository. It > > > sounded to me as if this is what you were suggesting, quite a bit of > work. > > > > > > Perhaps I'm not wording the question correctly, as it seems like > > > this would be a very common situation. > > > > > > > -----Original Message----- > > > > From: Wayne Fay [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, February 26, 2008 11:49 AM > > > > To: Maven Users List > > > > Subject: Re: Best practice to represent an arbitrary collection of > > > jars as > > > > a single dependency? > > > > > > > > I guess we don't understand what you want/need, as it sounds a lot > > > > > like what we're suggesting. You can manage the artifacts > > > > themselves by using Archiva etc rather than asking Maven to > > > > download direct from the Internet. > > > > > > > > An alternative is to unzip each jar into a shared directory and > > > > then re-jar all of it. But I don't know if that would actually > > > > work due to log4j.xml collisions etc. > > > > > > > > Wayne > > > > > > > > On 2/26/08, Brown, Carlton <[EMAIL PROTECTED]> wrote: > > > > > These approaches both involve resolving each jar as an > > > > > individual separate dependency, a large amount of manual effort > > > > > for a couple of reasons. I'd have to specify 50 new > > > > > dependencies in the POM, and > > > then > > > > > I'd have to stage these artifacts separately in our internal > > > repository. > > > > > This jar collection is certified by our internal QA process, > > > although > > > > > some of them are probably sitting out on Maven central, we're > > > > > not > > > just > > > > > going to take whatever comes off a public repository without > > > certifying > > > > > it first. > > > > > > > > > > So basically what I'm needing to do is specify a single > > > > > dependency > > > that > > > > > is composed of 50-something arbitrary jars. I was able to do > > > > > this > > > in > > > > > Ivy, I figured Maven would likewise have a way to accomplish > > > > > this result. > > > > > > > > > > > -----Original Message----- > > > > > > From: Wayne Fay [mailto:[EMAIL PROTECTED] > > > > > > Sent: Tuesday, February 26, 2008 10:27 AM > > > > > > To: Maven Users List > > > > > > Subject: Re: Best practice to represent an arbitrary > > > > > > collection of > > > > > jars as > > > > > > a single dependency? > > > > > > > > > > > > Just make a project with type pom and specify these > dependencies. > > > > > > Then, depend on this project in your other projects, and it > > > > > > will > > > bring > > > > > > in those dependencies transitively. > > > > > > > > > > > > If you're certain about those versions, you can lock them down > > > with > > > > > > <version>[1.2.3]</version>. > > > > > > > > > > > > Wayne > > > > > > > > > > > > On 2/26/08, Brown, Carlton <[EMAIL PROTECTED]> > wrote: > > > > > > > Hi all, newb question here... > > > > > > > > > > > > > > Somewhere long ago, an internal dev project started > > > > > > > depending on > > > > > > > foo-corp/lib/**/* of a 3rd-party framework, which ends up > > > > > > > being > > > a > > > > > random > > > > > > > collection of 50 jars or so. What's the Maven best practice > > > > > > > > for representing a "big bag o' jars" as a single dependency? > > > > > > > > > > > > > > I know it would be ideal to resolve our dependency graph > > > > > > > with > > > > > greater > > > > > > > granularity, but until someone has copious free time to do > > > > > > > that, > > > > > we'd > > > > > > > need a simple interim solution to move us forward on the > > > > > > > Maven > > > > > track. > > > > > > > > > > > > > > Just to make it clear, the repository dir would look > > > > > > > something > > > like: > > > > > > > /foo-corp/bigbagofjars/5.7/ > > > > > > > > > > > > > > And it would contain a random selection of goodies such as: > > > > > > > apache-commons-codec_1.3.jar > > > > > > > apache-commons-discovery_1.1.jar > > > > > > > apache-commons-logging_1.1.jar axis-jaxrpc_1.1.jar > > > > > > > axis-saaj_1.1.jar axis-wsdl4j_1.1.jar axis_1.1.jar > > > > > > > bsh_1.3.0.jar jdom_b8.jar junit_3.8.1.jar ldapjdk_5.2.jar > > > > > > > log4j_1.2.8.jar oracle_9.2.0.5.jar xalan_2.6.0.jar > > > > > > > xerces-xml-apis_2.6.2.jar xerces_2.6.2.jar > > > > > > > xpp3_min-1.1.3.4.I.jar xstream-1.1.3.jar > > > > > > > > > > > > > > If I'm missing some obvious best practice, please feel free > > > > > > > to > > > point > > > > > it > > > > > > > out, this is just the best I've been able to come up with so > > > far. > > > > > > > > > > > > > > Thanks in advance... > > > > > > > > > > > > > > ----------------------------------------- > > > > > > > ==================================================== > > > > > > > This message contains PRIVILEGED and CONFIDENTIAL > > > > > > > information that is intended only for use by the named > > > > > > > recipient. If you are not the named recipient, any > > > > > > > disclosure, dissemination, or action based on the contents > > > > > > > of this message is prohibited. In such case please notify us > > > > > > > > and destroy and delete all copies of this transmission. > > > > > > > Thank you. > > > > > > > ==================================================== > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - > > > > > > > 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] > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - > > > > > 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] > > > > > > > > > -------------------------------------------------------------------- > > > - 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] > > > > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
