Why can't I build, please help.
by Vimal Kansal
Hi,
I have checked out the latest code and while building it on my Windows 7
m/c(Java 1..6.27, 64 bit), the build fails with the following error :
[ERROR] Failed to execute goal
org.codehaus.mojo:javacc-maven-plugin:2.3-jboss-1:jjtree
(jjtree-jbossql) on project jboss-as-cmp: Execution jjtree-jbossql of
goal org.codehaus.mojo:javacc-maven-plugin
:2.3-jboss-1:jjtree failed: basedir
C:\vkk\JBoss-AS7\jboss-as\cmp\C:\vkk\JBoss-AS7\jboss-as\cmp\src\main\jjtree
does not exist -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn <goals> -rf :jboss-as-cmp
C:\vkk\JBoss-AS7\jboss-as>
I am not sure why the base dir is being picked up as :
basedir
C:\vkk\JBoss-AS7\jboss-as\cmp\C:\vkk\JBoss-AS7\jboss-as\cmp\src\main\jjtree
it should be
basedir C:\vkk\JBoss-AS7\jboss-as\cmp\src\main\jjtree
Can somebody please help.
Thx
Vimal
12 years, 6 months
Testsuite Guidelines
by Jason T. Greene
Hi Everyone,
Lately I've been seeing a lot of testsuite activity, which is great,
however I noticed some of the pull requests are doing direct copies of
the AS6 tests.
One thing to keep in mind is that the AS6 testsuite had a number of
broken tests, was extremely slow to run, and tested a lot of deprecated
functionality. Also another issue is that we have quite a few test cases
in AS7 already, and quite a few of the older tests overlap.
I really would like to keep our testsuite clean and efficient so we do
not end up with an AS6 style 4 hour testsuite that no one bothers to
run. This greatly out-ways the need for more coverage (What good is
extra coverage if its infrequently used?).
Every added test, whether ported or new should follow the same guidelines:
- Verify the test belongs in AS7
AS6 has a lot of tests for things that are discontinued. For example the
legacy JBoss Transaction Manager which was replaced by Arjuna. Also we
had tests for SPIs that no longer exist. None of these things should be
migrated.
- Only add CORRECT and UNDERSTANDABLE tests
If you don't understand what a test is doing (perhaps too complex), or
it's going about things in a strange way that might not be correct, THEN
DO NOT PORT IT. Instead we should have a simpler, understandable, and
correct test. Write a new one, ping the author, or skip it altogether.
- Do not add duplicate tests
Always check that the test you are adding doesn't have coverage
elsewhere (try using "git grep"). As mentioned above we have some
overlap between 6 and 7. The 7 test version will likely be better.
- Don't name tests after JIRAs
A JIRA number is useless without an internet connection, and they are
hard to read. If I get a test failure thats XDGR-843534578 I have to dig
to figure out the context. It's perfectly fine though to link to a JIRA
number in the comments of the test. Also the commit log is always available.
- Tests should contain javadoc that explains what is being tested
This is especially critical if the test is non-trivial
- Prefer expanding an EXISTING test over a new test class
If you are looking at migrating or creating a test with similar
functionality to an exiting test, it is better to
expand upon the existing one by adding more test methods, rather than
creating a whole new test. In general each
new test class adds at least 300ms to exectution time, so as long as it
makes sense it is better to add it to an
existing test case.
- Organize tests by subsystem
Integration tests should be packaged in subpackages under the relevant
subsystem (e.g org.jboss.as.test.integration.ejb.async). When a test
impacts multiple subsystems this is a bit of a judement call, but in
general the tests should go into the package of
the spec that defines the functionlaity (e.g. CDI beased constructor
injection into an EJB, even though this involes CDI and EJB,
the CDI spec defines this behaviour)
- Explain non-obvious spec behavior in comments
The EE spec is full of odd requirements. If the test is covering
behavior that is not obvious then please add sometihng like "Verifies EE
X.T.Z - The widget can't have a foobar if it is declared like blah"
- Put integration test resources in the package of the test
At the moment there is not real organization of these files. It makes
sense for most apps to have this separation, however the testsuite is
different. e.g. most apps will have a single delpoyment descriptor of a
given type, for the tesuite will have hundreds, and mantaining mirroring
package structures is error prone.
This also makes the tests easier to understand, as all the artifacts in
the deployment are in one place, and that place tends to be small (only
a handful of files)
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
12 years, 6 months
cli: default tab completion list
by Alexey Loubyansky
WRT https://issues.jboss.org/browse/AS7-2243
Tab completion for operations should show low-level operations
Brian suggests to include operations in the list of commands shown by
the tab completion when the line is empty.
The original idea was to make an accent on the commands with the hope
that operations will be used only in special/advanced cases. Which is
still the direction to follow.
So, by default the cli is in the command completion mode.
Operation request completion is triggered by '/', './' or ':'.
This is actually consistent with the bash shell too, where by default
you get a list of commands, scripts are not included, you'd have to
start with './'. Although, './' is listed there before all the commands
as an option, which is not the case in the cli.
IMO, the current impl is cleaner.
Votes, suggestions?
Thanks,
Alexey
12 years, 6 months
module upgrade suggestion
by Bill Burke
A user needed an upgrade to resteasy for JBoss AS 7. To upgrade it
though, he has to copy each and every jar to the appropriate directory
*AND* edit XML files to export the appropriate new jars.
Initially to make the process easier, don't require a <resource/>
element within module.xml. If there is none, have the runtime export
every jar in that directory.
I'd also like to suggest a redesign of the module structure:
1. Have a central module.xml file instead of separating it out into
multiple module files.
2. Point <resources/> to maven artifacts instead of actual files.
3. Allow configuring of maven repository directory
4. Later on, allow downloading of maven repository directory.
With those two things your directory structure becomes very simplified
and profiles can be shipped into an even smaller set of files.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years, 6 months
OpenJDK and JDK 7 Builds
by James Perkins
I've been making some changes to get AS7 to build on a build of OpenJDK
7. In the process of getting this to work I did get it successful builds
with OpenJDK 6 as well. I did have to disable one Hiibernate test that
uses JSR-223 as OpenJDK doesn't have a JavaScript engine. Other than
that I do see more random test failures with OpenJDK 7 than I do with
any of the JDK 6's.
There is one catch to building with OpenJDK 7, it only works with
OpenJDK or IcedTea and if you build the JDK from their respective
upstreams. There is a fix in there for an annotation processor bug that
effects the logging tooling. If anyone needs/wants information on
building those just let me know.
This is mainly to let everyone know as I've heard others have been
talking about it. I'll be submitting a pull request in the next few days.
--
James R. Perkins
JBoss by Red Hat
12 years, 6 months
Programmable deploying HOWTO
by Pavel Janousek
Hello,
is there any useful guide or some more specific docs for programmable deploying of some EAR/JAR etc.? I've understood which options I have for to do this. I prefer a way via ModelControllerClient => the same way as CLI works.
I think I've grasped what and how CLI works and does deploy/undeploy some - let say WAR artifact (= WebApp for ex.) and I can extract code technique from it. But if there is more elegant and better way which depends only on a small number of AS7 artifacts, it will be great.
I need this because I'll develop some performance tests for RESTEasy sub-system, including WebApp deploying time etc.
I think, the second reasonable way (with comparable overhead as previous) to do thing like this is use the HTTP deploying management, but I didn't found any docs about this.
Could you please point me out to some useful info or example for study?
Thank you,
--
Pavel Janousek
Senior JBoss QA Engineer
12 years, 6 months
JBoss Logging upgrade breaking build (was Re: [infinispan-dev] )
by Sanne Grinovero
Hi David,
thanks for the update, it seems indeed that jboss-logging to
3.1.0.Beta3 works fine for Infinispan but since the logging classes
generated for JBoss Logging 3.1.x are not compatible with 3.0.x, which
version is AS7 going to use?
Sanne
On 24 October 2011 00:14, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
> Okay, I've gotten to the root of the build issue. If you update your
> jboss-logging to 3.1.0.Beta3, and do a clean rebuild, the problem should
> go away.
12 years, 6 months
