Hi all: The jbosstools team has been instructed by you all not to reach in to the modules folder for the purposes of classpath management in eclipse. We've also been told api would be forthcoming to assist us discover what jars should be added to projects so that users can get up and running as fast as possible. And a final reminder, our use case requires a non-running server to discover the appropriate jars to add. Was just wondering if this was anywhere on the plan, or if we should abandon waiting and simply hard-code our classpaths as we have in the past. Our users are getting upset as we just released alpha2 and our next is beta1. A beta with this serious error would only win user condemnation as incomplete if we provide no classpath management for web / seam / etc projects.

> From what I know of our current schedule, I'm afraid you should not > count on this for the 8.0.0.Alpha1 release. Okey - but we need *something* for AS 7.1+/EAP 6.0+ ..or you should be ok with us "guessing" the list of jars to add... Is there anyway we can figure out the jar location for a set of jars based on a list of module names ? i.e. one that you guys would not call "broken and not supported" ? :) i.e. a "jboss module/AS aware jar locator" I'm thinking we get our eclipse tooling to understand module names and then use this locator to get the proper jars would be a great start. Then add ons like the txt in root of distribution can be tweaked out on top of this. (since we would need this 'locator' for the txt file anyway - especially with layering and patching being added making hardcoded fileset's not good) Would that be doable ?

/max > > The solutions which seem applicable to your concerns which Max and Brian > and I talked about included the following: > > 1. A single top-level txt file whose complete content is the release > name e.g. "WildFly 8" or "JBoss EAP 6.2" etc. (this should be easy) > 2. Packaging JBDS Facet definitions in a well-defined place which > includes the class path information for each technology > > We can definitely do #1 without any substantial effort. For #2 we would > definitely count on input from you guys (we have no idea what these > definitions look like, though it does seem clear we'd have to use build > information in part to generate these files to ensure the exact JAR > paths (or at least Maven GAV) are properly specified). > > Do you have any expectations beyond what I've listed here? > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Tue, May 07, 2013 at 08:26:24AM -0500, David M. Lloyd wrote: > On 05/07/2013 07:25 AM, Max Rydahl Andersen wrote: >>> From what I know of our current schedule, I'm afraid you should not >>> count on this for the 8.0.0.Alpha1 release. >> >> Okey - but we need *something* for AS 7.1+/EAP 6.0+ ..or you should >> be ok >> with us "guessing" the list of jars to add... >> >> Is there anyway we can figure out the jar location for a set of jars >> based on a list of module names ? i.e. one that you guys would not call >> "broken and not supported" ? :) >> i.e. a "jboss module/AS aware jar locator" >> >> I'm thinking we get our eclipse tooling to understand module names and >> then use this locator >> to get the proper jars would be a great start. >> >> Then add ons like the txt in root of distribution can be tweaked out on >> top of this. >> (since we would need this 'locator' for the txt file anyway - especially >> with layering and patching >> being added making hardcoded fileset's not good) >> >> Would that be doable ? > > Possible, but a lot more work than #1/#2 that I've mentioned, and may > require resources that are already booked up. Is there any reason the > two suggestions I made would not suffice? Putting things in the > filesystem is a trivial effort compared to creating APIs that have to be > supported. #1 is about identifying the server - seperate problem and not really about classpath definition. #2 would need to locate the jar info...

2. Packaging JBDS Facet definitions in a well-defined place which includes the class path information for each technology We can definitely do #1 without any substantial effort. For #2 we would definitely count on input from you guys (we have no idea what these definitions look like, though it does seem clear we'd have to use build information in part to generate these files to ensure the exact JAR paths (or at least Maven GAV) are properly specified).

> Do you have any expectations beyond what I've listed here? > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev