"mculpepper@jboss.com" wrote:

1) Make a standard "JBoss (JEMS?)" runtime wizard that is accesible through the "Libraries" wizard page in a Java projects build path.

...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.

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)

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

#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.

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

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" :)

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.

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".

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

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