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

[Galder Zamarreno]

Galder Zamarreno wrote:
> 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.

http://jira.jboss.com/jira/browse/JBIDE-2100

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

http://jira.jboss.com/jira/browse/JBIDE-2101

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

http://jira.jboss.com/jira/browse/JBIDE-2094

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

http://jira.jboss.com/jira/browse/JBIDE-2095

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

http://jira.jboss.com/jira/browse/JBIDE-2096

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

http://jira.jboss.com/jira/browse/JBIDE-2097

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

http://jira.jboss.com/jira/browse/JBIDE-2098

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

http://jira.jboss.com/jira/browse/JBIDE-2099

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