Menu
▾
▴
jboss-dev-forums
|
From: <mcu...@jb...> - 2006-06-22 16:31:49
|
Also one thing I forgot to add.. Max had previously mentioned that this standardization could also be added through the use of WTP facets (project natures++). Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952736#3952736 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952736 |
|
From: <max...@jb...> - 2006-06-25 15:18:11
|
"mcu...@jb..." wrote : | 1) Make a standard "JBoss (JEMS?)" runtime wizard that is accesible through the "Libraries" wizard page in a Java projects build path. | AFAIK there is no extension point for this page - do you know the name of it or ? anonymous wrote : | ...would provide extension points that all of our runtimes could register with. The wizard will allow the user to either setup the runtime as an external dependency (AKA classpath container) OR import/copy those libraries into a user specified directory within their project. | Sounds like some code/logic that should be shared/delegatable to a WTP facets implementation. anonymous wrote : | 2) Try to distribute "interface" JARs where it makes sense.. mostly for the EJB3 plugin right now. Also put pressure on our runtime developers to provide us with lightweight interfaces so runtime distribution is left to a minimum. (Only HibernateTools and AOP actually need the runtime to work ATM) | I do not understand what this point is about ? How can we live with just "interface" JAR's when it is something the users projects need to run against ? (either we distribute or not ;) anonymous wrote : | 3) We left off on distribution. We basically have 3 different methods of obtaining a runtime currently: | 1. Put runtime jars in CVS/SVN | 2. Download/copy runtime jars from repository.jboss.com into plugin | 3. Let user download/register their runtime after installation | I have a distinct feeling that you have a different concept of runtime than me ;) For me "runtime" libraries is *only* about which libraries *users* need for their projects. #3 sounds more like a mix on how we get libraries for the JBossIDE plugins into the build and how users can select something else ? anonymous wrote : | #3 should probably be left for "runnable" runtimes i.e. JBossAS and the jBPM Server. I suggest we keep with #1 for plugins that need to distribute runtime w/ the plugin, but this is definately still up for discussion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953284#3953284 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953284 |
|
From: <koe...@jb...> - 2006-07-03 14:07:16
|
Max, There is another category of 'runtime' libs IMO. Namely the libs that a user needs to *develop* his application that later will be run against a 'runtime'. e.g. A user wants to develop a pure servlet application. The library he needs in his project is only the servlet-api.jar. If he wants to run his application, he needs all the Tomcat jars. What we were talking about during this meeting is that it would be good to minimize the amount of jars included (either by a classpath container or by copying them locally) in the project. It would be good to only have a 'lightweight interface' jar that includes the api classes and not the implementation details of the used technology. As for the Facet stuff, is there any easy example or pointer you can provide that can shed some light on this solution? Regards, Koen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955057#3955057 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955057 |
|
From: <max...@jb...> - 2006-07-04 19:18:08
|
For me api.jar's is part of runtime-libs. In what situations do we have a situation where it is not clear if you want to devel against api's or impl's ? (it might be obvious but i can't think of anyone right now ;) i'll try and dig out the facet stuff when i get back - but i've send all I've stumbled upon to the dev-ide list at "some point in time" :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955335#3955335 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955335 |
|
From: <koe...@jb...> - 2006-07-05 12:42:44
|
The obvious case where you want to develop against api and not against impl's is for all of the jee standard stuff... You don't need all of the JBoss runtime classes in the classpath of your project in order to develop a jee app. Also, if you develop a pure jee app using the api jars, it should be fairly easy to port them between JBoss 4.0.x versions. This is (at this point) not possible easily with e.g. jBPM in the first part because of the non-existence of a jBPM-api.jar. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955483#3955483 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955483 |
|
From: <max...@jb...> - 2006-07-05 16:24:04
|
All of those situations is *clear* for me (except the jbpm.jar) ;) When do you not need to run against the jbpm.jar in e.g. your unittests ? What i'm trying to say is that for me there still are only two kind of libs in this discussion: libs for the IDE and libs for the users development/runtime. The last part is of course not just one big bundle of jars, but very much dependent on what kind/"facet" of development the user is doing - this is where Facet's become usefull since you here can define different "configurations" or simply just "facets". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955579#3955579 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955579 |
|
From: <max...@jb...> - 2006-07-07 10:00:25
|
Facet tutorial with code and slides: http://www.eclipsecon.org/2006/Sub.do?id=241 And here is a snippet from Konstantin (the guy behind the facets) on how to enable facets for non-WTP projects. There exists an api for converting an existing project into a faceted project. That api is... import org.eclipse.wst.common.project.facet.core.ProjectFacetsManager; import org.eclipse.wst.common.project.facet.core.IFacetedProject; final IFacetedProject fpj = ProjectFacetsManager.create( , true, <IProgressMonitor ) That will make the project "facet-enabled", but will not install any facets, set any facets as fixed, or associate the project with a runtime. To then install a java facet, you can do this: import org.eclipse.jst.common.project.facet.JavaFacetUtils; fpj.installProjectFacet( JavaFacetUtils.JAVA_50, null, ) Adjust appropriately depending on which version of the java facet you want. Converting an existing project into a faceted project and auto-detecting which facets should be install is not a typical WTP usecase, so we have no neat api for doing all of this or the associated ui. Thus, if you roll out this functionality, you would not be duplicating anything. Depending on how generic you make it, it may be appropriate to push it down into WTP. Hope that answers your questions. Let me know if you have any other. Thanks, - Konstantin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3956127#3956127 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3956127 |
|
From: <max...@jb...> - 2006-07-07 10:01:13
|
note that i'm not 100% sure facet is the answer to everything, but it at least is a good way to integrate into the built-in "configurability" of WTP View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3956129#3956129 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3956129 |
Thanks for helping keep SourceForge clean.
X