Re: private jar dependencies
I have now. http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-518
[EMAIL PROTECTED] wrote:
Has anyone raised this in Jira?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Brian Ewins <[EMAIL PROTECTED]> wrote on 24/06/2003
01:17:09 AM:
Michal Maczka wrote:
[...]
(or something like that) - jelly should always use artifacts, not
dependencies, to construct paths. It doesnt stop you naming jars
whatever you like, if they are in the local repo. I had a look over
the
broken plugins a while back and I think there was only one case where
it
wasnt clear that the use of dependency was a bug.
Just to make myself more clear.
I wanted to say that in the most of the cases plugins don't need to
know
nothing about existence of local repository. They just can operateon
set of
file with absolute path. I think that such assumption (or rather lack
of any
assumptions) can result in simpler code.
I think we are in violent agreement...
So I simply don't agree with statement: "jelly should always use
artifacts,
not dependencies, to construct paths".
But yet you say "Plugin are supposed to work with artifacts" in the
other post, which is basically what I am saying too.
dependencies don't know anything about their paths, and most of the
plugins[1] were guessing how to reconstruct the path to the artifact.
You're obviously agreeing that this is wrong.
When I said jelly should always use artifacts not deps to construct
paths, its precisely because these *are* the paths "constructed in maven
core (artifact factory)". I just hadn't spotted that I could use
getFile() as well as getPath(). You seem not to have noticed the
'' in my code is a jelly call to
artifact.getPath()?
Anyway, I was posting because you said "Moreover there is no easy way of
determining if artifact was overriden or not (it is in maven-new, but
that's different story)" - when as far as I can tell this problem is
fixable in the jelly for RC1? You don't need to know in a plugin whether
or not a jar is overridden, just the file.
I would rather prefer that jelly uses path constructed in maven core
(artifact factory) and ignore existence of such <> like "local
repository".
Yup.
[1] A list from b8, posted to this list previously. All of these are
probably bugs:
brian [EMAIL PROTECTED] /c/maven/plugins
$ find . -name '*.jelly' | xargs grep pom.dependencies
./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-cactus-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-deploy-plugin-1.0/plugin.jelly:
./maven-ear-plugin-1.0/plugin.jelly:
./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly:
./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly:
./maven-idea-plugin-1.0/plugin.jelly:
./maven-j2ee-plugin-1.1-SNAPSHOT/plugin.jelly:
items="${pom.dependencies}">
./maven-jdeveloper-plugin-1.0-SNAPSHOT/plugin.jelly:
./maven-jnlp-plugin-1.0/plugin.jelly:
./maven-jnlp-plugin-1.0/plugin.jelly:
./maven-release-plugin-1.0/plugin.jelly:
./maven-uberjar-plugin-1.0/plugin.jelly:
./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly:
as are almost all of these (mostly related to the use above):
$ find . -name '*.jelly' | xargs grep maven.repo.local
./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly:${maven.repo.local}
./maven-cactus-plugin-1.2-SNAPSHOT/plugin.jelly:
location="${maven.repo.local}/${lib.artifactDirectory}/jars/${lib.artifact}"/>
./maven-deploy-plugin-1.0/plugin.jelly:
value='${context.getVariable("maven.repo.local")}'/>
./maven-ear-plugin-1.0/plugin.jelly:
./maven-ear-plugin-1.0/plugin.jelly:
./maven-ear-plugin-1.0/plugin.jelly:
./maven-ear-plugin-1.0/plugin.jelly:
value="${maven.repo.local}/${pom.artifactDirectory}/ears"/>
./maven-eclipse-plugin-1.2-SNAPSHOT/plugin.jelly:
default="${maven.repo.local}" />
./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly:
./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly:
value="${maven.repo.local}/${pom.artifactDirectory}/ejbs"/>
./maven-idea-plugin-1.0/plugin.jelly:
./maven-j2ee-plugin-1.1-SNAPSHOT/plugin.jelly:
./maven-java-plugin-1.2-SNAPSHOT/plugin.jelly:value="${maven.repo.local}/${pom.artifactDirectory}/jars"/>
./maven-java-plugin-1.2-SNAPSHOT/plugin.jelly:value="${maven.repo.local}/${pom.artifactDirectory}/jars"/>
./maven-jbuilder-plugin-1.1-SNAPSHOT/plugin.jelly:
./maven-jnlp-plugin-1.0/plugin.jelly:
jar="${maven.repo.local}/${lib.artifactDirectory}/jars/${lib.artifact}"
./maven-jnlp-plugin-1.0/plugin.jelly:
jar="${maven.repo.local}/${lib.artifactDirectory}/jars/${lib.artifact}"
./maven-plexus-plugin-0.2/plugin.jelly:
value="${maven.repo.local}/plexus/jars/${plexusPom.artifactId}-
${plexusPom.currentVersion}.jar"/>
./maven-plexus-plugin-0.2/plugi
Re: private jar dependencies
Has anyone raised this in Jira?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Brian Ewins <[EMAIL PROTECTED]> wrote on 24/06/2003
01:17:09 AM:
>
>
> Michal Maczka wrote:
>
> > [...]
> >
> >>(or something like that) - jelly should always use artifacts, not
> >>dependencies, to construct paths. It doesnt stop you naming jars
> >>whatever you like, if they are in the local repo. I had a look over
the
> >>broken plugins a while back and I think there was only one case where
it
> >>wasnt clear that the use of dependency was a bug.
> > Just to make myself more clear.
> >
> > I wanted to say that in the most of the cases plugins don't need to
know
> > nothing about existence of local repository. They just can operateon
set of
> > file with absolute path. I think that such assumption (or rather lack
of any
> > assumptions) can result in simpler code.
>
> I think we are in violent agreement...
>
> >
> > So I simply don't agree with statement: "jelly should always use
artifacts,
> > not dependencies, to construct paths".
>
> But yet you say "Plugin are supposed to work with artifacts" in the
> other post, which is basically what I am saying too.
>
> dependencies don't know anything about their paths, and most of the
> plugins[1] were guessing how to reconstruct the path to the artifact.
> You're obviously agreeing that this is wrong.
>
> When I said jelly should always use artifacts not deps to construct
> paths, its precisely because these *are* the paths "constructed in maven
> core (artifact factory)". I just hadn't spotted that I could use
> getFile() as well as getPath(). You seem not to have noticed the
> '' in my code is a jelly call to
> artifact.getPath()?
>
> Anyway, I was posting because you said "Moreover there is no easy way of
> determining if artifact was overriden or not (it is in maven-new, but
> that's different story)" - when as far as I can tell this problem is
> fixable in the jelly for RC1? You don't need to know in a plugin whether
> or not a jar is overridden, just the file.
>
> > I would rather prefer that jelly uses path constructed in maven core
> > (artifact factory) and ignore existence of such <> like "local
> > repository".
>
> Yup.
>
> [1] A list from b8, posted to this list previously. All of these are
> probably bugs:
> brian [EMAIL PROTECTED] /c/maven/plugins
> $ find . -name '*.jelly' | xargs grep pom.dependencies
> ./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly: items="${pom.dependencies}">
> ./maven-cactus-plugin-1.2-SNAPSHOT/plugin.jelly: var="lib" items="${pom.dependencies}">
> ./maven-deploy-plugin-1.0/plugin.jelly: items="${pom.dependencies}">
> ./maven-ear-plugin-1.0/plugin.jelly: items="${pom.dependencies}">
> ./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly: items="${pom.dependencies}">
> ./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly: items="${pom.dependencies}">
> ./maven-idea-plugin-1.0/plugin.jelly: items="${pom.dependencies}">
> ./maven-j2ee-plugin-1.1-SNAPSHOT/plugin.jelly: items="${pom.dependencies}">
> ./maven-jdeveloper-plugin-1.0-SNAPSHOT/plugin.jelly:
>
> ./maven-jnlp-plugin-1.0/plugin.jelly: var="lib" items="${pom.dependencies}">
> ./maven-jnlp-plugin-1.0/plugin.jelly: items="${pom.dependencies}">
> ./maven-release-plugin-1.0/plugin.jelly: items="${pom.dependencies}">
> ./maven-uberjar-plugin-1.0/plugin.jelly: items="${pom.dependencies}">
> ./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly: items="${pom.dependencies}">
> ./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly: items="${pom.dependencies}">
>
> as are almost all of these (mostly related to the use above):
> $ find . -name '*.jelly' | xargs grep maven.repo.local
> ./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly:
> ./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly:${maven.repo.local}
> ./maven-cactus-plugin-1.2-SNAPSHOT/plugin.jelly:
location="${maven.repo.local}/${lib.artifactDirectory}/jars/${lib.artifact}"/>
> ./maven-deploy-plugin-1.0/plugin.jelly: value='${context.getVariable("maven.repo.local")}'/>
> ./maven-ear-plugin-1.0/plugin.jelly: dir="${maven.repo.local}/${dep.artifactDirectory}/jars/">
> ./maven-ear-plugin-1.0/plugin.jelly: dir="${maven.repo.local}/${dep.artifactDirectory}/wars/">
> ./maven-ear-plugin-1.0/plugin.jelly: dir="${maven.repo.local}/${dep.artifactDirectory}/ejbs/">
> ./maven-ear-plugin-1.0/plugin.jelly:
> value="${maven.repo.local}/${pom.artifactDirectory}/ears"/>
> ./maven-eclipse-plugin-1.2-SNAPSHOT/plugin.jelly:
> default="${maven.repo.local}" />
> ./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly: dir="${maven.repo.local}/${dep.artifactDirectory}/jars/">
> ./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly:
> value="${maven.repo.local}/${pom.artifactDirectory}/ejbs"/>
> ./maven-idea-plugin-1.0/plugin.jelly:
Re: private jar dependencies
Thanks for these two+ suggestions on how to work with private jars. While I can't contribute much on the implementation details, I have some thoughts on the big picture. You can tell someone that setting up an artifact repository is the "right" way to do it, but regardless Maven/Ant users will use whatever approach makes their life easier (whatever solution is most appropriate for a given situation). In my case I want to use some of the features of Maven (reports, web site, etc.) but don't need all of them. I probably won't set up an artifact repository until the incremental benefit of doing so outweighs the incremental cost (complexity, time--remember setting up a repository also involves maintaining, training, backing up, etc.) So I don't think it should be an all-or-nothing choice. Regards, Otto --- Jason van Zyl <[EMAIL PROTECTED]> wrote: > On Fri, 2003-06-20 at 18:55, Otto von Wachter wrote: > > Hi all, > > > > I have a question/suggestion on jar dependencies. I > think > > maven is perfect for open source (large/collaborative) > > projects. I would like to leverage Maven for my > internal > > project at work, but not all dependencies are available > on > > ibiblio (some are not open source, etc.) Also it makes > > sense for us to keep these jars in CVS, to make sure > they > > don't get lost, and just because "it works". > > > > What I would like is to specify some "private" jar > > dependencies that are stored in a lib dir. Is there a > quick > > hack that would allow me to do this? If it is, perhaps > > documenting it would increase the adoption of maven > among > > users like me. If not would it be easy to add this > feature? > > I was thinking of something like this: > > > > > > lib > > > > > > or maybe > > > > > > > > > > > > > > > > ... > > > > > > I know this might go against the "maven philosophy", > but it > > would be optional, and it's one of the things that is > > keeping me from using Maven instead of Ant. > > Something for this will never be built into Maven. You > lose anything > Maven provides in the way of auto-downloading and > verification. I would > recommend you save yourself much grief and spend 10 > minutes and make > yourself a local repository. But do what you like, here's > one way you > might do it: > >xmlns:ant="jelly:ant" > xmlns:maven="jelly:maven"> > > > > > > > > >id="maven.dependency.classpath" > refid="my.doublebarrel.classpath"/> > > > > > > Again, I do not recommend you do this. > > > Otto > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://tambora.zenplex.org > > In short, man creates for himself a new religion of a > rational > and technical order to justify his work and to be > justified in it. > > -- Jacques Ellul, The Technological Society > > > - > 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: private jar dependencies
Michal Maczka wrote:
[...]
(or something like that) - jelly should always use artifacts, not
dependencies, to construct paths. It doesnt stop you naming jars
whatever you like, if they are in the local repo. I had a look over the
broken plugins a while back and I think there was only one case where it
wasnt clear that the use of dependency was a bug.
Just to make myself more clear.
I wanted to say that in the most of the cases plugins don't need to know
nothing about existence of local repository. They just can operate on set of
file with absolute path. I think that such assumption (or rather lack of any
assumptions) can result in simpler code.
I think we are in violent agreement...
So I simply don't agree with statement: "jelly should always use artifacts,
not dependencies, to construct paths".
But yet you say "Plugin are supposed to work with artifacts" in the
other post, which is basically what I am saying too.
dependencies don't know anything about their paths, and most of the
plugins[1] were guessing how to reconstruct the path to the artifact.
You're obviously agreeing that this is wrong.
When I said jelly should always use artifacts not deps to construct
paths, its precisely because these *are* the paths "constructed in maven
core (artifact factory)". I just hadn't spotted that I could use
getFile() as well as getPath(). You seem not to have noticed the
'' in my code is a jelly call to
artifact.getPath()?
Anyway, I was posting because you said "Moreover there is no easy way of
determining if artifact was overriden or not (it is in maven-new, but
that's different story)" - when as far as I can tell this problem is
fixable in the jelly for RC1? You don't need to know in a plugin whether
or not a jar is overridden, just the file.
I would rather prefer that jelly uses path constructed in maven core
(artifact factory) and ignore existence of such <> like "local
repository".
Yup.
[1] A list from b8, posted to this list previously. All of these are
probably bugs:
brian [EMAIL PROTECTED] /c/maven/plugins
$ find . -name '*.jelly' | xargs grep pom.dependencies
./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-cactus-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-deploy-plugin-1.0/plugin.jelly:
./maven-ear-plugin-1.0/plugin.jelly:
./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly:
./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly:
./maven-idea-plugin-1.0/plugin.jelly:
./maven-j2ee-plugin-1.1-SNAPSHOT/plugin.jelly:
./maven-jdeveloper-plugin-1.0-SNAPSHOT/plugin.jelly:
./maven-jnlp-plugin-1.0/plugin.jelly:
./maven-jnlp-plugin-1.0/plugin.jelly:
./maven-release-plugin-1.0/plugin.jelly:
./maven-uberjar-plugin-1.0/plugin.jelly:
./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly:
as are almost all of these (mostly related to the use above):
$ find . -name '*.jelly' | xargs grep maven.repo.local
./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-ant-plugin-1.2-SNAPSHOT/plugin.jelly:${maven.repo.local}
./maven-cactus-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-deploy-plugin-1.0/plugin.jelly:
./maven-ear-plugin-1.0/plugin.jelly:
./maven-ear-plugin-1.0/plugin.jelly:
./maven-ear-plugin-1.0/plugin.jelly:
./maven-ear-plugin-1.0/plugin.jelly:
value="${maven.repo.local}/${pom.artifactDirectory}/ears"/>
./maven-eclipse-plugin-1.2-SNAPSHOT/plugin.jelly:
default="${maven.repo.local}" />
./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly:
./maven-ejb-plugin-1.0-SNAPSHOT/plugin.jelly:
value="${maven.repo.local}/${pom.artifactDirectory}/ejbs"/>
./maven-idea-plugin-1.0/plugin.jelly:
./maven-j2ee-plugin-1.1-SNAPSHOT/plugin.jelly:
./maven-java-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-java-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-jbuilder-plugin-1.1-SNAPSHOT/plugin.jelly:
./maven-jnlp-plugin-1.0/plugin.jelly:
jar="${maven.repo.local}/${lib.artifactDirectory}/jars/${lib.artifact}"
./maven-jnlp-plugin-1.0/plugin.jelly:
jar="${maven.repo.local}/${lib.artifactDirectory}/jars/${lib.artifact}"
./maven-plexus-plugin-0.2/plugin.jelly:
value="${maven.repo.local}/plexus/jars/${plexusPom.artifactId}-${plexusPom.currentVersion}.jar"/>
./maven-plexus-plugin-0.2/plugin.jelly:
value="${maven.repo.local}/plexus/poms/${component}.pom"/>
./maven-plexus-plugin-0.2/plugin.jelly:
value="${maven.repo.local}/plexus/jars/${depPom.artifactId}-${depPom.currentVersion}.jar"/>
./maven-plugin-plugin-1.0-SNAPSHOT/plugin.jelly:
todir="${maven.repo.local}/maven/jars" />
./maven-uberjar-plugin-1.0/plugin.jelly:
file="${maven.repo.local}/${dep.artifactDirectory}/jars/${dep.artifact}"/>
./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly:
./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly:
file="${maven.repo.local}/${dep.artifactDirectory}/jars/${dep.artifact}"/>
./maven-war-plugin-1.2-SNAPSHOT/plugin.jelly
RE: private jar dependencies
[...] > > (or something like that) - jelly should always use artifacts, not > dependencies, to construct paths. It doesnt stop you naming jars > whatever you like, if they are in the local repo. I had a look over the > broken plugins a while back and I think there was only one case where it > wasnt clear that the use of dependency was a bug. > Just to make myself more clear. I wanted to say that in the most of the cases plugins don't need to know nothing about existence of local repository. They just can operate on set of file with absolute path. I think that such assumption (or rather lack of any assumptions) can result in simpler code. So I simply don't agree with statement: "jelly should always use artifacts, not dependencies, to construct paths". I would rather prefer that jelly uses path constructed in maven core (artifact factory) and ignore existence of such <> like "local repository". Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private jar dependencies
[...]
> Those plugins are unnecessarily wrong though. The offending code in the
> war plugin:
>
>
>
>
>
>
>
>
> Should read:
>
>
>
>
>
>
>
>
>
> (or something like that) - jelly should always use artifacts, not
> dependencies, to construct paths. It doesnt stop you naming jars
> whatever you like, if they are in the local repo. I had a look over the
> broken plugins a while back and I think there was only one case where it
> wasnt clear that the use of dependency was a bug.
>
What about the case when overridden jars are not in repository?
Say I will put:
maven.jar.a = ${mylibdir}/lib/a.jar
maven.jar.b = ${mylibdir}/lib/b.jar
and set myslib to
mylib=c:\\temp
I don't see also any reason why we should guess or recompute artifacts paths
in plugins.
Artifact interface provides methods like;
File getFile();
String getPath();
(If those methods are not exactly what we need we can add similar)
Why not to use them?
Plugin are supposed to work with artifacts.
Artifacts for me are just files with some metadata (defined by dependency).
Once we have a set of artifact we have a set of files with well defined
location in local file system. Maven core takes care about is.
It doesn't matter if this location is relative to local repository or not.
It is fixed and already computed. Why should we bother to recalculate this
value all over again?
Only good reason I know is the fact we use ant FileSets. And they are
limited. But this is not a reason which is good enough.
mm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: private jar dependencies
dion gillard wrote: Michal Maczka wrote: This feature probably is not used so often but surly plugins like war, ear, eclipse are not aware of the fact that artifact can be overriden! and what they do is something like: So basiclly they require that artifact must be in local repository. Moreover there is no easy way of determining if artifact was overriden or not (it is in maven-new, but that's different story) Those plugins are unnecessarily wrong though. The offending code in the war plugin: Should read: (or something like that) - jelly should always use artifacts, not dependencies, to construct paths. It doesnt stop you naming jars whatever you like, if they are in the local repo. I had a look over the broken plugins a while back and I think there was only one case where it wasnt clear that the use of dependency was a bug. -Baz Privacy and Confidentiality Notice The information contained in this E-Mail message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on the telephone number printed above. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. i-documentsystems Ltd. does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this Email, however made, after it was sent. (Please note that it is your responsibility to scan this message for viruses). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private jar dependencies
Otto von Wachter wrote: What I would like is to specify some "private" jar dependencies that are stored in a lib dir. Is there a quick hack that would allow me to do this? If it is, perhaps documenting it would increase the adoption of maven among users like me. If not would it be easy to add this feature? I have a private jar that I need for my other projects. When I build the private jar, I run: maven jar:install And it places the private jar in my local repository for me. From my other projects, I specify this private jar as a dependancy like any other. As the right version is already available locally, maven has no need to look for this private jar on ibiblio or anywhere else. Regards, Graham -- - [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private jar dependencies
Michal Maczka wrote:
> So they just override version? Not paths?
> I am surly +1 for allowing overriding version.
> This is also a must from the perspective of "transitive dependencies"
> There must be some way of setting the preferred version or artifacts
> Even if they are not listed as dependencies in project.xml
>
> But we have two kinds of overrides:
>
> maven.jar.artifactId = [path]
>
> maven.jar.artifactId = [version]
>
>
> First of all it's just heuristic guessing if user has overridden version or
> path. And sometimes this guessing can fail (even ofen).
> Secondly the version with [path] overriding is against maven philosophy of
> forcing users to keep artifact in repositories.
Path overriding gives an extra bit of flexibility, but experience shows
that such extra bits is all too often used to complicate things beyound
need, and cause unnecessary grief.
I suggest that path overriding should be dropped if it causes
considerable implementation problems.
> Say that users have "unversion " artifacts inside his project (e.g in the
> ${basedir}/lib directory). They want to quickly switch to maven.
> Maven should help them, but such help can be also resolved outside of maven
> core using "special" fetchers.
> Say you use fetcher which will during "download" convert paths like
>
> /groupId/jars/artifactId-version.jar to ${basedir}/lib/artifactId.jar.
>
> So after first run of such fetcher the local repository will be populated
> with those jars. After some time when this operation was performed by all
> team members the lib directory can be erased.
I'd say that it would be enough if one developer run a special goal that
would copy the jars over. It could even be interactive - ask for lib
directory location, target repository location (local fs should be
sufficient - resulting repo can be copied over to the destination server
manually), and then iterate over the jars and ask for their groupId,
artifactId and version, trying to provide sensible defaults based on the
POM.
> So -1 on first kind of overriding but +1 on second.
I second Michal's opinion.
> I also think that we should support per project repositories (they are in
> practice threaten as another "remote" repository). This will allow easier
> transition for project using e.g. ant to maven.
Are they any different that any other remote repositories? I think that
maven supports them now, it's only a matter of terminology.
R.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: private jar dependencies
> -Original Message-
> From: dion gillard [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 23, 2003 5:35 AM
> To: [EMAIL PROTECTED]
> Subject: Re: private jar dependencies
>
> Michal Maczka wrote:
>
>
> > There is one more mean for realizing such scenario which was not
> mentioned
> > here:
> > jar overriding mechanism (or more generally artifact overriding
> mechanism).
> >
> > I am personally for dropping the jar overriding mechanism.
> > and for replacing them with such "fake remote repository" as Aslak has
> > described.
> Big, big -1 on this. I have a real need for the jar override facility.
> We have maven users who run common sql through db2. they each have their
> own db2 release, and MUST use the jar file that corresponds to their db2
> install.
So they just override version? Not paths?
I am surly +1 for allowing overriding version.
This is also a must from the perspective of "transitive dependencies"
There must be some way of setting the preferred version or artifacts
Even if they are not listed as dependencies in project.xml
But we have two kinds of overrides:
maven.jar.artifactId = [path]
maven.jar.artifactId = [version]
First of all it's just heuristic guessing if user has overridden version or
path. And sometimes this guessing can fail (even ofen).
Secondly the version with [path] overriding is against maven philosophy of
forcing users to keep artifact in repositories.
Say that users have "unversion " artifacts inside his project (e.g in the
${basedir}/lib directory). They want to quickly switch to maven.
Maven should help them, but such help can be also resolved outside of maven
core using "special" fetchers.
Say you use fetcher which will during "download" convert paths like
/groupId/jars/artifactId-version.jar to ${basedir}/lib/artifactId.jar.
So after first run of such fetcher the local repository will be populated
with those jars. After some time when this operation was performed by all
team members the lib directory can be erased.
So -1 on first kind of overriding but +1 on second.
I also think that we should support per project repositories (they are in
practice threaten as another "remote" repository). This will allow easier
transition for project using e.g. ant to maven.
>
> > This will make the implementation cleaner.
> And less functional.
>
> > There is a lot of places in maven where the fact that artifact was
> overriden
> > is simply ignored.
> This is a bug and should be fixed. Before 1.0
>
> > This feature probably is not used so often but surly plugins like
> > war, ear, eclipse are not aware of the fact that artifact can be
> overriden!
> >
> > and what they do is something like:
> >
> >
> >
> >dir="${maven.repo.local}/${dep.artifactDirectory}/jars/">
> >
> >
> >
> >
> > So basiclly they require that artifact must be in local repository.
> Any artifact thats listed as a dependency MUST be available in the local
> repository.
Not really. If we use jar overriding with
maven.jar.artifactId = [path]
it can be anywhere.
[...]
mm
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: private jar dependencies
On Sun, 2003-06-22 at 23:34, dion gillard wrote: > Michal Maczka wrote: > > > > There is one more mean for realizing such scenario which was not mentioned > > here: > > jar overriding mechanism (or more generally artifact overriding mechanism). > > > > I am personally for dropping the jar overriding mechanism. > > and for replacing them with such "fake remote repository" as Aslak has > > described. > Big, big -1 on this. I have a real need for the jar override facility. > We have maven users who run common sql through db2. they each have their > own db2 release, and MUST use the jar file that corresponds to their db2 > install. The override is absolutely necessary. You cannot do any sort of integration build without it. My particular case is Tambora where I pull in bits and pieces from all over the place and many of the bits have conflicting versions. Now for me the version overriding would suffice so we could definitely nudge people to use a repository structure. But being able to override the version is crucial for integration. > > This will make the implementation cleaner. > And less functional. > > > There is a lot of places in maven where the fact that artifact was overriden > > is simply ignored. > This is a bug and should be fixed. Before 1.0 > > > This feature probably is not used so often but surly plugins like > > war, ear, eclipse are not aware of the fact that artifact can be overriden! > > > > and what they do is something like: > > > > > > > > > > > > > > > > > > So basiclly they require that artifact must be in local repository. > Any artifact thats listed as a dependency MUST be available in the local > repository. > > > I think that this assumption is correct and it is the idea of jar overriding > > which is wrong. > I think this assumption is correct, and that the plugins shouldn't > assume this format. > > > Moreover there is no easy way of determining if artifact was overriden or > > not (it is in maven-new, but that's different story) > Is it needed? -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private jar dependencies
Michal Maczka wrote: There is one more mean for realizing such scenario which was not mentioned here: jar overriding mechanism (or more generally artifact overriding mechanism). I am personally for dropping the jar overriding mechanism. and for replacing them with such "fake remote repository" as Aslak has described. Big, big -1 on this. I have a real need for the jar override facility. We have maven users who run common sql through db2. they each have their own db2 release, and MUST use the jar file that corresponds to their db2 install. This will make the implementation cleaner. And less functional. There is a lot of places in maven where the fact that artifact was overriden is simply ignored. This is a bug and should be fixed. Before 1.0 This feature probably is not used so often but surly plugins like war, ear, eclipse are not aware of the fact that artifact can be overriden! and what they do is something like: So basiclly they require that artifact must be in local repository. Any artifact thats listed as a dependency MUST be available in the local repository. I think that this assumption is correct and it is the idea of jar overriding which is wrong. I think this assumption is correct, and that the plugins shouldn't assume this format. Moreover there is no easy way of determining if artifact was overriden or not (it is in maven-new, but that's different story) Is it needed? -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Work: http://www.multitask.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private jar dependencies
> -Original Message- > From: Aslak Hellesøy [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 21, 2003 12:33 PM > To: Maven Developers List > Subject: Re: private jar dependencies > > > > > > > We're doing this in the http://www.nanocontainer.org/ project. Have a > > look at: > > Oops, this example is from xdoclet2 and not nanocontainer. Oh well. > > > > > http://tinyurl.com/ew5l (look at the end of the 1st property) > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xdoclet2/lib/ > > (this is our own local repo treated as a remote one) > > > > Of course, if you're in a corporate environment, you should be able to > > set up a real remote repository on an internal webserver, whihch is an > > even cleaner solution. > > > > Aslak > > There is one more mean for realizing such scenario which was not mentioned here: jar overriding mechanism (or more generally artifact overriding mechanism). I am personally for dropping the jar overriding mechanism. and for replacing them with such "fake remote repository" as Aslak has described. This will make the implementation cleaner. There is a lot of places in maven where the fact that artifact was overriden is simply ignored. This feature probably is not used so often but surly plugins like war, ear, eclipse are not aware of the fact that artifact can be overriden! and what they do is something like: So basiclly they require that artifact must be in local repository. I think that this assumption is correct and it is the idea of jar overriding which is wrong. Moreover there is no easy way of determining if artifact was overriden or not (it is in maven-new, but that's different story) So I am really +1 on scenario described by Aslak. First time you start you maven -- artifact from "fake remote repository" will appear in local repository. And this forces you to __always__ keep repository layout which adheres to maven standards. Even if this repository is kept in CVS. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private jar dependencies
We're doing this in the http://www.nanocontainer.org/ project. Have a look at: Oops, this example is from xdoclet2 and not nanocontainer. Oh well. http://tinyurl.com/ew5l (look at the end of the 1st property) http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xdoclet2/lib/ (this is our own local repo treated as a remote one) Of course, if you're in a corporate environment, you should be able to set up a real remote repository on an internal webserver, whihch is an even cleaner solution. Aslak Otto - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private jar dependencies
Jason van Zyl wrote: On Fri, 2003-06-20 at 18:55, Otto von Wachter wrote: Hi all, I have a question/suggestion on jar dependencies. I think maven is perfect for open source (large/collaborative) projects. I would like to leverage Maven for my internal project at work, but not all dependencies are available on ibiblio (some are not open source, etc.) Also it makes sense for us to keep these jars in CVS, to make sure they don't get lost, and just because "it works". What I would like is to specify some "private" jar dependencies that are stored in a lib dir. Is there a quick hack that would allow me to do this? If it is, perhaps documenting it would increase the adoption of maven among users like me. If not would it be easy to add this feature? I was thinking of something like this: lib or maybe ... I know this might go against the "maven philosophy", but it would be optional, and it's one of the things that is keeping me from using Maven instead of Ant. Something for this will never be built into Maven. You lose anything Maven provides in the way of auto-downloading and verification. I would recommend you save yourself much grief and spend 10 minutes and make yourself a local repository. But do what you like, here's one way you might do it: xmlns:maven="jelly:maven"> refid="my.doublebarrel.classpath"/> Again, I do not recommend you do this. I'm a little puzzled by this approach Jason. Here is a much cleaner way IMHO: 1) Make your own repository structure inside your project under a lib folder 2) Tell maven to use that as an additional remote repository (!) We're doing this in the http://www.nanocontainer.org/ project. Have a look at: http://tinyurl.com/ew5l (look at the end of the 1st property) http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xdoclet2/lib/ (this is our own local repo treated as a remote one) Of course, if you're in a corporate environment, you should be able to set up a real remote repository on an internal webserver, whihch is an even cleaner solution. Aslak Otto - 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: private jar dependencies
On Fri, 2003-06-20 at 18:55, Otto von Wachter wrote: > Hi all, > > I have a question/suggestion on jar dependencies. I think > maven is perfect for open source (large/collaborative) > projects. I would like to leverage Maven for my internal > project at work, but not all dependencies are available on > ibiblio (some are not open source, etc.) Also it makes > sense for us to keep these jars in CVS, to make sure they > don't get lost, and just because "it works". > > What I would like is to specify some "private" jar > dependencies that are stored in a lib dir. Is there a quick > hack that would allow me to do this? If it is, perhaps > documenting it would increase the adoption of maven among > users like me. If not would it be easy to add this feature? > I was thinking of something like this: > > > lib > > > or maybe > > > > > > > > ... > > > I know this might go against the "maven philosophy", but it > would be optional, and it's one of the things that is > keeping me from using Maven instead of Ant. Something for this will never be built into Maven. You lose anything Maven provides in the way of auto-downloading and verification. I would recommend you save yourself much grief and spend 10 minutes and make yourself a local repository. But do what you like, here's one way you might do it: Again, I do not recommend you do this. > Otto > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
