Re: Maven2: dependencies with non-conformant file names.
On Thu, 21 Apr 2005, Mykel Alvis wrote: Total now $0.04: I totally agree, but since Maven 2 already uses directories with the version in it's name, it should be possible to store the jar itself without a version in it's name. The path to the jar already has it's version in it, so you can still differentiate between versions (but not snapshots..) Ha! Should've waited until Shakiyama Porter had his say. Could've saved myself some typing. :) -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
On 4/22/05, Kenney Westerhof [EMAIL PROTECTED] wrote: On Thu, 21 Apr 2005, Mykel Alvis wrote: Total now $0.04: I totally agree, but since Maven 2 already uses directories with the version in it's name, it should be possible to store the jar itself without a version in it's name. The path to the jar already has it's version in it, so you can still differentiate between versions (but not snapshots..) Hmmm... The same argument could be made for removing the artifactID - so maybe it should be /artifactId/version/.jar :)) You're right, but then you have an inconsistency between how snapshots and others look, and if you were to download it over the web, you lose that version information in the filename. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven2: dependencies with non-conformant file names.
Just chiming in for the first time since I started using Maven 1 (Other than asking new user questions). I have had a love/hate relationship with Maven ever since I started using it on a large project integrating the output of 4 different development groups. One of the things that has constantly frustrated is the way the enforcement of best practices interferes with the integration with tools that don't follow those best practices or interferes with the integration of existing Corporate best practices differing from Maven's own. Maven 2 already appears to have switched things over so that Maven's best practices are the easiest route to go, but not the only one. So when I deal with a tool that mandates that Jar names not contain a '-' I can make it all work. It looks like you have beaten the adages about 2.0 rewrites. Congratulations and thank you! Jim Mochel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven2: dependencies with non-conformant file names.
I am glad I started this discussion. I believe it is very useful for many developers. I totally agree with arguments for using versions; I like the structure and discipline, and I agree that it will reduce the number of errors. Software vendors like Tibco and Oracle may reconsider their artifact names when more developers use maven2. They may even use maven2 themselves and store their artifacts in accessible repositories. For now, I will just rename those few files, no big deal. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Sunday, April 24, 2005 5:50 AM To: Maven Users List Subject: Re: Maven2: dependencies with non-conformant file names. On Fri, 2005-04-22 at 09:36 +0200, Kenney Westerhof wrote: On Thu, 21 Apr 2005, Mykel Alvis wrote: Total now $0.04: I totally agree, but since Maven 2 already uses directories with the version in it's name, it should be possible to store the jar itself without a version in it's name. The path to the jar already has it's version in it, so you can still differentiate between versions (but not snapshots..) Here's my take on it: http://blogs.codehaus.org/projects/maven/archives/001052_why_maven_uses_ jar_names_with_versions.html -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 22, 2005, at 12:19, Mykel Alvis wrote: If the manner of accessing the repository were abstracted, one might be able to write a repository manager that would retrieve dependencies arbitrarily from a service rather than from the filesystem. For instance, someone could write a manager that, when supplied with a particular dependency, went and retrieved that dependency from a blob in a database, and was therefore referenced by an id rather than a filename. Not that the two things are different, mind you. You still have to provide some indicator for versioning as part of the id. However, based on the property service that I think we're going to work on internally here at my company, I can see a dependency service that works in a similar fashion. I don't think there's anything standing in the way of that now. Such a repository manager would simply have to speak HTTP. For instance, you define your local repository as being at the URL http://www.example.com/cgi-bin/repository. The repository script/executable receives the rest of the URL (for instance, /commons-collections/jars/commons-collections-3.1.jar) as extra path info, and can parse it or split it up or whatever and use that information to retrieve or generate the dependency as needed. I would think the biggest concern with generating dependencies on the fly would be keeping the HTTP connection from timing out. Interesting idea, though. - -- Craig S. Cottingham [EMAIL PROTECTED] OpenPGP key available from: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7977F79C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCaThTEJLQ3Hl395wRAsX6AJsF77NG6S9BX5mbWCZTmQhLnaHMgwCgrANz hebGSf/XE7xR/YIBnR2n32I= =6Px8 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Craig S.Cottingham wrote: On Apr 22, 2005, at 12:19, Mykel Alvis wrote: If the manner of accessing the repository were abstracted, one might be able to write a repository manager that would retrieve dependencies arbitrarily from a service rather than from the filesystem. For instance, someone could write a manager that, when supplied with a particular dependency, went and retrieved that dependency from a blob in a database, and was therefore referenced by an id rather than a filename. Not that the two things are different, mind you. You still have to provide some indicator for versioning as part of the id. However, based on the property service that I think we're going to work on internally here at my company, I can see a dependency service that works in a similar fashion. I don't think there's anything standing in the way of that now. Such a repository manager would simply have to speak HTTP. In maven2, we use RepositoryLayout's and Wagon's to accomplish artifact and metadata resolution against some ArtifactRepository. There is nothing (from an API perspective) standing in the way of using any implementation of any of these: * RepositoryLayout: Simply returns a formatted access path for a given artifact. This has some conceptual ties to a filesystem, but those definitely could be worked with to implement a DB-based repo, for instance. * Wagon: These are the workers of the resolution world. You could implement a Wagon to retrieve an artifact from a DB, where the ArtifactRepository might contain a URL to connect to the db, and the RepositoryLayout implementation might represent a way of contstructing either query params or a fully-formed SQL query...then the wagon executes, and retrieves the artifact to a file on localhost. Again, in the API this is already possible. HOWEVER ;), there is currently a partial implementation of Wagon accessibility in Maven2 alpha-1, in that it expects to use HTTP. We haven't made that part configurable yet, I don't think. But it's coming... - -john -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCaT8aK3h2CZwO/4URAhCYAJsEeD2c7VgDhwyED2A6lZes3xsGDwCgpSXD knqyz2RLUDoHbVRWLX2eqJE= =5XG1 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'll add my $0.02: http://blogs.codehaus.org/people/jdcasey/archives/001053_dependencies_to_version_or_not_to_version.html Cheers, - -john Jason van Zyl wrote: On Fri, 2005-04-22 at 09:36 +0200, Kenney Westerhof wrote: On Thu, 21 Apr 2005, Mykel Alvis wrote: Total now $0.04: I totally agree, but since Maven 2 already uses directories with the version in it's name, it should be possible to store the jar itself without a version in it's name. The path to the jar already has it's version in it, so you can still differentiate between versions (but not snapshots..) Here's my take on it: http://blogs.codehaus.org/projects/maven/archives/001052_why_maven_uses_jar_names_with_versions.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCaSa1K3h2CZwO/4URAvXNAKCcqaDKFFbXQMI1CpOIE3muiR8zdgCfRxNg HmLrtnEgcRsyy37U0Ndvz3E= =xp5B -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
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]
Re: Maven2: dependencies with non-conformant file names.
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]
Re: Maven2: dependencies with non-conformant file names.
On 4/22/05, Jamie Bisotti [EMAIL PROTECTED] wrote: 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... No, it's a valid question. But it has been answered before, so you might get a more thorough answer from the archives. 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. Yes, definitely. This isn't just a matter of best practice - the Maven repository is it's storage area - as long as it doesn't impose filenames on the artifacts in your resulting build, I don't see how this is causing anyone any inconvenience. Dependencies simply won't work if you store it without a version in the remote repository without a version. Consider: A project depends on unversioned-artifact.jar. now a new one is released, and I assume you want to drop it into the repository and the project starts using it. What's broken? 1) anyone with it already downloaded won't get the update 2) if you try to build the old version of the project from source control, it may no longer work This is aside from the problem of never knowing which is which when you have 3 of those lying around that are all different. You should differentiate between wants/needs above. I cannot recall a time that Maven didn't allow someone to do something they needed to do. Quite often someone wants to do it differently (Very often just for the sake of it!), but I've never seen it as a need. Honestly, tools like Ant are better suited if you feel you want to do everything a specific way, because Maven's main draw is that it gives you some consistency (where it is applied, and a lot of Maven 1.x has gone down more of the unnecessary flexibility path). You should be able to pick up a new project without learning how to build it again. Hope this helps. Please let me know if you feel this there are instances where this isn't applied. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2: dependencies with non-conformant file names.
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-MMDD.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
Re: Maven2: dependencies with non-conformant file names.
Ha! Should've waited until Shakiyama Porter had his say. Could've saved myself some typing. :)
