My $0.02 I don't think it's rude at all. It's a completely valid point, on the presumption that you're not held to being responsible deterministically reproducing the results of a given build. A co-worker of mine shares that same opinion and it's an oft-discussed issue with regard to our product due to the fact that the developers work inside Eclipse and therefore don't want to crank up the maven build every time they make a change. I don't blame them, but as the cat in change of producing the artifact that we'll give to a customer, I have to lay down ground rules to ensure my success. :)
One salient point is that if the contents of the jar change, then the version has already changed. This has occurred implicitly if you didn't give it a new name with a version. Since maven, as a build system, only understands versions as part of a filename, and since no filesystem that I'm aware of understands version lifecycling as a part of it's nature, you have to toss your build system a bone in order to get the results you expect. Maven generally produces versioned artifacts (even/especially SNAPSHOTS), precisely because a change of content denotes a change of version. What Brett was saying is that, in order for you to place your produced jars in a repo that maven would recognize, you'd need to attach some additional information (i.e. anything, like a made-up magic number or a date/time stamp). Otherwise, all artifacts of a given type in the repo would'nt just look the same to projects using them as dependencies. They would all actually BE the same. Frankly from my perspective, which is currently purely a build/deploy person, the forced versioning is practically essential. This sort of thing actually does happen quite often, for things like the dependecies from Sun which aren't versioned and can't be distributed by third parties. This includes a number of transaction, mail, and graphics packages, as well as anything you might have purchased but not be able to re-distribute outside of your licensed realm. For instance, I believe I internally redistribute the jta.jar from Sun as jta-20050121.jar because that's when I picked it up from them. I only distribute it within my dev group, after management accepted the licenses. If Sun makes a new one that's different, I'll rename it to some other jta-YYYYMMDD.jar name and store it in my local maven repo. The name certainly doesn't have to change, but then it's far less useful to a build system since the [content] library of dependencies in a maven project don't get versioned with the source code the way it might otherwise. For example: Case A: You have some non-maven java project, probably built with an ant script and not using a dependency repo. You'd normally have a lib tree somewhere in your source path, usually maintained in source code control along with the actual source. That would allow you to produce a tag that replicates your build. Your "version" is whatever the code and deps looked like as of the source code tag. When you extract a tag from the SCM, the jars come along with the tag and are, at that point, implicitly versioned because their contents are associated with a tag. vs. Case B: You have a maven project. The dependecies are managed in the POM. They exist outside source management of the project. You make a tag in your SCM system that's a version of that project. All your dependencies are noted by version in the POM. vs. Case C: You have a project with some sort of build system, probably ant, that uses a repository of dependencies that are not versioned. The source is tagged as a version, but refers to unversioned dependencies in a repository external to the source tree. If the contents of a dependency change, then you just copy the new jar on top of the old one in the repository and the build references that. The challenge: Given that cases A and B produce precisely the same output from a tag every time they're extracted, determine a manner in which case C produces replicatable (sp?) results of a build based on a tag. If the items in the repo change content across time but do not change name [ i.e. version], then any checkout of the source that uses XYZ.jar will always use the current XYZ.jar and therefore is likely to break if the contents of XYZ.jar don't conform to the source at the time of the tag. Among its myriad characteristics,a build system should produce predictably r eproducible results. Unversioned dependencies don't make that impossible, just highly improbable. On 4/21/05, Jamie Bisotti <[EMAIL PROTECTED]> wrote: > > >I find it hard to believe the JAR would never change, so some version > is appropriate :) > > Just because the contents of a JAR file change, the name does not have > too. My company, for whatever reason, chooses not to include any kind > of version info in the JAR's name. > > I don't mean this to sound rude, or come off like an ass, but... > > I'm semi-new to using Maven and I'm wondering if the wants/needs of > the users are being taken into consideration with regard to Maven2. > Are you/we trying to come up with the best tool the fit users needs, > or just come up with a tool that meets our ideas of what a users needs > should be? Then, telling users they need to change the way they are > currently doing things because they aren't following our contrived > "best practice". > > Jamie > > > On 4/21/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 4/22/05, Ilyevsky, Leonid (Equity Trading) <[EMAIL PROTECTED]> > wrote: > > > It seems that if third party jar file name does not comply with maven > > > naming convention, the only way is to rename it. > > > The <dependency> element always requires version number, and the <jar> > > > tag (supposed to take explicit file name) does not do anything. > > > Is this a feature? I just want to know. > > > It might be OK to rename files and make up a version number even if > the > > > vendor does not care about version. But then we are going back to > > > non-standardized environment where, let say, tibrvj.jar from Tibco is > > > not named tibrvj.jar and it is not clear in what directory it should > be. > > > -------------------------------------------------------- > > > > > > > Yes this is by design - the new Maven layout requires a version in the > > directory tree, so it has to have something. > > > > I find it hard to believe the JAR would never change, so some version > > is appropriate :) > > > > eg, tibco-CVS-20050312.jar, or tibco-internal-1.jar, or > > tibco-unversioned.jar would all work. Using some date like "20050304" > > as the version is probably a good idea. > > > > Cheers, > > Brett > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > Jamie Bisotti > Software Engineer > Lexmark International, Inc. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
