Re: [m2] missing dependency features??
On 11/22/05, Chris Berry [EMAIL PROTECTED] wrote: 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. In this case, you'd need to create a POM, and we'd need to have some way for the POM to point at the resource outside of the repository. Is that what you are suggesting? 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. That's our experience too, which is why we gave the power of configuring it to the final POM in the form of an artifact filter fed to plugin configuration. This probably isn't documented well enough - I have noted it in JIRA as something needing attention. Basically this takes your suggestion: 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 pushes the configuration into the plugin configuration to avoid confusion. We also highly recommend using some sort of sensible default to minimise the amount of configuration - for example, the war plugin uses all compile/runtime but not test time or provided dependencies. That said, the war plugin doesn't allow you to filter the artifacts yet, and it should. I hope that clears it up, sorry for the delay in replying. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] missing dependency features??
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]
[m2] missing dependency features??
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). This is particularly important when one depends upon interface definitions -- particularly WSDLs -- which are typically available from some webserver which does not adhere to the maven style of URL. A client may wish to find these dependencies at the URL first, and leave open the possibility of finding the WSDL locally in a maven-style repo. Looking at the available dependency XML elements; systemPath is System-scope only, but something akin to it (say, path) might work. dependency groupIdorg.myorg.services/groupId artifactIdfoo/artifactId version1.0.0/version typewsdl/type pathhttp://foo.com/wslds/foo.wsdl/path properties transitive=false server.wsdltrue/server.wsdl war.bundletrue/war.bundle /properties /dependency 2) The ability to specify a dependency property (as in m1). For example, in my project must be able to specify that I want a WSDL dependency as either a client or a server. This is an application specific property, which is a good, legitimate use of properties. Others are war.bundle, etc. These properties may be used in all points of the lifecycle. In one case, server.wsdl is a compile-time property, in another war.bundle is a assembly-time property. It seems that these properties could be transitive -- so that, say, war.bundle will pertain to the declaring dependency and all of it's descendants (so that they all end up in the war.bundle). Or perhaps use an XML artifact to control whether it is transitive or not would be useful. I'm probably rehashing old history, but why were dependency properties removed in m2?? Thanks, -- Chris
Re: [m2] missing dependency features??
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. 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. HTH, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
