In case you missed it in the svn commit logs a branch where created for 2.1.x and CR1 was tagged.
That means if something needs to go into the final 2.1 you need to commit it in the branch too.
Please make sure when you resolve in jira you set the right fix versions! (tip: you can select multiple with Ctrl key ;)
The most recent problem was that wtp is still too restrictive. It did
not like our seam 1.2 jboss-seam.jar file. It refused to parse it
because it had no deployment descriptor.
When given a deployment descriptor with proper ejb 3.0 tags in it, such
as interceptors etc, it puked because it didn't understand them.
THe solution is to patch jboss-seam.jar and give it a skeleton ejb 3.0
Rob and I fixed 2 bugs:
1) The pesky binary EJB-JAR not being deployed correctly problem (used
to be a patch issue, then we realized it was ALSO a logic issue...)
2) Small "null" error in the archives view for archives without an
I've retagged the whole shebang, and the 2 builds are moving forward..
feel free to track progress via the following links:
Notification emails for the builds should be ready in approx. 1 hour+
Denis: If you can help us test tomorrow that would be great, we need to
start the release process ASAP tomorrow.. I will probably go ahead with
the JBossTools release mid/late in the day (giving some time to test
tonight and tomorrow), and I will point Bryan to the JBDS binaries as
soon as we have a green light.
Denis & Rob: Let's ALL plan to be in #jbosstools_conf tomorrow so we can
ping any problems off each other in real time, the faster we get this
verified the better =).
Do these changes need to be in the CR1 release or were they earmarked
for GA? I haven't heard about them until just now
Snjezana Peco wrote:
> I have added the fix for JBIDE-2178 and two new hibernate tests to the
> 2.1.x branch.
> These are the changed projects:
The solution has been committed.
This turned out to be a bug in my code, but had a lot to do with the way
WTP treated things that counted as modules but were in fact binary
files. Basically, the "name" of most wtp modules (ear projects, ejb
projects, web projects) is just the name of the project itself.
The name for a binary ejb inside an ear project, however, is actually
something ridiculous like
I have no idea why that's it. Don't ask me. What makes it even worse is
that this, however, is that even this module has "members".
The way my publisher had been handling things was to get the project
name, which should have been the same as the module name. Unfortunately
binary objects *do* have projects, and those projects are the ones they
are contained in. Therefore, my deploy folder became something like
It recognized the child was an ejb, but the name it was using was from
the project. Dumb mistake.
However what compounded it was that the ejb module *also* has
"members". In a project scenerio, that works out just fine because you
would likely append any member directly after the path of the module
itself. For example,
someEar.ear/myEJB.jar and then append each member, such as
However, in the case of a binary object, you'd end up getting something like
The worst part of all is that there's no way to tell whether a "module"
is binary or is a project. There's simply no API for it.
Well, I did my best. I checked to see if the "name" of the module has
more than one "segment" in a Path.
Good luck to us.