Home » Language IDEs » Java Development Tools (JDT) » how to manage external jars?
| how to manage external jars? [message #214906] |
Fri, 16 September 2005 12:25  |
Eclipse User |
|
|
|
Originally posted by: jwoofy.hotmail.com
I've been using Eclipse for a year and love it. I'd like to know if what's
the best practice for an organization problem. I include a number of open
source jars: log4j, etc. For every project, I add the jars to my build
path. What do Eclipse experts suggest?
I'm considering putting all my external jars in one project, then adding
that project to the build path.
Thanks
--
Jeff
|
|
|
| Re: how to manage external jars? [message #214920 is a reply to message #214906] |
Fri, 16 September 2005 14:28  |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
You can create a userLibrary containing all of the jars and then add the
userLibrary to your project. It is like a project except you don't need
to create a project for it.
Jeff wrote:
> I've been using Eclipse for a year and love it. I'd like to know if what's
> the best practice for an organization problem. I include a number of open
> source jars: log4j, etc. For every project, I add the jars to my build
> path. What do Eclipse experts suggest?
>
> I'm considering putting all my external jars in one project, then adding
> that project to the build path.
>
> Thanks
>
--
Thanks,
Rich Kulp
|
|
|
| Re: how to manage external jars? [message #214948 is a reply to message #214906] |
Fri, 16 September 2005 20:13 |
| Eclipse User |
|
|
|
Originally posted by: eclipse3.rizzoweb.com
Jeff wrote:
> I've been using Eclipse for a year and love it. I'd like to know if what's
> the best practice for an organization problem. I include a number of open
> source jars: log4j, etc. For every project, I add the jars to my build
> path. What do Eclipse experts suggest?
>
> I'm considering putting all my external jars in one project, then adding
> that project to the build path.
I've tried that, and it works to an extent. Problems arise if you have
different projects that depend on different versions of the same common
libs.
Now I tend to put dependent JARs in the lib directory of each project
(or if I have several related projects that all depend on one "parent"
project, then in the lib of the "parent" project).
Besides being able to handle the differing versions problem, I always
strive to have everything needed to build a project encapsulated so it
can be checked out of SCM and built with minimal set-up required. If
third-party libs live externally or have to be depended on from another
Project, it makes that goal harder to achieve.
HTH,
Eric
|
|
|
| Re: how to manage external jars? [message #214962 is a reply to message #214948] |
Fri, 16 September 2005 21:27 |
| Eclipse User |
|
|
|
Originally posted by: oliverm.sourceonenet.com
I use the Eclipse java build path variables to point to my external jars,
but I also find that many times it is better to put them in a /lib/ folder
in my project if there are multiple versions or dependencies.
Use of the variable names means I can upgrade ALL the projects that use that
library with one change.
"Eric Rizzo" <eclipse3@rizzoweb.com> wrote in message
news:dgf955$hgd$1@news.eclipse.org...
> Jeff wrote:
>> I've been using Eclipse for a year and love it. I'd like to know if
>> what's the best practice for an organization problem. I include a number
>> of open source jars: log4j, etc. For every project, I add the jars to
>> my build path. What do Eclipse experts suggest?
>>
>> I'm considering putting all my external jars in one project, then adding
>> that project to the build path.
>
> I've tried that, and it works to an extent. Problems arise if you have
> different projects that depend on different versions of the same common
> libs.
> Now I tend to put dependent JARs in the lib directory of each project (or
> if I have several related projects that all depend on one "parent"
> project, then in the lib of the "parent" project).
> Besides being able to handle the differing versions problem, I always
> strive to have everything needed to build a project encapsulated so it can
> be checked out of SCM and built with minimal set-up required. If
> third-party libs live externally or have to be depended on from another
> Project, it makes that goal harder to achieve.
>
> HTH,
> Eric
|
|
|
| Re: how to manage external jars? [message #215028 is a reply to message #214948] |
Sat, 17 September 2005 11:12 |
| Eclipse User |
|
|
|
Originally posted by: thhal.mailblocks.com
Eric Rizzo wrote:
> Jeff wrote:
>
>> I've been using Eclipse for a year and love it. I'd like to know if
>> what's the best practice for an organization problem. I include a
>> number of open source jars: log4j, etc. For every project, I add the
>> jars to my build path. What do Eclipse experts suggest?
>>
>> I'm considering putting all my external jars in one project, then
>> adding that project to the build path.
>
>
> I've tried that, and it works to an extent. Problems arise if you have
> different projects that depend on different versions of the same common
> libs.
> Now I tend to put dependent JARs in the lib directory of each project
> (or if I have several related projects that all depend on one "parent"
> project, then in the lib of the "parent" project).
> Besides being able to handle the differing versions problem, I always
> strive to have everything needed to build a project encapsulated so it
> can be checked out of SCM and built with minimal set-up required. If
> third-party libs live externally or have to be depended on from another
> Project, it makes that goal harder to achieve.
>
> HTH,
> Eric
You solve one problem but create another. You risk getting into the "jar
copy hell", not very different from when you copy and paste source-code
instead of doing sane refactoring. I always advocate to that jars must
be maintained separately and not be copied into each and every project
that uses them. The more complex your environment get, the harder you'll
have to maintain all the copies, their versions, inter-dependencies,
origins, etc.
The real problem is that Eclipse in itself doesn't have a good tool to
handle external dependencies dynamically. Tools like Maven and Ivy will
address this problem to some extent. They will also allow the you to
have simultanious dependencies to different versions of the same jar.
You might be interesed in the new Eclipse Technology project Buckminster
that had its first milestone release a week ago (see
www.eclipse.org/buckminster for more info). One of its objectives is to
bring order into how external jars can be managed regardless of how
where you find them.
Kind regards,
Thomas Hallgren
|
|
|
| Re: how to manage external jars? [message #215107 is a reply to message #215028] |
Mon, 19 September 2005 14:30 |
| Eclipse User |
|
|
|
Originally posted by: eclipse3.rizzoweb.com
Thomas Hallgren wrote:
> Eric Rizzo wrote:
>
>> Jeff wrote:
>>
>>> I've been using Eclipse for a year and love it. I'd like to know if
>>> what's the best practice for an organization problem. I include a
>>> number of open source jars: log4j, etc. For every project, I add
>>> the jars to my build path. What do Eclipse experts suggest?
>>>
>>> I'm considering putting all my external jars in one project, then
>>> adding that project to the build path.
>>
>>
>>
>> I've tried that, and it works to an extent. Problems arise if you have
>> different projects that depend on different versions of the same
>> common libs.
>> Now I tend to put dependent JARs in the lib directory of each project
>> (or if I have several related projects that all depend on one "parent"
>> project, then in the lib of the "parent" project).
>> Besides being able to handle the differing versions problem, I always
>> strive to have everything needed to build a project encapsulated so it
>> can be checked out of SCM and built with minimal set-up required. If
>> third-party libs live externally or have to be depended on from
>> another Project, it makes that goal harder to achieve.
>>
>> HTH,
>> Eric
>
> You solve one problem but create another. You risk getting into the "jar
> copy hell", not very different from when you copy and paste source-code
> instead of doing sane refactoring. I always advocate to that jars must
> be maintained separately and not be copied into each and every project
> that uses them. The more complex your environment get, the harder you'll
> have to maintain all the copies, their versions, inter-dependencies,
> origins, etc.
All the more reason, IMO, to let each project have its own lib
directory. That encapsulates the dependencies within each project
instead of trying to manage them globally.
Besides, as I said, a primary goal I always have when setting up a new
project is to minimize the amount of work between no workspace and
getting a successful build (note that seldom is Eclipse set-up enough to
get a successful build - there is almost always a more comprehensive
build step, such as an Ant script). Having to point to global locations
of libraries does not fit well with that goal.
> The real problem is that Eclipse in itself doesn't have a good tool to
> handle external dependencies dynamically.
Actually, that is exactly what the User Libraries and Classpath
Variables features are for. They may not be everything to everybody, but
they were created to address the issue of external libraries.
> You might be interesed in the new Eclipse Technology project Buckminster
> that had its first milestone release a week ago (see
> www.eclipse.org/buckminster for more info). One of its objectives is to
> bring order into how external jars can be managed regardless of how
> where you find them.
Yes, I'm watching it out of the corner of my eye. However I've developed
some personal best practices and "patterns" of project setup over the
years with Eclipse, and they work well for me for now. I'll wait until
Buckminster goes 1.0 to seriously evaluate it.
Eric
|
|
|
| Re: how to manage external jars? [message #215213 is a reply to message #215107] |
Tue, 20 September 2005 10:10 |
| Eclipse User |
|
|
|
Originally posted by: thhal.mailblocks.com
Hi Eric,
Some comments inline:
Eric Rizzo wrote:
>> You solve one problem but create another. You risk getting into the
>> "jar copy hell", not very different from when you copy and paste
>> source-code instead of doing sane refactoring. I always advocate to
>> that jars must be maintained separately and not be copied into each
>> and every project that uses them. The more complex your environment
>> get, the harder you'll have to maintain all the copies, their
>> versions, inter-dependencies, origins, etc.
>
>
> All the more reason, IMO, to let each project have its own lib
> directory. That encapsulates the dependencies within each project
> instead of trying to manage them globally.
There's a reason why you split your code into projects instead of just
one big monolith. IMO, the fact that some 'projects' are in another form
should not make them more eligable for inclusion in other projects.
Small development shops might be OK working the way you suggest but it
doesn't scale. Assume that you work together with many different teams.
There's really no need for you to use the source code control system and
always download the source for each and every component. Perhaps you
dont' even have access to some of it (or to what's required in order to
build it).
Wouldn't it be great if you seamlessly could pick pre-compiled binaries
(jars, shared objects, formatted documentation, or whatever) produced by
the other teams instead?
> Besides, as I said, a primary goal I always have when setting up a new
> project is to minimize the amount of work between no workspace and
> getting a successful build (note that seldom is Eclipse set-up enough to
> get a successful build - there is almost always a more comprehensive
> build step, such as an Ant script). Having to point to global locations
> of libraries does not fit well with that goal.
>
You need a tool that can generate property files that can be included in
your ant-scripts (or makefiles). The property file can contain the
location of the external components that you depend on and perhaps also
a classpath that makes it easy for you to integrate. I.e.
Buckminster has incremental builders that will fulfill this purpose.
>
>
>> The real problem is that Eclipse in itself doesn't have a good tool to
>> handle external dependencies dynamically.
>
>
> Actually, that is exactly what the User Libraries and Classpath
> Variables features are for. They may not be everything to everybody, but
> they were created to address the issue of external libraries.
>
While they help you appoint jars on your local harddrive, they don't
give you any support that can help you maintain them. New versions pop
up all the time.
Your source-code is typically maintained in a CVS repository or similar
and you get a new version of it simply by doing an "update". In order to
work efficiently, you need similar functionality for all components.
Imagine a tool that would help you see what's new out there with respect
to your dependencies and assist you in downloading.
>
>> You might be interesed in the new Eclipse Technology project
>> Buckminster that had its first milestone release a week ago (see
>> www.eclipse.org/buckminster for more info). One of its objectives is
>> to bring order into how external jars can be managed regardless of how
>> where you find them.
>
>
> Yes, I'm watching it out of the corner of my eye.
Great!
> However I've developed
> some personal best practices and "patterns" of project setup over the
> years with Eclipse, and they work well for me for now. I'll wait until
> Buckminster goes 1.0 to seriously evaluate it.
>
Please convey any thoughts that you may have to us. It's hard to
anticipate everyones needs and your input would be very valuable to us.
Regards,
Thomas Hallgren
|
|
|
| Re: how to manage external jars? [message #215252 is a reply to message #215213] |
Tue, 20 September 2005 15:39 |
| Eclipse User |
|
|
|
Originally posted by: eclipse3.rizzoweb.com
Thomas Hallgren wrote:
> Eric Rizzo wrote:
>
>> All the more reason, IMO, to let each project have its own lib
>> directory. That encapsulates the dependencies within each project
>> instead of trying to manage them globally.
>
> There's a reason why you split your code into projects instead of just
> one big monolith. IMO, the fact that some 'projects' are in another form
> should not make them more eligable for inclusion in other projects.
>
> Small development shops might be OK working the way you suggest but it
> doesn't scale. Assume that you work together with many different teams.
> There's really no need for you to use the source code control system and
> always download the source for each and every component. Perhaps you
> dont' even have access to some of it (or to what's required in order to
> build it).
This is an apples and oranges thing. You're talking about a very
different problem, one that does not concern me, to be honest. I do not
want to build libraries - I assume binaries are available and use them.
>
> Wouldn't it be great if you seamlessly could pick pre-compiled binaries
> (jars, shared objects, formatted documentation, or whatever) produced by
> the other teams instead?
Might be nice sometimes, but in reality not that big of a deal on any
team I've ever worked on. I think it is a bit of a lofty goal. Not sure
it is feasible to solve in a universal way. If that is what Buckminster
is aiming for, then more power to it - but as I said I don't have need
or desire to look at such a project until it has delivered at least a
majority of what that kind of tool would involve.
>> Besides, as I said, a primary goal I always have when setting up a new
>> project is to minimize the amount of work between no workspace and
>> getting a successful build (note that seldom is Eclipse set-up enough
>> to get a successful build - there is almost always a more
>> comprehensive build step, such as an Ant script). Having to point to
>> global locations of libraries does not fit well with that goal.
>>
> You need a tool that can generate property files that can be included in
> your ant-scripts (or makefiles). The property file can contain the
> location of the external components that you depend on and perhaps also
> a classpath that makes it easy for you to integrate. I.e.
>
> Buckminster has incremental builders that will fulfill this purpose.
At some point a developer has to configure/maintain such a tool, which
is what I strive to minimize. In practice, I always set up build scripts
to use properties files with the bare minimum required configuration -
it is not something that I've needed a tool to do for me, because the
Ant scripts I write are all consistent in their usage of such features.
> Your source-code is typically maintained in a CVS repository or similar
> and you get a new version of it simply by doing an "update". In order to
> work efficiently, you need similar functionality for all components.
> Imagine a tool that would help you see what's new out there with respect
> to your dependencies and assist you in downloading.
As I said above, we're talking apples and oranges. I am not interested
in always using the latest version of a library that my projects depend
on. In fact, for some libraries that can be a productivity killer as you
constantly try to stay up to date with changing APIs, feature sets,
config file formats, etc. Furthermore, dependencies are often linked to
another library a project is already dependent on (for example, Struts
versions depend on specific versions of other Jakarta libs - that puts
limitations on what the project can use and makes automated management a
very lofty goal).
I have nothing against what (it appears to me) Buckminster is trying to
do - I just have no need for it. I also am skeptical if it can actually
be done in a reasonable amount of time (and code) and such that it only
requires a small amount of user oversight to be useful. If it is pulled
off, I'll be impressed and evaluate it for my own use.
Eric
|
|
|
Goto Forum:
Current Time: Sat Dec 21 16:42:46 GMT 2024
Powered by FUDForum. Page generated in 0.04306 seconds |
] 
Search
Help
Register
Login
Home
