Re: build time vs. runtime dependency
Brett Porter wrote:
While this would work, it doesn't address all the cases from the
original email, and even for tests I don't think it is the right
solution. You want your tests built and run alongside you main code, not
left to be run when you think to do it separately. For me, integrated
unit tests is one of the biggest plusses for Maven.
Depenedencies have a "type" attribute in the POM, but I don't think that
it is used at the moment... ideally plugins could set up a separate
classpath when, for example, type == 'test' || type == null. Builds
could use type == 'compile' || type == null.
The type property of Dependency is documented as 'dependency type such
as "compile" or "test"' as you suggest, but if you look where its used,
you'll see its actually the file extension. I think in this case the
documentation on get/setType is wrong.
(from Dependency.java)
public String getArtifact()
{
// If the jar name has been explicty set then use that. This
// is when the element is explicity used in the POM.
if ( jar != null)
{
return jar;
}
return getArtifactId() + "-" + getVersion() + "." + getType();
}
(returns eg, foo-SNAPSHOT.jar, bar-1.0.ear)
(from AbstractArtifact.java)
/** @see Artifact#generatePath */
public String generatePath()
{
return ps + getDependency().getArtifactDirectory()
+ ps + getDependency().getType() + "s"
+ ps + getDependency().getArtifact();
}
returns eg /foo/jars/foo-SNAPSHOT.jar, /bar/ears/bar-SNAPSHOT.ear . NB
this use of directory names other than 'jars' is inconsistent with some
of the plugins - this is a bug in the plugins. The bug occurs anywhere a
plugin loops over project.dependencies, instead of looping over
project.artifacts - you can always get dependency information by doing
'${artifact.dependency}', but if you only have a dependency you can only
guess at its path. I should really submit a patch on this stuff - I
looked at it last week after a thread on maven-dev about the repo design.
I'm not sure - what else is type used for at the moment? I noticed it
renaming JARs sometimes, so I took it out...
- Brett
[EMAIL PROTECTED] wrote:
Charles,
Hi, in Maven, we have only one way of specifying
dependency. In some cases, a project may have
different dependencies at runtime and at compile time.
I can think of two examples:
Naive thinking: manage the test sources in a separate project! This
project
depends on the production code and on additional required
dependencies. Your
production code could depend on the API's of another package, while your
test project adds to that a specific implementation of these API's to run
the tests.
I didn't try this myself, so if you give this a try, pleas post your
results.
Ringo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: build time vs. runtime dependency
> Depenedencies have a "type" attribute in the POM, but I don't think that > it is used at the moment... ideally plugins could set up a separate > classpath when, for example, type == 'test' || type == null. Builds > could use type == 'compile' || type == null. > > I'm not sure - what else is type used for at the moment? I noticed it > renaming JARs sometimes, so I took it out... AFAIK, the type attribute determines the name of the subdirectory in the remote repo (with an 's' appended) where the artifact is stored. So a jar dependency, the default type, is obtained from the jars subdir. A pom dependency is obtained from the poms subdir, etc. Also, the type is used as the default extension of the artifact. Maven verifies and downloads all dependency types, but jars are treated special because they are added to the maven.dependency.classpath. Conversely, you pass the type attribute, with the 's' appended, to the deploy:artifact tag to specify the subdir on the central repo to deploy to. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build time vs. runtime dependency
While this would work, it doesn't address all the cases from the original email, and even for tests I don't think it is the right solution. You want your tests built and run alongside you main code, not left to be run when you think to do it separately. For me, integrated unit tests is one of the biggest plusses for Maven. Depenedencies have a "type" attribute in the POM, but I don't think that it is used at the moment... ideally plugins could set up a separate classpath when, for example, type == 'test' || type == null. Builds could use type == 'compile' || type == null. I'm not sure - what else is type used for at the moment? I noticed it renaming JARs sometimes, so I took it out... - Brett [EMAIL PROTECTED] wrote: Charles, Hi, in Maven, we have only one way of specifying dependency. In some cases, a project may have different dependencies at runtime and at compile time. I can think of two examples: Naive thinking: manage the test sources in a separate project! This project depends on the production code and on additional required dependencies. Your production code could depend on the API's of another package, while your test project adds to that a specific implementation of these API's to run the tests. I didn't try this myself, so if you give this a try, pleas post your results. Ringo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Web Developer f2 network ~ everything essential 02 8596 4437 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: build time vs. runtime dependency
Charles, > Hi, in Maven, we have only one way of specifying > dependency. In some cases, a project may have > different dependencies at runtime and at compile time. > I can think of two examples: Naive thinking: manage the test sources in a separate project! This project depends on the production code and on additional required dependencies. Your production code could depend on the API's of another package, while your test project adds to that a specific implementation of these API's to run the tests. I didn't try this myself, so if you give this a try, pleas post your results. Ringo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: build time vs. runtime dependency
Hi, FWIW, we faced a similar problem related to our unit tests. We have dependencies on a large test framework built ontop of jUnit that we want included in the test compilation and runtime path, but omitted from the normal classpath. We hacked this by putting these additional dependencies into a separate pom that we have standardized called project-tests.xml. Our custom plugin then registers test pre and post goals that read this pom and add/remove it from Maven's classpath. Here is an example: I worked this out the hard way because it was one of our first needs when we started migrating to Maven. Personally, I wish there was an easier and more general-purpose way to segregate and group dependencies and also have control over when they are verified. It is also getting to the point where we are considering writing our own DependencyVerifier subclass so that we can have a range of snapshot-like dependencies with finer grained control over how each type is resolved. -- David Zeleznik ILOG - Changing the rules of business mailto:[EMAIL PROTECTED] http://www.ilog.com -- > -Original Message- > From: Charles Chan [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 13, 2003 9:30 AM > To: maven-user > Subject: build time vs. runtime dependency > > > Hi, in Maven, we have only one way of specifying > dependency. In some cases, a project may have > different dependencies at runtime and at compile time. > I can think of two examples: > > 1. A project that uses a dependent library that > guarantees backward API compatibility. The project may > not want to use any new API but they want to run > against any improved code. > > 2. A dependency library can be split into an API > portion and an implementation portion. To prevent > anyone from using the implementation portion, one may > NOT want to have any implementation class in the > compile classpath. > > Do you think they are valid scenarios? How would Maven > deal with them? > > Charles > > > __ > Do you Yahoo!? > Yahoo! Web Hosting - establish your business online > http://webhosting.yahoo.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build time vs. runtime dependency
Hi, in Maven, we have only one way of specifying dependency. In some cases, a project may have different dependencies at runtime and at compile time. I can think of two examples: 1. A project that uses a dependent library that guarantees backward API compatibility. The project may not want to use any new API but they want to run against any improved code. 2. A dependency library can be split into an API portion and an implementation portion. To prevent anyone from using the implementation portion, one may NOT want to have any implementation class in the compile classpath. Do you think they are valid scenarios? How would Maven deal with them? Charles __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
