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

[Galder Zamarreno]

On top of all this:

- Default values for output and source folders for ejb projects should 
be changeable. Not sure about other type of projects. I'll create a JIRA 
for this.

- I created a new category in the XML configuration view of the server 
called Server and added a new XPath like this:

Name: jmx invoker

XPath Pattern: 
/server/mbean/xmbean/operation/descriptors/interceptors/interceptor

It worked fine first time around but now, although I can see the XPath, 
I can't see the matched XML files. Same happens in the "Ports" category.

I'll create a JIRA for this.

Max Rydahl Andersen wrote:
 >> 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 ;)

My aim is to crush this thing :p

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

What about automatic jar addition to classpath? You start with 
jbossall-client.jar and when the user needs a class that is not in the 
classpath but it's in one of the jars in the runtime, add the jar to the 
"All JBoss Libraries" library. IOW, lazy loading of jars into library.

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

JIRA on its way...

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

JIRA on its way...

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

Project explorer view of ejb-jar.xml and jboss.xml would be welcome.

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

Shame.

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

Ok.

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

JIRA on its way...

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

JIRA on its way...

 >
 >> 9.- Support for SAR archives?
 >
 > In what way? You mean a project type?

Hmm, I suppose you can create a .sar Project Archive without needing a 
project type. Leave this out.

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

JIRA on its way...

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

Will have a go.

 >
 >> 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 ,)

Indeed :)

 >
 > -max

-- 
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat