You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Chris Berry <ch...@gmail.com> on 2005/11/20 15:19:52 UTC
[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>
<groupId>org.myorg.services</groupId>
<artifactId>foo</artifactId>
<version>1.0.0</version>
<type>wsdl</type>
<path>http://foo.com/wslds/foo.wsdl</path>
<properties transitive="false" >
<server.wsdl>true</server.wsdl>
<war.bundle>true</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??
Posted by Brett Porter <br...@gmail.com>.
On 11/22/05, Chris Berry <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] missing dependency features??
Posted by Chris Berry <ch...@gmail.com>.
Inline.
Thanks,
-- Chris
On 11/20/05, Brett Porter <br...@gmail.com> wrote:
>
> On 11/21/05, Chris Berry <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] missing dependency features??
Posted by Brett Porter <br...@gmail.com>.
On 11/21/05, Chris Berry <ch...@gmail.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org