[jbosstools-dev] Re: Feedback/Questions on jbtools-200804160015-nightly

[Max Rydahl Andersen]

> My first email to JBoss Tools Dev list, so be gentle :)

I'll try ,)

btw. for ya'all Galder is one of our support engineers in Neuchatel which
I convinced to take our new stuff for a ride so we could get some more reallife
input ;)

> 1.- Is there any specific ordering to the runtime libraries in the
> classpath? Why do I wanna do that? The most efficient way to add source
> folders is to have client/jbossall-client.jar first. Then, as source
> folder for this, you go to the root of your EAP/AS svn checkout and find
> source recursively. Any classes that are not in jbossall-client.jar can
> be added later, for example for jboss-aop-jdk5.jar.

The runtime libraries entry in the classpath is basically just a **/*.jar
of the proper jboss server. I initially wanted to keep that list of jars
very restricted but for various reasons in WTP it turned out not to be doable.
We didn't add too much features to this runtime since it would basically then
duplicate alot of what is already possible via user-libraries.

We should proabably look into have more intelligent classpath libraries for
our runtime classpath container...

> If you can't put jbossall-client.jar first, you end up having to go
> through each individual client jar and add source folder for that. This
> can be quite a pain in the ass if you're debugging client side calls.

That classpath container is just a classpath container, meaning you can
remove it and add something else, e.g. a user library which orders and setup
the jars just like you want it.

> 2.- Project Archives view is misleading -> Shown Filesets are not
> accurate (see "project-archive-view-misleading-1.png"), where's the
> excluded patterns? It only shows included patterns.

Good catch - please put that in jira.

> 3.- .svn/ and CVS/ folders should be excluded from filesets by default.
> Maybe an option in preferences of Project Archives?

I understand the reasoning but having a set of global default excludes will 
make the packaging non-deterministic.

What I would suggest is that you could set this per archive and then set those
as defaults for new archives which users can adapt to their needs.

Put that in jira too.

> 4.- When you create an EJB project, if the ejb-jar.xml is located in
> [project-name]/[source-folder]/META-INF/ejb-jar.xml, jdbs shows a nice
> preview of it (see "Deployment Descriptor" at the bottom left of
> "ejb-jar-xml-preview.png"). This does not happen if the ejb-jar.xml is
> located somewhere else. Is this configurable?

This is the Project Explorer that is showing the WTP project model which
over time also will integrate information from Java annotations and thus 
its more than just what is in ejb-jar.xml.

The reason it does not show anything when the file is not in that location
is because that is the assumed standard location...and you got more than one
so which one should it pick up ?

In any case what we try to do for most file types is that you can explore them
directly. e.g. we can browse faces-config.xml and hbm.xml files in the project explorer
without opening them.

> 5.- Is there a way to convert a eclipse java project into an ejb project
> automatically? All my projects are currently java projects and wanna
> migrate them to faced projects depending on what they do. Currently, I'm
> having to create a sample project of each type, take .classpath,
> .project...and other files and inject them into my original project.
> This is a pain in the ass.

I don't think this exist in a usable way in WTP.

> 6.- What does this warning really mean? "CHKJ2905W: The EJB Validator
> did not run because ejb-jar.xml could not be loaded. Run the XML
> validator for more information.". Is it after a
> [project-name]/[source-folder]/META-INF/ejb-jar.xml file?

yes - coming back to the issue of WTP needs to assume how the project is structured
and when it does not fit you will get "collisions".

You can disable the ejb validator on that project if you want to get the warning removed.

> 7.- I name my runtimes and servers something like this:
> eap-4.2.0.ga.cp01-12345 (servertype-version-casenumber). When creating
> the server for it, I need to go back to the runtimes in
> Windows/Preferences, copy/paste the runtime name, try creating the
> server again and paste the name there. Wouldn't naming servers with the
> runtime name by default make more sense? You've already had to think of
> a unique name for the runtime and as far as I can see there's a 1-to-1
> mapping between runtime and server...

This is definitly something we should do (and maybe strip out the "runtime" automatically if it is there)
so a "eap-4.2.0.ga-12345 Runtime" becomes "eap-4.2.0.ga-12345 Server"

Please report it in jira.

> 8.- Project archive filter set preview is too small and not resizable.

Yes - jira.

> 9.- Support for SAR archives?

In what way? You mean a project type?

> 10.- Let's say I create a .SAR exploded project archive which contains a
> exploded .WAR archive, i.e
>
> descriptors/
> |--> a.sar/
> 	|--> META-INF/jboss-service.xml
> 	|--> b.war/
> 		|--> WEB-INF/web.xml
>
> When I ask JBDS to filter from descriptors/ folder **/*, the generated
> project archive transforms the exploded war into an jarred war. JBDS
> shouldn't do that, it should keep the war exploded.

I believe this is a bug in the project archives, it should not zip up things that is not set to be zipped.

Put in jira.

> 11.- Following warning: "Classpath entry
> org.eclipse.jdt.junit.JUNIT_CONTAINER/3 will not be exported or
> published. Runtime ClassNotFoundExceptions may result. ". Well, I'm not
> gonna include my test classes in src/test inside my deployments and I
> don't wanna be including junit.jar in the deployment archive, so how can
> i get rid of this warning? Judging from the quick fix, you can only
> avoid this warning by adding junit.jar into the published jar which I
> don't wanna do.

Yeah...tricky WTP fun ,)

http://wiki.eclipse.org/ClasspathEntriesPublishExportSupport explains the gory details.

Unfortunately it looks like the org.eclipse.jst.component.nondependency attribute was only added
to WTP 3.x and thus I don't think WTP 2.x support it. But it could be worth a try to set it manually.

> Last but not least: Great job to everyone involved in JBDS! In spite of
> my comments above, I'm very happy with what I've seen so far!!!

Thanks - and I can see Project Archives is your big loove ,)

-max