Inline. Thanks, -- Chris On 11/20/05, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 11/21/05, Chris Berry <[EMAIL PROTECTED]> wrote: > > Greetings, > > Seems that dependencies should provide two features they do not already; > > > > 1) the ability to explicitly specify the URL from which to download an > > artifact (in m1, if I recall, this was handled by the <jar> element). > > Actually, not quite - the JAR element just let you change the > filename, not the repository. > > This isn't really an artifact as it will have no other meta > information (no versioning, no POM, no checksum). > > What is the use case for having this as a dependency? I can think of 2: > - use from a plugin: in which case, passing the URL to the plugin > directly and having it manage it seems the best alternative > - copied into a webapp/jar/etc: I think this might fit better with a > external resources specification we have discussed on the dev list and > will consider for 2.1. In the mean time, it will require a custom > plugin to download and copy it, or that you manually put it in the > repository and look after the versioning. >
My need is for WSDL file dependencies. If I am building, say, a web service which makes use of other web services, then I need only the WSDL of those web services -- then from it I create the necessary interface code using a code generator (Axis' WSDL2Java). This is a true dependency and should be treated as such. I do not think this should be treated as a external resource when it is truly a dependency. Often WSDLs are published onto some web server somewhere, say, http://svcdefs.myco.com/wsdls/foo.wsdl. There is still no clear way to version WSDLs. Yes, I could copy the WSDL to a maven-style repo. But this violates "Don't repeat yourself". So I want to be able to declare a dependency and to also specify a URL from which to grab the file. > I'm probably rehashing old history, but why were dependency properties > > removed in m2?? > > Well, its our fault for not putting together a FAQ - but you should > find plenty of answers in the mail list archives. I'll put a FAQ > together :) > > They were removed because they aren't reliable in a transitive > environment. It implies that the dependency knows something about the > environment of the dependee, which is back to front. In most cases, > granted, the value for war bundle will be the same for a particular > dependency - but that relies on the dependency specifying it. > > In the end, we give control to the actual POM doing the building, > trying to use sensible defaults that minimise what needs to be > specified, and allowing the use of artifact filters in the > configuration of plugins. In my experiece, these properties are application specific and are typically related to the build for the project at hand. And for larger organizations with build systems there is often a uniformity in these properties for all internal projects. What the properties mean in a transitive sense is really up to the project at hand, and thus, it should be "switchable" behavior. I'll give two concrete examples; 1) I need to speficy which WSDL dependency is my "server" dependency vs. which are "client" dependencies because the server dependency is processed differently in WSDL2Java than are the client WSDLs. This is an application specific property. It is not transient. Of course, I could lay in a m2 property -- but this would require that I get things from 2 places. I would far prefer getting a set of WSDL dependencies and then be able to query these dependencies for which are server vs. client. IMO, this is closer to the spirit of what is really happening. 2) I need to proclaim which dependencies are to go into the webapp's /lib ( i.e. war.bundle) This may or may not be transitive, although most likely it is. I.e. put this dependency and all of it's child dependencies into the war bundle. Alternately, we have a base level "service engine" which has a shared /lib, so many dependencies end up in the shared /lib and not in the war.bundle. Thus, I depend upon the service-engine which has a application specific property; "service.engine" which I use to process these dependencies differently. I wonder if the answer to this dilemma is to only allow properties at the base project level, and to ignore them at the child levels?? But make no mistake, these properties are important, and removing this capability is a real issue for those us trying to transition from m1 to m2. HTH, > Brett > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
