- This topic has 21 replies, 10 voices, and was last updated 20 years ago by
.
-
Posts
-
Please introduce this fieature as soon as possible. This is a very important
concept (surprisingly missing from the core eclipse) – to the point that it greatly reduced usability of Eclipse.That is true, but user defined libraries added to the project are not packed into to WEB-INF/lib! In the preferences, there is an option Always deploy external libraries and place in the lib directory when deploying. This does not apply to user defined libraries!
If you care about external libraries, you have also do that for user defined libraries in Eclipse 3.0!!!!
User libraries can typically be used for resources that cannot be deployed, and are only needed for compile-time dependencies, like the J2EE Libraries, DB Drivers, etc…. all these libraries are provided by your application server, and while they are needed for development should not be deployed.
If your applications requires a library, then it 1) must be in the WEB-INF/lib directory OR 2) be a dependent Java project OR 3) be an external lib… all of these resources are automatically deployed… I’m not sure what problem you are currently having that is not covered by these 3 different ways of deploying dependencies. Can you explain your situation a little more clearly?
I have a project with Libraries for Spring, Hibernate, MySQL, Log4J, Commons Lang, Commons Validate. That includes about 50 jars. If I define those jars as external libraries, I have cluttered the whole screen of a 20″ screen with those jars. With a user defined library, I can hide all libraries for Hibernate (32) into a single entry in the class path. For me, external jars and user defined jars provides the same functionality – they expand the class path.
So I see no problem with adding user defined libraries to WEB-INF/lib – or adding the fourth way to handle jars.
So I see no problem with adding user defined libraries to WEB-INF/lib – or adding the fourth way to handle jars.
Well that’s the point… all the libraries you just mentioned are required by your web application, they should be in your WEB-INF/lib directory anyway so they will be deployed regardless of them being in a user library or not.
Also you don’t have to clutter your screen with JARs if you just add a “jar” string filter to the package view. (this is a FYI incase you hadn’t tried it, I’m not suggesting it as a workaround)
@support-rkalla wrote:
User libraries can typically be used for resources that cannot be deployed
Yes, thay can. And they can also be used for something else too, like libraries that do need to be deployed.
and are only needed for compile-time dependencies, like the J2EE Libraries, DB Drivers, etc…
Says who? Sorry, I missed that reference. You have a link?
If your applications requires a library, then it 1) must be in the WEB-INF/lib directory OR 2) be a dependent Java project OR 3) be an external lib…
Yes, that’s exactly the problem. Your deployment capabilities are limited to the three scenarios you list. We need the option of deploying User Defined Libraries as well. Want a reason why? I’ve got 20 web apps, classic 2-tier. Each one needs the db driver lib, reporting libs, and a handful of other jars. Do I define all of these once, as user libraries, or do I manually copy them into WEB-INF/lib or add them as external jars 20 times? User Libraries are a convenience for developers — their power is that they allow us to be able to define once and only once commonly used libs, i.e., libs used across many projects. And when we define a user lib as a project dependency, it is a real project dependency. And as such, you should provide the option of deploying all real project dependencies.
Make the web project dependent on the other project(s), and then those will get deployed…
Regards,
Robert
@robvarga wrote:
Make the web project dependent on the other project(s), and then those will get deployed…
Yes, that has been tested and is proven to work. This thread, however, is about deployment of user-defined libraries. User-defined libraries should not be replaced by ad-hoc projects. They are not projects — many are proprietary and do not have source code. Creating a project made up solely of a bunch of external jars provides a workaround, but we already have workarounds, and yet another kludge is not particularly eye-opening.
BTW, the explanation I received is that user-defined libraries are new and the MyEclipse team has simply not had time to implement their deployment. My understanding is that the team is working on getting this feature in. If so, why are members of MyEclipse defending the position of not doing so?
@ayampols wrote:
@robvarga wrote:
Make the web project dependent on the other project(s), and then those will get deployed…
Yes, that has been tested and is proven to work. This thread, however, is about deployment of user-defined libraries. User-defined libraries should not be replaced by ad-hoc projects. They are not projects — many are proprietary and do not have source code. Creating a project made up solely of a bunch of external jars provides a workaround, but we already have workarounds, and yet another kludge is not particularly eye-opening.
That is what I was about to suggest.
@ayampols wrote:
BTW, the explanation I received is that user-defined libraries are new and the MyEclipse team has simply not had time to implement their deployment. My understanding is that the team is working on getting this feature in. If so, why are members of MyEclipse defending the position of not doing so?
I guess they are rather trying to suggest you some workarounds so that
you are able to proceed with your work until they implement that feature, and also trying to explain what was the reason why they did not think about it at once.The other (and more serious) possible reason why it got omitted is that if they automatically include user libraries, you cannot leave out those which are present before deployment (jdbc driver, rt.jar, tools.jar, j2ee jars, etc), and including those libraries in deployment can make problems.
Therefore deploying user libraries which you should not have deployed can prove worse than not deploying some which should have been deployed.You can work around the omission of user libraries, as described in the thread. You cannot work around automatic inclusion of libraries. So unless user libraries can be omitted on a one-by-one basis, automatic inclusion of user libraries is useless, since it would cause problems, and therefore you would have switched it off anyway, and we are back to step one.
My experience with them is that they don’t usually stick to their opinions if you can convince them otherwise, and they will implement features that are requested of them.
This is definitely a worthy feature, and I also second the request for this with the extension that you should be able to select which User libraries you want and don’t want to deploy (in each project independently of each other).
ayampols,
As Rob has correctly pointed out, we are user-driven. I wasn’t defending our position for not having the feature, if 200 people asking for the ability to deploy a webapp to /dev/null, even if we don’t understand why, we’ll still implement it. I honestly was just trying to figure out what the use case that justified this situation was, the developers need to recreate situations and use cases to see if they have implemented a feature correctly, and as support, we need to know how to test it and how to work around any problems.My experience with webapps is that if a webapp requires libs like Struts or Hibernate, then that webapp has all those libs under its WEB-INF/lib directory. Wether its 1 app, 2 apps or 20 apps as you pointed out. So when you asked about “copying it into WEB-INF/lib 20 times”, my initial impression was “Yes, where else would they be?”, but I can understand if you have a custom environment where you setup a few user libs, add them to all your projects, and then have an ant script to build out deployable apps at deploy-time (or in this case, have our deployment tool copy out the libs for you) then that makes sense. I wasn’t clear on this earlier.
Given that use case, I can definately see why you want this feature, its a real PIA to deploy without it. I’ll add a +1 to this in our tracker.
@robvarga wrote:
The other (and more serious) possible reason why it got omitted is that if they automatically include user libraries, you cannot leave out those which are present before deployment (jdbc driver, rt.jar, tools.jar, j2ee jars, etc)
Really? I haven’t looked into the mechanics of it, but the UI makes a clear distinction between “user-defined libraries” and J2EE/JRE library sets. A clean installation has 0 user-defined libraries present. If the UI can make the distinction, can’t MyEclipse as well? And if for some strange reason you don’t want to deploy a dependency, make it a regular jar. It’s a workaround in the reverse, and won’t get deployed.
This is definitely a worthy feature, and I also second the request for this with the extension that you should be able to select which User libraries you want and don’t want to deploy (in each project independently of each other).
That would be nice. Deployment preferences do deserve a more in depth pane.
ayampols,
The Library Sets provided by MyEclipse were provided as a workaround to the lack of them in Eclipse 2 and 3.0 early dev series. Now that Eclipse official supports them, we will likely adapt to the Eclipse provided libraries, so i’ve added a note that deployment of user libs must be configurable on a lib-by-lib basis.@support-rkalla wrote:
So when you asked about “copying it into WEB-INF/lib 20 times”, my initial impression was “Yes, where else would they be?”
No way! I do not manually place anything anywhere! I use the tool to set up dependencies, and my project’s WEB-INF/lib never contains a thing. And I always make sure that my preferences are set to ignore whatever is in there just in case, because I want to have total control of development and deployment via the tool’s mechanisms only. What’s the point of the GUI if you have to move your libs around on the file system? There’s a perfectly good build path pane, and that’s what I use.
Where are the libs, you ask? They are in their original installed locations. Only during deployment does the tool copy them to their respective deployment locations, of which I should be able to be blissfully unaware. 8)@ayampols wrote:
@robvarga wrote:
The other (and more serious) possible reason why it got omitted is that if they automatically include user libraries, you cannot leave out those which are present before deployment (jdbc driver, rt.jar, tools.jar, j2ee jars, etc)
Really? I haven’t looked into the mechanics of it, but the UI makes a clear distinction between “user-defined libraries” and J2EE/JRE library sets. A clean installation has 0 user-defined libraries present. If the UI can make the distinction, can’t MyEclipse as well? And if for some strange reason you don’t want to deploy a dependency, make it a regular jar. It’s a workaround in the reverse, and won’t get deployed.
The only off-the-shelf library set in Eclipse is the rt.jar.
The only off-the-shelf library set in MyEclipse is the J2EE libraries. Neither of those are deployed.JDBC drivers, tools.jar, whatever else are only manually creatable library sets.
Neither the workbench nor the MyEclipse extension knows anything about it, whether you should deploy it or not, hence they are unable to make the distinction about the necessity of their deployment.Even the J2EE libraries should be replaced with User libraries that do NOT get deployed, since currently you have one single set of J2EE libraries which ties you either to standard J2EE only classes, or to one specific application server.
It also is the cause of one bug in the JSP compiler/editor couple, which is almost impossible to track down, since it pops up randomly, therefore I was not able to make a reproducible test case for that.
If user libraries are always deployed then you are again in the same situation that you have a jar copied into the project. Only this time you don’t even want to deploy that, contrary to the alternative situation of having a jar in the project which at least will be deployed.
I think, if I have to choose between two bad solutions, I would rather choose the current ones, that is jar in the project which is deployed, user library if it is not deployed.Of course the proper solution is what we arrived to: configure in each deployment record (per project at least), which user libraries need to be deployed with that project.
Regards,
Robert
