Re: Dependencies Options
On Mon, 2006-04-24 at 21:25 -0400, Alexandre Poitras wrote: On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: tons of advantages - please quantify this. Well distributing internal corporation dependencies and managing the version, especially nightly build is way easier using Maven repository capabilities. Managing your project dependencies version is also really easier (especially conflicts and snapshots). I would disagree. Managing dependencies is really easy when you've checked jars into a directory - the jars used are the ones in that dir, and nothing else. Of course this does have the disadvantages listed in my mail (more repo space needed, more bandwidth). All the Maven generated reports also work better with regular dependencies because they can find some metadatas to work with. true. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. Nothing the exclude tag can't fix. That can be quite clumsy to use, though. Sometimes half-a-dozen libs need to be excluded, at which point the pom becomes hard to read. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? You are making this sound like it is a lot of work. Manually installing files on a corporate repository using install:install-file usually doesn't take more time then checking them inside SVN. A maven repository is basically a Jar versionning systems. [as noted in your followup, you meant deploy:deploy-file] That's assuming that a corporate repo exists and that it has upload support available. I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) If you have a remote Maven repository on the same server as your SVN repo, I really don't see the difference. True, as long as: (a) your svn server is already running behind a webserver, so the maven repo can easily be set up, (b) there is some upload support for that server, (c) there is some way of ensuring that jars always come from this repo, and never from ibiblio (this is the hardest bit in my experience) Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependencies Options
If we do not use the system dependecies then how can we resolve the dependency on ejb3.0 which is not available on http://www.ibiblio.org/maven2/. This was my problem so i used ejb3 jars distributed by jboss.Is there any other way? pom.xml--- groupIdjboss.ejb3/groupId artifactIdejb3-persistence/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/server/default/deploy/ejb3.deployer/ejb3- persistence.jar/systemPath /dependency dependency groupIdjboss.ejb3/groupId artifactIdejb3-management/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/docs/examples/jmx/ejb-management.jar /systemPath /dependency dependency groupIdjboss-ejb3x/groupId artifactIdejb3x/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/server/default/deploy/ejb3.deployer/jboss- ejb3x.jar/systemPath /dependency dependency groupIdjboss-annotations-ejb3/groupId artifactIdannotations-ejb3/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/server/default/deploy/ejb3.deployer/jboss- annotations-ejb3.jar/systemPath /dependency On 4/25/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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: Dependencies Options
On 4/25/06, Simon Kitching [EMAIL PROTECTED] wrote: On Mon, 2006-04-24 at 21:25 -0400, Alexandre Poitras wrote: On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: tons of advantages - please quantify this. Well distributing internal corporation dependencies and managing the version, especially nightly build is way easier using Maven repository capabilities. Managing your project dependencies version is also really easier (especially conflicts and snapshots). I would disagree. Managing dependencies is really easy when you've checked jars into a directory - the jars used are the ones in that dir, and nothing else. Well if you depend on a project developped concurrently (some common component) and not a stable component, it is easier. Easy to upgrade to a newer version and especially easy to get the new nightly builds in the morning. Of course, this is doable using some other mechanism but you have to it manually. Maven just see there are a fresh snapshot available and download it. Well, from experience I have found it easier but I guess it depends if Maven fit the way your corporation work. Of course this does have the disadvantages listed in my mail (more repo space needed, more bandwidth). All the Maven generated reports also work better with regular dependencies because they can find some metadatas to work with. true. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. Nothing the exclude tag can't fix. That can be quite clumsy to use, though. Sometimes half-a-dozen libs need to be excluded, at which point the pom becomes hard to read. Yup but if it is the case it is usually because the original dependency pom has some dependencies that should be declared optional. Time to fill a JIRA issue. Also, the key here is using a super pom so those settings are fixed for all your projects, this is what I do with Spring and Hibernate and it works very well. I don't have to declare all those exclude again and again. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? You are making this sound like it is a lot of work. Manually installing files on a corporate repository using install:install-file usually doesn't take more time then checking them inside SVN. A maven repository is basically a Jar versionning systems. [as noted in your followup, you meant deploy:deploy-file] That's assuming that a corporate repo exists and that it has upload support available. Yup but honestly I wouldn't use Maven without it because when you find a bug on ibiblio you don't have to wait for your bug report to be treated, you can fix it on internal corporation repository in the mean time. I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) If you have a remote Maven repository on the same server as your SVN repo, I really don't see the difference. True, as long as: (a) your svn server is already running behind a webserver, so the maven repo can easily be set up, (b) there is some upload support for that server, (c) there is some way of ensuring that jars always come from this repo, and never from ibiblio (this is the hardest bit in my experience) You're right except couple of things : - a) Http is not mandatory, you can use ftp or sctp for instance. - c) Well this is one is easy to fix, install Maven proxy on your internal corporation repository. Now on your desktop, go in your settings.xml and declare this repository as the only mirror of central. You'll never go on ibiblio again, the proxy will if you have configured it to do so. The only possible downside of this approach is that your repository server needs acces to the Internet. I understand inital difficulties using Maven repositories but once you have an internal corporation repository coupled with Maven-proxy, things get better. Well right now Maven-proxy is not the best
Re: Dependencies Options
Well using the Jboss jars is indeed the solution. The only thing I would do is install it in my local repository using install:install-file. But you have to know it won't work on other desktop so usually you should have an internal corporation repository and deploy them there. This each developper won't have to install them manually. After that, you can work with those jar like they were normal dependencies. On 4/25/06, Anshuman Srivastava [EMAIL PROTECTED] wrote: If we do not use the system dependecies then how can we resolve the dependency on ejb3.0 which is not available on http://www.ibiblio.org/maven2/. This was my problem so i used ejb3 jars distributed by jboss.Is there any other way? pom.xml--- groupIdjboss.ejb3/groupId artifactIdejb3-persistence/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/server/default/deploy/ejb3.deployer/ejb3- persistence.jar/systemPath /dependency dependency groupIdjboss.ejb3/groupId artifactIdejb3-management/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/docs/examples/jmx/ejb-management.jar /systemPath /dependency dependency groupIdjboss-ejb3x/groupId artifactIdejb3x/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/server/default/deploy/ejb3.deployer/jboss- ejb3x.jar/systemPath /dependency dependency groupIdjboss-annotations-ejb3/groupId artifactIdannotations-ejb3/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/server/default/deploy/ejb3.deployer/jboss- annotations-ejb3.jar/systemPath /dependency On 4/25/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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: Dependencies Options
Use mvn install:install-file ... to install those ejb3 files into your local repository. Then use scope compile, test, or provided as necessary. This is documented on the Maven website: http://maven.apache.org/guides/mini/guide-installing-3rd-party-jars.html Wayne On 4/25/06, Anshuman Srivastava [EMAIL PROTECTED] wrote: If we do not use the system dependecies then how can we resolve the dependency on ejb3.0 which is not available on http://www.ibiblio.org/maven2/. This was my problem so i used ejb3 jars distributed by jboss.Is there any other way? pom.xml--- groupIdjboss.ejb3/groupId artifactIdejb3-persistence/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/server/default/deploy/ejb3.deployer/ejb3- persistence.jar/systemPath /dependency dependency groupIdjboss.ejb3/groupId artifactIdejb3-management/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/docs/examples/jmx/ejb-management.jar /systemPath /dependency dependency groupIdjboss-ejb3x/groupId artifactIdejb3x/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/server/default/deploy/ejb3.deployer/jboss- ejb3x.jar/systemPath /dependency dependency groupIdjboss-annotations-ejb3/groupId artifactIdannotations-ejb3/artifactId version3.0/version scopesystem/scope systemPathC:/boss-4.0.4/server/default/deploy/ejb3.deployer/jboss- annotations-ejb3.jar/systemPath /dependency On 4/25/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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: Dependencies Options
Alexandre, First, thanks for your response. I appreciate you taking the time to answer my thoughts. Just one more thing I dislike about system dependencies I wanted to specify. A good practice is usually to do a complete project check out after a check in. Takes a lot of times when you have several jars bundled with your projects. This is a very contextual argument, which is what my point is. I think we can all find reasons why we would opt for using the jar repository (as Simon stated). But equally, I think there are contexts where we can make the argument for not using the jar repository. In all the contexts I've worked in thus far it takes me very little time to actually checkout my project... jars included. This holds true for larger projects too. Disk space is cheap. The strain on bandwidth is not a compelling enough argument due to the fact that a check happens once every few hours in a system that has a continuous build. Also, I don't think I've ever heard one complaint about disk space usage or bandwidth usage when checking out source code containing libraries. Another thought occurred to me while I was writing this. What about other binary elements that are in a source tree? Such as Images or PDFs. Should we create a binary repository for them too? Or maybe we can setup a WebDAV for those ;-) Sometimes these things are needed... but not every time. What is the difference between a internal corporation Maven repository and a internal corporation SVN repository setup on the same server? Nothing except Maven repository is better at handling dependencies then SVN. You really make my point here :). You pose the question What's the difference?. My answer is very little or none. So if there isn't a compelling difference for my project it becomes extra baggage that I would prefer not to have. Shouldn't it be an optional, planned and acceptable practice not to use it? So, the difference is: 1) I only need one repository SVN 2) I only need to make one call to SVN I think Simon has very valid points and has made a stab at a solution. Would an enhancement request to more openly support source tree based jars be welcomed? I want to reemphasize that I really appreciate the hard work the Maven developers have put in. I really enjoy much of Maven. I just believe the dependency options are too strict and need to provide additional support. Thank you all for your dialog on this, Brandon Goodin Start simple and grow to complexity... when necessary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependencies Options
I think you can checkin all your dependencies into SCM using maven layout. and point your pom to local directory containing your binaries. -D On 4/25/06, Goodin, Brandon [EMAIL PROTECTED] wrote: Alexandre, First, thanks for your response. I appreciate you taking the time to answer my thoughts. Just one more thing I dislike about system dependencies I wanted to specify. A good practice is usually to do a complete project check out after a check in. Takes a lot of times when you have several jars bundled with your projects. This is a very contextual argument, which is what my point is. I think we can all find reasons why we would opt for using the jar repository (as Simon stated). But equally, I think there are contexts where we can make the argument for not using the jar repository. In all the contexts I've worked in thus far it takes me very little time to actually checkout my project... jars included. This holds true for larger projects too. Disk space is cheap. The strain on bandwidth is not a compelling enough argument due to the fact that a check happens once every few hours in a system that has a continuous build. Also, I don't think I've ever heard one complaint about disk space usage or bandwidth usage when checking out source code containing libraries. Another thought occurred to me while I was writing this. What about other binary elements that are in a source tree? Such as Images or PDFs. Should we create a binary repository for them too? Or maybe we can setup a WebDAV for those ;-) Sometimes these things are needed... but not every time. What is the difference between a internal corporation Maven repository and a internal corporation SVN repository setup on the same server? Nothing except Maven repository is better at handling dependencies then SVN. You really make my point here :). You pose the question What's the difference?. My answer is very little or none. So if there isn't a compelling difference for my project it becomes extra baggage that I would prefer not to have. Shouldn't it be an optional, planned and acceptable practice not to use it? So, the difference is: 1) I only need one repository SVN 2) I only need to make one call to SVN I think Simon has very valid points and has made a stab at a solution. Would an enhancement request to more openly support source tree based jars be welcomed? I want to reemphasize that I really appreciate the hard work the Maven developers have put in. I really enjoy much of Maven. I just believe the dependency options are too strict and need to provide additional support. Thank you all for your dialog on this, Brandon Goodin Start simple and grow to complexity... when necessary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependencies Options
On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote:
It is *strongly* suggested that you do not utilize scope system. This
is available for the rare use case which actually requires it.
In general, you should add dependencies to your local repo (or a
corporate repo, if you are using one) and use dependency in the
normal manner.
So what do people do when they're using commercial libraries that aren't
just jars? We use a commercial toolkit that comprises just under 5,000
files, 40 of which are jar files. Right now, just so that I can use the
Maven repo, I have to manually deploy each of those jar files to our
internal repo, adding version numbers, creating group and artifact ids, etc.
Then I have to package the other files up as a few zip files that I can
download using the Maven dependency plugin, and deploy those to the repo as
well. This is a painful manual process that needs to be repeated each time
we get a new version from the vendor.
Things might be simpler if the dependency plugin actually related to
dependencies. ;-) What I mean is that, in theory, I could just drop the
whole 3rd party toolkit into the repo as a zip file, use the dependency
plugin to grap and explode it, and then reference the jar files in my POM.
But doing that would require the use of system scope, because the dependency
plugin doesn't actually add dependencies to your build. (Actually, I really
don't understand why it's called the 'dependency' plugin, unless I've missed
something quite fundamental about it. ;)
Since I can't imagine that using a commercial toolkit could be considered a
rare use case, I'm wondering if I'm missing something rather basic. What
are other people doing in similar circumstances?
--
Martin Cooper
Wayne
On 4/24/06, Kristian Nordal [EMAIL PROTECTED] wrote:
On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote:
Is it a requirement that i use the remote repository for jars? Is
there a way to reference jars that are distributed with the code when
checked out from the code repository?
Take a look at the system scope:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
e.g:
dependency
groupIdfoo/groupId
artifactIdfoo/artifactId
version1.0.0/version
scopesystem/scope
systemPath${basedir}/foo/foo/1.0.0/foo-1.0.0.jar/systemPath
/dependency
--
Cheers,
Kristian
Re: Dependencies Options
On 4/25/06, Goodin, Brandon [EMAIL PROTECTED] wrote: Alexandre, First, thanks for your response. I appreciate you taking the time to answer my thoughts. Just one more thing I dislike about system dependencies I wanted to specify. A good practice is usually to do a complete project check out after a check in. Takes a lot of times when you have several jars bundled with your projects. This is a very contextual argument, which is what my point is. I think we can all find reasons why we would opt for using the jar repository (as Simon stated). But equally, I think there are contexts where we can make the argument for not using the jar repository. In all the contexts I've worked in thus far it takes me very little time to actually checkout my project... jars included. This holds true for larger projects too. Disk space is cheap. The strain on bandwidth is not a compelling enough argument due to the fact that a check happens once every few hours in a system that has a continuous build. Also, I don't think I've ever heard one complaint about disk space usage or bandwidth usage when checking out source code containing libraries. Another thought occurred to me while I was writing this. What about other binary elements that are in a source tree? Such as Images or PDFs. Should we create a binary repository for them too? Or maybe we can setup a WebDAV for those ;-) Sometimes these things are needed... but not every time. They follow the project versionning so they be stored in SVN. The difference is not based upon the file type but upon their versionning cycle. What is the difference between a internal corporation Maven repository and a internal corporation SVN repository setup on the same server? Nothing except Maven repository is better at handling dependencies then SVN. You really make my point here :). You pose the question What's the difference?. My answer is very little or none. So if there isn't a compelling difference for my project it becomes extra baggage that I would prefer not to have. Shouldn't it be an optional, planned and acceptable practice not to use it? Yeah, but dependencies have a versionning scheme of their own that don't follow the project one. It wouldn't make any sense to me to put other project sources in my project SVN repository either. Here why I think dependencies repositories have a purpose. So, the difference is: 1) I only need one repository SVN 2) I only need to make one call to SVN See my previous comment. I think Simon has very valid points and has made a stab at a solution. Would an enhancement request to more openly support source tree based jars be welcomed? I am not a developper so I don't know. You should ask on the dev list. I want to reemphasize that I really appreciate the hard work the Maven developers have put in. I really enjoy much of Maven. I just believe the dependency options are too strict and need to provide additional support. No problem, I also appreciate this discussion but I have a strong opinion on this subject as you can see :) I prefer to put jar in Maven repositories because it allow different teams to work on interdependent project quite easily. Thank you all for your dialog on this, Brandon Goodin Start simple and grow to complexity... when necessary - 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: Dependencies Options
On 4/25/06, Martin Cooper [EMAIL PROTECTED] wrote:
On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote:
It is *strongly* suggested that you do not utilize scope system. This
is available for the rare use case which actually requires it.
In general, you should add dependencies to your local repo (or a
corporate repo, if you are using one) and use dependency in the
normal manner.
So what do people do when they're using commercial libraries that aren't
just jars? We use a commercial toolkit that comprises just under 5,000
files, 40 of which are jar files. Right now, just so that I can use the
Maven repo, I have to manually deploy each of those jar files to our
internal repo, adding version numbers, creating group and artifact ids, etc.
Then I have to package the other files up as a few zip files that I can
download using the Maven dependency plugin, and deploy those to the repo as
well. This is a painful manual process that needs to be repeated each time
we get a new version from the vendor.
Things might be simpler if the dependency plugin actually related to
dependencies. ;-) What I mean is that, in theory, I could just drop the
whole 3rd party toolkit into the repo as a zip file, use the dependency
plugin to grap and explode it, and then reference the jar files in my POM.
But doing that would require the use of system scope, because the dependency
plugin doesn't actually add dependencies to your build. (Actually, I really
don't understand why it's called the 'dependency' plugin, unless I've missed
something quite fundamental about it. ;)
Really, I think this is one case where using system dependencies make
sense. But expect changes in the system dependencies. From what I have
red, Maven developpers think it is just a temporary patch for those
kind of problems.
Since I can't imagine that using a commercial toolkit could be considered a
rare use case, I'm wondering if I'm missing something rather basic. What
are other people doing in similar circumstances?
I think system dependencies makes sense there but I could be wrong.
--
Martin Cooper
Wayne
On 4/24/06, Kristian Nordal [EMAIL PROTECTED] wrote:
On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote:
Is it a requirement that i use the remote repository for jars? Is
there a way to reference jars that are distributed with the code when
checked out from the code repository?
Take a look at the system scope:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
e.g:
dependency
groupIdfoo/groupId
artifactIdfoo/artifactId
version1.0.0/version
scopesystem/scope
systemPath${basedir}/foo/foo/1.0.0/foo-1.0.0.jar/systemPath
/dependency
--
Cheers,
Kristian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependencies Options
On 4/25/06, Wayne Fay [EMAIL PROTECTED] wrote:
Since you're a paying customer, I'd ask your vendor to set up a Maven
repo protected by HTTPS (or something similar to only allow valid
customers to access it) that you can utilize. Put the onus back on
them to handle the Maven repo with upgrading components etc.
If this isn't realistic, I'd write a little Perl or Ruby script to
accept a version number and a directory containing the jars, and make
system calls to install each jar in turn into your corporate repo.
When it has finished installing them, it could output a dependencies
xml node that you can cut and paste into your project pom.xml files to
pull in all the newly installed modules. (Someone actually sent a Ruby
script to do the first half of this a few weeks ago, check the User
list archive.)
As for dependency plugin does not add dependencies... I'm wondering
where that's coming from... If your third-party jars were proper
Maven dependencies, they would each have a pom file describing their
dependencies. So you could include in your pom a dependency on modA,
which has deps on modB, modC; and modC has deps on modD and modE.
Simply by adding the modA dep in your project's pom file, you would
have modA-modE pulled in and used automatically as needed during
compilation, testing, etc.
Only because you are not creating proper poms for each module,
declaring what specifically is dependent on what else etc, Maven
cannot build a dependency tree to discover these transitive
dependencies. So instead you have to declare every single module
individually in your pom, I guess. This is not a fault of Maven,
rather, it is a failure related to your current usage of the tool.
(imho)
We use some commercial toolkit jars as well, but check them into our
Corporate repo, and just deal with it. Its not that big of a deal for
us. The 1hr work of one person turns into hours saved not emailing
jars around to all the various members of different development teams
to make sure their project lib folders are up to date, dealing with
large quantities of binary files checked into source control, etc. So
for us it is an advantage.
Totally agree with you on this one. We did the same and it's worth it.
Save a lot of problems, especially when you want to distribute a new
version.
Wayne
On 4/25/06, Martin Cooper [EMAIL PROTECTED] wrote:
On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote:
It is *strongly* suggested that you do not utilize scope system. This
is available for the rare use case which actually requires it.
In general, you should add dependencies to your local repo (or a
corporate repo, if you are using one) and use dependency in the
normal manner.
So what do people do when they're using commercial libraries that aren't
just jars? We use a commercial toolkit that comprises just under 5,000
files, 40 of which are jar files. Right now, just so that I can use the
Maven repo, I have to manually deploy each of those jar files to our
internal repo, adding version numbers, creating group and artifact ids, etc.
Then I have to package the other files up as a few zip files that I can
download using the Maven dependency plugin, and deploy those to the repo as
well. This is a painful manual process that needs to be repeated each time
we get a new version from the vendor.
Things might be simpler if the dependency plugin actually related to
dependencies. ;-) What I mean is that, in theory, I could just drop the
whole 3rd party toolkit into the repo as a zip file, use the dependency
plugin to grap and explode it, and then reference the jar files in my POM.
But doing that would require the use of system scope, because the dependency
plugin doesn't actually add dependencies to your build. (Actually, I really
don't understand why it's called the 'dependency' plugin, unless I've missed
something quite fundamental about it. ;)
Since I can't imagine that using a commercial toolkit could be considered a
rare use case, I'm wondering if I'm missing something rather basic. What
are other people doing in similar circumstances?
--
Martin Cooper
Wayne
On 4/24/06, Kristian Nordal [EMAIL PROTECTED] wrote:
On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote:
Is it a requirement that i use the remote repository for jars? Is
there a way to reference jars that are distributed with the code when
checked out from the code repository?
Take a look at the system scope:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
e.g:
dependency
groupIdfoo/groupId
artifactIdfoo/artifactId
version1.0.0/version
scopesystem/scope
systemPath${basedir}/foo/foo/1.0.0/foo-1.0.0.jar/systemPath
/dependency
--
Cheers,
Kristian
Re: Dependencies Options
On 4/25/06, Wayne Fay [EMAIL PROTECTED] wrote: Since you're a paying customer, I'd ask your vendor to set up a Maven repo protected by HTTPS (or something similar to only allow valid customers to access it) that you can utilize. Put the onus back on them to handle the Maven repo with upgrading components etc. I can try, but I won't hold my breath. ;-) In particular, there's no one way that would make sense for all of their customers to partition the ~5,000 files that are not jars. If this isn't realistic, I'd write a little Perl or Ruby script to accept a version number and a directory containing the jars, and make system calls to install each jar in turn into your corporate repo. When it has finished installing them, it could output a dependencies xml node that you can cut and paste into your project pom.xml files to pull in all the newly installed modules. (Someone actually sent a Ruby script to do the first half of this a few weeks ago, check the User list archive.) Yeah, that's where I figured I'd end up having to go. One thing that's a bit annoying on that front, though, is that I found that when I put a bunch of 'mvn foo' commands in a Windows batch file, only the first one executes, even if that first one is successful. ;-( As for dependency plugin does not add dependencies... I'm wondering where that's coming from... If your third-party jars were proper Maven dependencies, they would each have a pom file describing their dependencies. So you could include in your pom a dependency on modA, which has deps on modB, modC; and modC has deps on modD and modE. Simply by adding the modA dep in your project's pom file, you would have modA-modE pulled in and used automatically as needed during compilation, testing, etc. Sorry, that's not what I mean at all. I can use dependency:copy or dependency:unpack to get artifacts from the repo, but as far as I can determine, there is zero relationship between those artifacts and my build dependencies. Certainly anything I obtain that way is not treated as a dependency for build purposes. So I don't understand why they're in a plugin called a 'dependency' plugin. I understand that the '-dependencies' versions of these goals are based on declared dependencies, but that wasn't what I was referring to. Admittedly, I wasn't clear about that. Sorry. -- Martin Cooper Only because you are not creating proper poms for each module, declaring what specifically is dependent on what else etc, Maven cannot build a dependency tree to discover these transitive dependencies. So instead you have to declare every single module individually in your pom, I guess. This is not a fault of Maven, rather, it is a failure related to your current usage of the tool. (imho) We use some commercial toolkit jars as well, but check them into our Corporate repo, and just deal with it. Its not that big of a deal for us. The 1hr work of one person turns into hours saved not emailing jars around to all the various members of different development teams to make sure their project lib folders are up to date, dealing with large quantities of binary files checked into source control, etc. So for us it is an advantage. Wayne On 4/25/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: It is *strongly* suggested that you do not utilize scope system. This is available for the rare use case which actually requires it. In general, you should add dependencies to your local repo (or a corporate repo, if you are using one) and use dependency in the normal manner. So what do people do when they're using commercial libraries that aren't just jars? We use a commercial toolkit that comprises just under 5,000 files, 40 of which are jar files. Right now, just so that I can use the Maven repo, I have to manually deploy each of those jar files to our internal repo, adding version numbers, creating group and artifact ids, etc. Then I have to package the other files up as a few zip files that I can download using the Maven dependency plugin, and deploy those to the repo as well. This is a painful manual process that needs to be repeated each time we get a new version from the vendor. Things might be simpler if the dependency plugin actually related to dependencies. ;-) What I mean is that, in theory, I could just drop the whole 3rd party toolkit into the repo as a zip file, use the dependency plugin to grap and explode it, and then reference the jar files in my POM. But doing that would require the use of system scope, because the dependency plugin doesn't actually add dependencies to your build. (Actually, I really don't understand why it's called the 'dependency' plugin, unless I've missed something quite fundamental about it. ;) Since I can't imagine that using a commercial toolkit could be considered a rare use case, I'm wondering if I'm missing something
Re: Dependencies Options
On 4/25/06, Martin Cooper [EMAIL PROTECTED] wrote: Sorry, that's not what I mean at all. I can use dependency:copy or dependency:unpack to get artifacts from the repo, but as far as I can determine, there is zero relationship between those artifacts and my build dependencies. Certainly anything I obtain that way is not treated as a dependency for build purposes. So I don't understand why they're in a plugin called a 'dependency' plugin. You're right... Changing the plugin name to Artifact rather than Dependency might make more sense. ;-) Wayne
Dependencies Options
Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependencies Options
Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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: Dependencies Options
On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote:
Is it a requirement that i use the remote repository for jars? Is
there a way to reference jars that are distributed with the code when
checked out from the code repository?
Take a look at the system scope:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
e.g:
dependency
groupIdfoo/groupId
artifactIdfoo/artifactId
version1.0.0/version
scopesystem/scope
systemPath${basedir}/foo/foo/1.0.0/foo-1.0.0.jar/systemPath
/dependency
--
Cheers,
Kristian
Re: Dependencies Options
It is *strongly* suggested that you do not utilize scope system. This
is available for the rare use case which actually requires it.
In general, you should add dependencies to your local repo (or a
corporate repo, if you are using one) and use dependency in the
normal manner.
Wayne
On 4/24/06, Kristian Nordal [EMAIL PROTECTED] wrote:
On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote:
Is it a requirement that i use the remote repository for jars? Is
there a way to reference jars that are distributed with the code when
checked out from the code repository?
Take a look at the system scope:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
e.g:
dependency
groupIdfoo/groupId
artifactIdfoo/artifactId
version1.0.0/version
scopesystem/scope
systemPath${basedir}/foo/foo/1.0.0/foo-1.0.0.jar/systemPath
/dependency
--
Cheers,
Kristian
Re: Dependencies Options
tons of advantages - please quantify this. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) Thanks to everyone for pointing me in the direction of the system. I'll be using it. I'm always open to a compelling argument and a tap on the forehead that helps me to see the light. Many Thanks, Brandon On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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: Dependencies Options
Checking Sun Jars into your repo is a violation of the Sun Binary Compatibility License which you agreed to when you downloaded the file. (Assuming the file was downloaded from Sun under the Sun BCL terms, which most files on Sun.com require you to accept prior to downloading.) I doubt Sun will chase you down and prosecute you, but realize that some of us actually care about respecting intellectual property and license requirements. Complaining about the way these Sun Jars are handled to the Maven User list is really the wrong place -- complain directly to Sun, ask them to modify the distribution terms of their licenses, etc. Wayne On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: tons of advantages - please quantify this. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) Thanks to everyone for pointing me in the direction of the system. I'll be using it. I'm always open to a compelling argument and a tap on the forehead that helps me to see the light. Many Thanks, Brandon On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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: Dependencies Options
That should be Checking Sun Jars into your SVN repo. Obviously anyone is allowed to download the Sun Jars and install them into their own local Maven repo, or anything else permitted under the Sun BCL terms. Checking the jars into a publicly available distribution service ie Sourceforge CVS/SVN etc is unfortunately not allowed by Sun's licensing. You can go to Sun.com and read the specifics of the BCL if you want, to see what specifically is permitted and what is not. Wayne On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: Checking Sun Jars into your repo is a violation of the Sun Binary Compatibility License which you agreed to when you downloaded the file. (Assuming the file was downloaded from Sun under the Sun BCL terms, which most files on Sun.com require you to accept prior to downloading.) I doubt Sun will chase you down and prosecute you, but realize that some of us actually care about respecting intellectual property and license requirements. Complaining about the way these Sun Jars are handled to the Maven User list is really the wrong place -- complain directly to Sun, ask them to modify the distribution terms of their licenses, etc. Wayne On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: tons of advantages - please quantify this. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) Thanks to everyone for pointing me in the direction of the system. I'll be using it. I'm always open to a compelling argument and a tap on the forehead that helps me to see the light. Many Thanks, Brandon On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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: Dependencies Options
The sun jars were a minor point. You still didn't answer the larger context. Brandon On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: Checking Sun Jars into your repo is a violation of the Sun Binary Compatibility License which you agreed to when you downloaded the file. (Assuming the file was downloaded from Sun under the Sun BCL terms, which most files on Sun.com require you to accept prior to downloading.) I doubt Sun will chase you down and prosecute you, but realize that some of us actually care about respecting intellectual property and license requirements. Complaining about the way these Sun Jars are handled to the Maven User list is really the wrong place -- complain directly to Sun, ask them to modify the distribution terms of their licenses, etc. Wayne On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: tons of advantages - please quantify this. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) Thanks to everyone for pointing me in the direction of the system. I'll be using it. I'm always open to a compelling argument and a tap on the forehead that helps me to see the light. Many Thanks, Brandon On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependencies Options
For your reading pleasure: 1. You may reproduce and use the Software for Individual, Commercial, or Research and Instructional Use for the purposes of designing, developing, testing, and running Your applets and applications (Programs). 2. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the Software's documentation, You may reproduce and distribute Software, provided that: (a) you distribute the Software complete and unmodified and only bundled as part of Your Programs, (b) your Programs add significant and primary functionality to the Software, (c) you distribute Software for the sole purpose of running your Programs, (d) you do not distribute additional software intended to replace any component(s) of the Software, (e) you do not remove or alter any proprietary legends or notices contained in or on the Software. (f) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (g) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: Checking Sun Jars into your repo is a violation of the Sun Binary Compatibility License which you agreed to when you downloaded the file. (Assuming the file was downloaded from Sun under the Sun BCL terms, which most files on Sun.com require you to accept prior to downloading.) I doubt Sun will chase you down and prosecute you, but realize that some of us actually care about respecting intellectual property and license requirements. Complaining about the way these Sun Jars are handled to the Maven User list is really the wrong place -- complain directly to Sun, ask them to modify the distribution terms of their licenses, etc. Wayne On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: tons of advantages - please quantify this. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) Thanks to everyone for pointing me in the direction of the system. I'll be using it. I'm always open to a compelling argument and a tap on the forehead that helps me to see the light. Many Thanks, Brandon On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependencies Options
Hey Wayne, I'm sorry if my email tone sounds aggressive... i really am not trying to come off that way. So please accept my comments purely as an exercise in conversation. I totally understand the intellectual property that rights that Sun attaches to their jars. I fully respect them. I'm just trying to understand why so much emphasis is placed on the centralized jar repo. There were plenty of other concerns besides the sun jars that i cited. I'm just speaking more from my needs. The repo is cool. But, I see an equally acceptable approach of having jars that you check into your source code repo. I guess I'm trying more to understand why there is such an emphasis on central repo over simply presenting the ability to use either/or. As an additional note, the centralized repo is only as good as those willing to post to it. I've run into the problem that the latest and greatest are not always on ibiblio. I've also ran into the problem that there are sometimes version gaps. Also, I've seen where there are the same jars under different (but similar) group ids. I know i can setup a local repo for jars. But, then i find myself wondering why. Especially when i already have a versioning repository... SVN. Many thanks for your time and responses, Brandon On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: That should be Checking Sun Jars into your SVN repo. Obviously anyone is allowed to download the Sun Jars and install them into their own local Maven repo, or anything else permitted under the Sun BCL terms. Checking the jars into a publicly available distribution service ie Sourceforge CVS/SVN etc is unfortunately not allowed by Sun's licensing. You can go to Sun.com and read the specifics of the BCL if you want, to see what specifically is permitted and what is not. Wayne On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: Checking Sun Jars into your repo is a violation of the Sun Binary Compatibility License which you agreed to when you downloaded the file. (Assuming the file was downloaded from Sun under the Sun BCL terms, which most files on Sun.com require you to accept prior to downloading.) I doubt Sun will chase you down and prosecute you, but realize that some of us actually care about respecting intellectual property and license requirements. Complaining about the way these Sun Jars are handled to the Maven User list is really the wrong place -- complain directly to Sun, ask them to modify the distribution terms of their licenses, etc. Wayne On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: tons of advantages - please quantify this. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) Thanks to everyone for pointing me in the direction of the system. I'll be using it. I'm always open to a compelling argument and a tap on the forehead that helps me to see the light. Many Thanks, Brandon On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: Dependencies Options
No worries, Brandon. I have to run now but I'll be happy to continue the discussion later tonight... ;-) Wayne On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Hey Wayne, I'm sorry if my email tone sounds aggressive... i really am not trying to come off that way. So please accept my comments purely as an exercise in conversation. I totally understand the intellectual property that rights that Sun attaches to their jars. I fully respect them. I'm just trying to understand why so much emphasis is placed on the centralized jar repo. There were plenty of other concerns besides the sun jars that i cited. I'm just speaking more from my needs. The repo is cool. But, I see an equally acceptable approach of having jars that you check into your source code repo. I guess I'm trying more to understand why there is such an emphasis on central repo over simply presenting the ability to use either/or. As an additional note, the centralized repo is only as good as those willing to post to it. I've run into the problem that the latest and greatest are not always on ibiblio. I've also ran into the problem that there are sometimes version gaps. Also, I've seen where there are the same jars under different (but similar) group ids. I know i can setup a local repo for jars. But, then i find myself wondering why. Especially when i already have a versioning repository... SVN. Many thanks for your time and responses, Brandon On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: That should be Checking Sun Jars into your SVN repo. Obviously anyone is allowed to download the Sun Jars and install them into their own local Maven repo, or anything else permitted under the Sun BCL terms. Checking the jars into a publicly available distribution service ie Sourceforge CVS/SVN etc is unfortunately not allowed by Sun's licensing. You can go to Sun.com and read the specifics of the BCL if you want, to see what specifically is permitted and what is not. Wayne On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: Checking Sun Jars into your repo is a violation of the Sun Binary Compatibility License which you agreed to when you downloaded the file. (Assuming the file was downloaded from Sun under the Sun BCL terms, which most files on Sun.com require you to accept prior to downloading.) I doubt Sun will chase you down and prosecute you, but realize that some of us actually care about respecting intellectual property and license requirements. Complaining about the way these Sun Jars are handled to the Maven User list is really the wrong place -- complain directly to Sun, ask them to modify the distribution terms of their licenses, etc. Wayne On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: tons of advantages - please quantify this. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) Thanks to everyone for pointing me in the direction of the system. I'll be using it. I'm always open to a compelling argument and a tap on the forehead that helps me to see the light. Many Thanks, Brandon On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon
Re: Dependencies Options
Hi, I agree with much of what Brandon is saying. For *open source* projects, Maven's repository is really useful; the minor inconveniences are worth living with. In particular, such projects need to conserve disk space and network bandwidth; checking in jars for each project is therefore a bad idea. Brandon: imagine if Apache projects used the check jars in with project approach; the disk space needed would multiply 100-fold, with the same jar checked in multiple times under different projects. It also means that those files are all downloaded from the apache site, not ibiblio. And it means that users (who may be on dialup connections) end up downloading the same jars multiple times even when they already have those jars on their local PC. For *internal* projects, however, having local jars can be very useful. Bandwidth is less of an issue; simplicity and reproducable builds are more important. And as several people have noted on this list (and I've found from experience too) preventing maven from fetching stuff from repositories beyond your control is currently *really hard*. I think it would be really nice if repositories could have a remotefalse/remote tag; a non-remote repo (using any access protocol) would be used when offline mode is used. People could then check a complete maven repository into their project if they wish, and use a repository declaration with url file://..., remote set to false, and offline set to true. This wouldn't be recommended for sites that host large numbers of projects, as disk-space and bandwidth issues would cause problems, but it's then easy to set up self-contained builds for smaller sites. It's not *quite* as simple to use as simply checking in a directory of jars and pointing to that dir, but it's close - while still supporting much of maven's standard dependency support. Hmm..could the same effect be achieved by checking in an settings.xml with localRepository pointing to a checked-in dir, and running maven with mvn -s ./settings.xml? Brandon: Note that when using scopesystem/scope, transitive dependencies aren't supported. It's really meant only for pointing at files like rt.jar from a locally-installed jdk. That doesn't mean you can't use it for the purpose you want, but that's not its intent. Cheers, Simon On Mon, 2006-04-24 at 16:13 -0600, Brandon Goodin wrote: Hey Wayne, I'm sorry if my email tone sounds aggressive... i really am not trying to come off that way. So please accept my comments purely as an exercise in conversation. I totally understand the intellectual property that rights that Sun attaches to their jars. I fully respect them. I'm just trying to understand why so much emphasis is placed on the centralized jar repo. There were plenty of other concerns besides the sun jars that i cited. I'm just speaking more from my needs. The repo is cool. But, I see an equally acceptable approach of having jars that you check into your source code repo. I guess I'm trying more to understand why there is such an emphasis on central repo over simply presenting the ability to use either/or. As an additional note, the centralized repo is only as good as those willing to post to it. I've run into the problem that the latest and greatest are not always on ibiblio. I've also ran into the problem that there are sometimes version gaps. Also, I've seen where there are the same jars under different (but similar) group ids. I know i can setup a local repo for jars. But, then i find myself wondering why. Especially when i already have a versioning repository... SVN. Many thanks for your time and responses, Brandon On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: That should be Checking Sun Jars into your SVN repo. Obviously anyone is allowed to download the Sun Jars and install them into their own local Maven repo, or anything else permitted under the Sun BCL terms. Checking the jars into a publicly available distribution service ie Sourceforge CVS/SVN etc is unfortunately not allowed by Sun's licensing. You can go to Sun.com and read the specifics of the BCL if you want, to see what specifically is permitted and what is not. Wayne On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: Checking Sun Jars into your repo is a violation of the Sun Binary Compatibility License which you agreed to when you downloaded the file. (Assuming the file was downloaded from Sun under the Sun BCL terms, which most files on Sun.com require you to accept prior to downloading.) I doubt Sun will chase you down and prosecute you, but realize that some of us actually care about respecting intellectual property and license requirements. Complaining about the way these Sun Jars are handled to the Maven User list is really the wrong place -- complain directly to Sun, ask them to modify the distribution terms of their licenses, etc. Wayne On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote:
Re: Dependencies Options
On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: tons of advantages - please quantify this. Well distributing internal corporation dependencies and managing the version, especially nightly build is way easier using Maven repository capabilities. Managing your project dependencies version is also really easier (especially conflicts and snapshots). All the Maven generated reports also work better with regular dependencies because they can find some metadatas to work with. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. Nothing the exclude tag can't fix. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? You are making this sound like it is a lot of work. Manually installing files on a corporate repository using install:install-file usually doesn't take more time then checking them inside SVN. A maven repository is basically a Jar versionning systems. I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) If you have a remote Maven repository on the same server as your SVN repo, I really don't see the difference. Thanks to everyone for pointing me in the direction of the system. I'll be using it. I'm always open to a compelling argument and a tap on the forehead that helps me to see the light. Many Thanks, Brandon On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependencies Options
On 4/24/06, Simon Kitching [EMAIL PROTECTED] wrote: Hi, I agree with much of what Brandon is saying. For *open source* projects, Maven's repository is really useful; the minor inconveniences are worth living with. In particular, such projects need to conserve disk space and network bandwidth; checking in jars for each project is therefore a bad idea. Brandon: imagine if Apache projects used the check jars in with project approach; the disk space needed would multiply 100-fold, with the same jar checked in multiple times under different projects. It also means that those files are all downloaded from the apache site, not ibiblio. And it means that users (who may be on dialup connections) end up downloading the same jars multiple times even when they already have those jars on their local PC. For *internal* projects, however, having local jars can be very useful. Bandwidth is less of an issue; simplicity and reproducable builds are more important. And as several people have noted on this list (and I've found from experience too) preventing maven from fetching stuff from repositories beyond your control is currently *really hard*. Have you ever used the dependency exclude element? Or run Maven using the offline switch (-o)? I think it would be really nice if repositories could have a remotefalse/remote tag; a non-remote repo (using any access protocol) would be used when offline mode is used. People could then check a complete maven repository into their project if they wish, and use a repository declaration with url file://..., remote set to false, and offline set to true. This is already doable mvn -o. You just don't get the jar bundled with your project. This is the assembly plugin job. But I really don't get what you are trying to achieve. What is the difference between a internal corporation Maven repository and a internal corporation SVN repository setup on the same server? Nothing except Maven repository is better at handling dependencies then SVN. This wouldn't be recommended for sites that host large numbers of projects, as disk-space and bandwidth issues would cause problems, but it's then easy to set up self-contained builds for smaller sites. It's not *quite* as simple to use as simply checking in a directory of jars and pointing to that dir, but it's close - while still supporting much of maven's standard dependency support. Hmm..could the same effect be achieved by checking in an settings.xml with localRepository pointing to a checked-in dir, and running maven with mvn -s ./settings.xml? Brandon: Note that when using scopesystem/scope, transitive dependencies aren't supported. It's really meant only for pointing at files like rt.jar from a locally-installed jdk. That doesn't mean you can't use it for the purpose you want, but that's not its intent. Cheers, Simon On Mon, 2006-04-24 at 16:13 -0600, Brandon Goodin wrote: Hey Wayne, I'm sorry if my email tone sounds aggressive... i really am not trying to come off that way. So please accept my comments purely as an exercise in conversation. I totally understand the intellectual property that rights that Sun attaches to their jars. I fully respect them. I'm just trying to understand why so much emphasis is placed on the centralized jar repo. There were plenty of other concerns besides the sun jars that i cited. I'm just speaking more from my needs. The repo is cool. But, I see an equally acceptable approach of having jars that you check into your source code repo. I guess I'm trying more to understand why there is such an emphasis on central repo over simply presenting the ability to use either/or. As an additional note, the centralized repo is only as good as those willing to post to it. I've run into the problem that the latest and greatest are not always on ibiblio. I've also ran into the problem that there are sometimes version gaps. Also, I've seen where there are the same jars under different (but similar) group ids. I know i can setup a local repo for jars. But, then i find myself wondering why. Especially when i already have a versioning repository... SVN. Many thanks for your time and responses, Brandon On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: That should be Checking Sun Jars into your SVN repo. Obviously anyone is allowed to download the Sun Jars and install them into their own local Maven repo, or anything else permitted under the Sun BCL terms. Checking the jars into a publicly available distribution service ie Sourceforge CVS/SVN etc is unfortunately not allowed by Sun's licensing. You can go to Sun.com and read the specifics of the BCL if you want, to see what specifically is permitted and what is not. Wayne On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: Checking Sun Jars into your repo is a violation of the Sun Binary Compatibility License which you agreed to when you
Re: Dependencies Options
On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: tons of advantages - please quantify this. Well distributing internal corporation dependencies and managing the version, especially nightly build is way easier using Maven repository capabilities. Managing your project dependencies version is also really easier (especially conflicts and snapshots). All the Maven generated reports also work better with regular dependencies because they can find some metadatas to work with. Personally, I find the repository to be a nice piece of Maven. But, I don't see it as a cardinal sin to actually distribute libraries in your project. If you follow the libary naming convention then who cares? Personally, what i find annoying are the copious additional, needless, and redundant dependencies that i have to download because of the dependencies defined in the pom of a jar that i need to download. Nothing the exclude tag can't fix. I also find it annoying to have to manually install several small libraries to my local repo cuz i can't distribute them as a result of licensing. It is additionally annoying to have to setup a jar repository that will be used for jars that will be needed that can only be distributed privately. All of this... vs. me just referencing them in my source tree? You are making this sound like it is a lot of work. Manually installing files on a corporate repository using install:install-file wanted to say deploy:deploy-file usually doesn't take more time then checking them inside SVN. A maven repository is basically a Jar versionning systems. I like Maven a lot and really enjoy the standard project layout features and plugins that are provided. But, the jar repository has caused me more time and less efficiency. However, i do like ibiblio for a single one stop shop for grabbing jars i need... to drop in my source tree ;-) I like it when people can check out my source from SVN and simply build. This is possible when i place them in SVN. Heck, I can even check Sun Jars into my SVN repo! ;) If you have a remote Maven repository on the same server as your SVN repo, I really don't see the difference. Thanks to everyone for pointing me in the direction of the system. I'll be using it. I'm always open to a compelling argument and a tap on the forehead that helps me to see the light. Many Thanks, Brandon On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Well you can use *system* dependencies but you loose tons of advantages. Instead, maybe you should just populate your local repository using the install plugin and -o to run mvn offline. On 4/24/06, Brandon Goodin [EMAIL PROTECTED] wrote: Is it a requirement that i use the remote repository for jars? Is there a way to reference jars that are distributed with the code when checked out from the code repository? Brandon - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependencies Options
Just one more thing I dislike about system dependencies I wanted to specify. A good practice is usually to do a complete project check out after a check in. Takes a lot of times when you have several jars bundled with your projects. On 4/24/06, Alexandre Poitras [EMAIL PROTECTED] wrote: On 4/24/06, Simon Kitching [EMAIL PROTECTED] wrote: Hi, I agree with much of what Brandon is saying. For *open source* projects, Maven's repository is really useful; the minor inconveniences are worth living with. In particular, such projects need to conserve disk space and network bandwidth; checking in jars for each project is therefore a bad idea. Brandon: imagine if Apache projects used the check jars in with project approach; the disk space needed would multiply 100-fold, with the same jar checked in multiple times under different projects. It also means that those files are all downloaded from the apache site, not ibiblio. And it means that users (who may be on dialup connections) end up downloading the same jars multiple times even when they already have those jars on their local PC. For *internal* projects, however, having local jars can be very useful. Bandwidth is less of an issue; simplicity and reproducable builds are more important. And as several people have noted on this list (and I've found from experience too) preventing maven from fetching stuff from repositories beyond your control is currently *really hard*. Have you ever used the dependency exclude element? Or run Maven using the offline switch (-o)? I think it would be really nice if repositories could have a remotefalse/remote tag; a non-remote repo (using any access protocol) would be used when offline mode is used. People could then check a complete maven repository into their project if they wish, and use a repository declaration with url file://..., remote set to false, and offline set to true. This is already doable mvn -o. You just don't get the jar bundled with your project. This is the assembly plugin job. But I really don't get what you are trying to achieve. What is the difference between a internal corporation Maven repository and a internal corporation SVN repository setup on the same server? Nothing except Maven repository is better at handling dependencies then SVN. This wouldn't be recommended for sites that host large numbers of projects, as disk-space and bandwidth issues would cause problems, but it's then easy to set up self-contained builds for smaller sites. It's not *quite* as simple to use as simply checking in a directory of jars and pointing to that dir, but it's close - while still supporting much of maven's standard dependency support. Hmm..could the same effect be achieved by checking in an settings.xml with localRepository pointing to a checked-in dir, and running maven with mvn -s ./settings.xml? Brandon: Note that when using scopesystem/scope, transitive dependencies aren't supported. It's really meant only for pointing at files like rt.jar from a locally-installed jdk. That doesn't mean you can't use it for the purpose you want, but that's not its intent. Cheers, Simon On Mon, 2006-04-24 at 16:13 -0600, Brandon Goodin wrote: Hey Wayne, I'm sorry if my email tone sounds aggressive... i really am not trying to come off that way. So please accept my comments purely as an exercise in conversation. I totally understand the intellectual property that rights that Sun attaches to their jars. I fully respect them. I'm just trying to understand why so much emphasis is placed on the centralized jar repo. There were plenty of other concerns besides the sun jars that i cited. I'm just speaking more from my needs. The repo is cool. But, I see an equally acceptable approach of having jars that you check into your source code repo. I guess I'm trying more to understand why there is such an emphasis on central repo over simply presenting the ability to use either/or. As an additional note, the centralized repo is only as good as those willing to post to it. I've run into the problem that the latest and greatest are not always on ibiblio. I've also ran into the problem that there are sometimes version gaps. Also, I've seen where there are the same jars under different (but similar) group ids. I know i can setup a local repo for jars. But, then i find myself wondering why. Especially when i already have a versioning repository... SVN. Many thanks for your time and responses, Brandon On 4/24/06, Wayne Fay [EMAIL PROTECTED] wrote: That should be Checking Sun Jars into your SVN repo. Obviously anyone is allowed to download the Sun Jars and install them into their own local Maven repo, or anything else permitted under the Sun BCL terms. Checking the jars into a publicly available distribution service ie Sourceforge CVS/SVN
