Do you want to fix this? Or do you need some help understanding the source.
The fix would be in MacroUtil.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3864199#3864199
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3864199
Adrian,
The Class-Path for a jar is now included in the build path, not just for
testing. I think this may be a problem, because I am not forced to specify a
direct dependency if it is a dependency for another artifact.
Example is jmx. I can compile JMX using just these declared
For example, javax.management.MatchQueryExp imports gnu.regexp, so I ought to
need to declare that as an input for the jmx component.
Perhaps we should add an additional construct similar to which only expands to
the directly included inputs.
buildpath/ ?
View the original post :
Ok, I'll take a look at this. I think I have a good idea of what needs to be
changed.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3864205#3864205
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3864205
I've fixed this. You are correct, SourceDefinition.generateTargets should break
out of the loop once it realizes that one of the Source elements applies rather
than trying to generate a target for each one that applies.
I fixed it in other places as well. Most of them were doing it wrong.
View
Also, as a heads up.
We don't use tabs in source.
1) Most developers use 3 *spaces* for tabs which doesn't work if you use
different editors that defaults to 4 or 8
2) Tabs don't display correctly when source is viewed by online tools. HTML
converts the tab to one space.
View the original post
TABS?! To the gallows with you!
[I believe there is code conventions document on sourceforge that describe the
basic requirements]
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3863394#3863394
Reply to the post :
I've implemented the Class-Path processing.
Now the pathelements/
will include the dependencies of the jars they include.
e.g. kernel compiles over common-project, concurrent
and includes test-project for testcase support.
| source id=main
| include input=common-project/
|
Another heads up.
You don't need to include both the server jar and the client jar in the
classpath.
e.g.
common-project only needs jboss-common.jar
jboss-common-client.jar is a cutdown version of jboss-common.jar
including only those classes required on the client side.
(Bad example, because
I've already added that to the new build:
| component
| mkdir dir=@{output}/etc/
| copy todir=@{output}/etc filtering=yes
|fileset dir=@{component.dir}/src/etc/ includes=**/
|filterset
| filter
Ultimately we do want this for thirdparty jars for support as very few projects
actually correctly tag their jars so its difficult to know what version of x is
in jboss. The new thirdparty management mechanism should make this information
available and should encode it as part of the dist build
I have checked in naming/jbossbuild.xml. I implemented rmic as Adrian
described above with an rmic attribute on the source node in the component
definition (in naming/jbossbuild.xml):
| source id=main
|rmic=**/NamingServer.class
|
|include
I have checked in j2ee/jbossbuild.xml. It produces all three artifacts of j2ee
and integrates into the top level build. However, I have a couple of issues.
1. j2ee includes some classes from jmx. For now, I access using a relative
path which is what the existing build path essentially does.
[EMAIL PROTECTED] wrote : I have checked in j2ee/jbossbuild.xml. It produces
all three artifacts of j2ee and integrates into the top level build. However,
I have a couple of issues.
|
| 1. j2ee includes some classes from jmx. For now, I access using a
relative path which is what the
Maybe
| includes id=common-project
|
Is a better name?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3862973#3862973
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862973
Ok, thanks -- this makes sense. I've added includes for common-project and
j2ee-project.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3862979#3862979
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862979
I've hit a similar problem. Except with the testing.
Here's an example:
The kernel project contains some tests that use JBoss common's JBossXB
implementation.
It works fine for compilation in that all I need to include is jboss-common.jar.
But when it comes to do testing, I need to include the
The only problem I see is that we can't (shouldn't?) modify the manifest of
thirdparty libraries. So you would only get the indirect dependencies of jboss
libraries. Perhaps this is not a big deal, though.
View the original post :
I already modify all jar manifests when a release is done to tag them with the
jboss release info. If a jar actually uses the version manifest (and few do)
its preserved, but the implementation headers are updated. Picking the
4.0.1/client/jacorb.jar at random:
| [EMAIL PROTECTED] client]$
How do I add a pre-compilation task like rmic? I think I would want to define
the input source which required processing:
| componentdef ..
| source id=rmic
| include input=classes
| /source
| /componentdef
|
And then in tasks.xml
| targetdef target=rmic
| component/
I would do it like this:
| source id=main
| rmic=org/jboss/invocation/jrmp/server/JRMPInvoker*
|
| ...
|
| // snipped targetdef as now
| targetdef target=build description=Build
| source
| mkdir dir=@{output}/
| depend
Ryan will be taking over the responsibility for this work,
with lots of input from me.
I imagine there are lots of other requirements and there are many things that
become
possible with a more declaritive and consistent build.
One of the key issues before this becomes the real build will be to
Here is some of what is new from the previous discussion:
1) I added an explicit generate/ tag. This works around a problem
with ant typedefs where there is no callback to tell you have finished parsing
that xml element.
This enabled me to remove of the complications with target generation where
TODO: This should be replaced with tasks in JIRA
1) Do the other projects within jboss-head - this is an alternate build for now,
i.e. you have to do ant -f jbossbuild.xml
This basically involves copying common/jbossbuild.xml to the other projects
and updating it.
It will also involve specifiy
24 matches
Mail list logo
