[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
[EMAIL PROTECTED] wrote : One issue that is not clear in this discussion is do I have sufficient info to go obtain the source for every jar I find in the dist? Ultimately I want this for patches as well. The ideal roundtrip behavior is that I would point a ant task to a release and have it spit out the jboss-build.xml that would obtain the source and thirdparty repository to rebuild the possibly patched dist. | Right, you might have a distribution which has potentially reflects multiple patches, and now you want the source for this distribution. I think this is possible with the current design. How it would work: 1. Iterate over all the jars in a release, collecting the component id version from each jar manifest. 2. Verify there are no conflicts between jars. IE, jboss-common.jar and jboss-common-client.jar must agree on their version. Otherwise, the source is not resolvable. 3. Based on the above, you have enough information to create a toplevel build. * 4. Upon calling synchronize for this toplevel build, the component id's and versions will be used to resolve the component-info from the build repository. 5. The component-info will contain the cvsroot, module, and tags for each component. These data will then be used to checkout the source for each component. * This does not address non-archive artifacts, such as text files. We would need to add manifests to these text files if we wanted to be able to resolve their source components. Is this necessary for this use case (or in general)? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3874116#3874116 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3874116 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
[EMAIL PROTECTED] wrote : | 1. Iterate over all the jars in a release, collecting the component id version from each jar manifest. | This assumes we add the compoent id to the manifest. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3874117#3874117 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3874117 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
anonymous wrote : | * This does not address non-archive artifacts, such as text files. We would need to add manifests to these text files if we wanted to be able to resolve their source components. Is this necessary for this use case (or in general)? | No. In general configuration files will have no mapping to the dist as they will have been customized. I'm really only interested in being able to reproduce the same binaries from source for support. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3874118#3874118 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3874118 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
So just to rephrase your comments: Each component sets the implVersion and implTitle to the component level values (eg. aop 1.1). We want additional values for the toplevel release, maybe releaseVersion and releaseTitle. I'm guessing the best place to set these two manifest values is as a part of the release target, using the Ant task from JBBUILD-5. [EMAIL PROTECTED] wrote : | In terms of the repository, I don't see a problem with each module defining its own repository/cvs. The issue is keeping that in step with reality. e.g. Suppose I copy a binary from one repository to another, who updates the xml? | I guess you are right, components could theoretically have different repositories. However, this would seem rare for our usage at least. Since we don't want to have this duplicated in each file, maybe the default should be a property which can be overriden with an attriibute in component info. [EMAIL PROTECTED] wrote : | e.g. Does a problem occur if the component info from cvs disagrees with the repository's version. Probably? | There is a problem if they differ, but not a fatal one. I give preference to the component-info from cvs. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3874019#3874019 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3874019 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
One issue that is not clear in this discussion is do I have sufficient info to go obtain the source for every jar I find in the dist? Ultimately I want this for patches as well. The ideal roundtrip behavior is that I would point a ant task to a release and have it spit out the jboss-build.xml that would obtain the source and thirdparty repository to rebuild the possibly patched dist. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3874034#3874034 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3874034 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
One result of not importing a toplevel build is that attributes which were previously set on the toplevel build element now must be set elsewhere. Examples of this are the thirdparty location, implTitle, targetdefs, repository location, etc. For most of these, I have created properties, stored in tools/etc/jbossbuild.properties. However, for the manifest data like implTitle and implVersion, I am less sure how to proceed. One natural place is to set these in the component-info for a given component. However, when we do a release, we want the jars to contain the same manifest information -- not to vary by component. Perhaps we could use http://jira.jboss.com/jira/browse/JBBUILD-5 to modify all jar manifests, including non-thirdparty? This is not stopping any work, just looking for input while its on my mind. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3873832#3873832 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3873832 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
Ok. So the problem now is that we need somewhere to specify project defaults, like the repository location and top level release id/version. In some circumstances, you probably wouldn't want the top level defining the version, e.g. aop-1.1 in 3.2.x or 4.0.x is still aop-1.1 You probably still want to know the top level build that built/included the file? I think we need to define what information we need in the manifest and who puts it there. e.g. If I download a thirdparty jar, do I still tag it with my main release id? Probably yes. e.g.2. does jbossmq get tagged with its own version besides the top level release ids it is included in, probably yes etc. Don't forget that some projects/jars although source projects will actually get included in multiple top level builds/versions as binaries, e.g. AOP or Cache. In terms of the repository, I don't see a problem with each module defining its own repository/cvs. The issue is keeping that in step with reality. e.g. Suppose I copy a binary from one repository to another, who updates the xml? Same problem with the cvs location. I think this will be more important for the full synchronize? e.g. 1) Download jbossas and tools 2) cd jbossas 3) ant synchronize 4) Download from the repository component info for each source project which gives the cvs info 5) checkout each project from cvs e.g. Does a problem occur if the component info from cvs disagrees with the repository's version. Probably? If everything is specfied correctly, there will be no problem. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3873835#3873835 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3873835 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
[EMAIL PROTECTED] wrote : For the export functionality, we want to keep the
syntax as simple as possible.
|
| This would cause the parsing as above, but would use the designated
reference id instead of the component's exports. So the export statement is
the default, but you retain the ability to reference an abitrary input.
| [/qoute]
|
| The includes or export is just a convenience such that each consuming
project
| does not need to be changed when the exported artifact definition changes.
|
| The consuming project still has the option to be more explicit about what it
| actually uses, but then that would point to a project that probably needs
| splitting up
|
| anonymous wrote :
| | To do this, I will need to add a component-info.xml for thirdparty/* in
cvs. I assme there is no problem with this? We'll need these eventually,
anyway. Basically, it will involve copying the existing thirdparty component
declarations from jbossas/jbossbuild.xml into the component-info.xml and
changing the {includes} to {export}.
|
Yes, that is exactly what I want. Each component (whether it is one our projects
or a true thirdparty project) should define its own artifacts
rather than the top level build. Doing it on the top level build stops
the project being included in multiple integration projects because it has
references back to a specific top level build.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3873104#3873104
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3873104
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
[EMAIL PROTECTED] wrote : [EMAIL PROTECTED] wrote : For the export
functionality, we want to keep the syntax as simple as possible.
| |
| | This would cause the parsing as above, but would use the designated
reference id instead of the component's exports. So the export statement is
the default, but you retain the ability to reference an abitrary input.
| |
|
| The includes or export is just a convenience such that each consuming
project
| does not need to be changed when the exported artifact definition changes.
|
| The consuming project still has the option to be more explicit about what it
| actually uses, but then that would point to a project that probably needs
| splitting up
|
| anonymous wrote :
| | To do this, I will need to add a component-info.xml for thirdparty/* in
cvs. I assme there is no problem with this? We'll need these eventually,
anyway. Basically, it will involve copying the existing thirdparty component
declarations from jbossas/jbossbuild.xml into the component-info.xml and
changing the {includes} to {export}.
|
Yes, that is exactly what I want. Each component (whether it is one our projects
or a true thirdparty project) should define its own artifacts
rather than the top level build. Doing it on the top level build stops
the project being included in multiple integration projects because it has
references back to a specific top level build.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3873105#3873105
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3873105
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
[EMAIL PROTECTED] wrote : For the export functionality, we want to keep the
syntax as simple as possible.
| (snip)
| This would cause the parsing as above, but would use the designated
reference id instead of the component's exports. So the export statement is
the default, but you retain the ability to reference an abitrary input.
|
The includes or export is just a convenience such that each consuming project
does not need to be changed when the exported artifact definition changes.
The consuming project still has the option to be more explicit about what it
actually uses, but then that would point to a project that probably needs
splitting up
anonymous wrote :
| To do this, I will need to add a component-info.xml for thirdparty/* in
cvs. I assme there is no problem with this? We'll need these eventually,
anyway. Basically, it will involve copying the existing thirdparty component
declarations from jbossas/jbossbuild.xml into the component-info.xml and
changing the {includes} to {export}.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3873106#3873106
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3873106
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
[EMAIL PROTECTED] wrote : For the export functionality, we want to keep the
syntax as simple as possible.
|
| This would cause the parsing as above, but would use the designated
reference id instead of the component's exports. So the export statement is
the default, but you retain the ability to reference an abitrary input.
|
The includes or export is just a convenience such that each consuming project
does not need to be changed when the exported artifact definition changes.
The consuming project still has the option to be more explicit about what it
actually uses, but then that would point to a project that probably needs
splitting up
anonymous wrote :
| To do this, I will need to add a component-info.xml for thirdparty/* in
cvs. I assme there is no problem with this? We'll need these eventually,
anyway. Basically, it will involve copying the existing thirdparty component
declarations from jbossas/jbossbuild.xml into the component-info.xml and
changing the {includes} to {export}.
|
Yes, that is exactly what I want. Each component (whether it is one our projects
or a true thirdparty project) should define its own artifacts
rather than the top level build. Doing it on the top level build stops
the project being included in multiple integration projects because it has
references back to a specific top level build.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3873107#3873107
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3873107
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
Ok, here is the plan for the standalone remoting build: 1. Implement the export/import funcationality described above. 2. Add remoting's thirdparty deps to cruisecontrol.jboss.com/repository 3. Create a standalone remoting cvs alias which includes remoting and tools (for jbossbuild) 4. Create a release.xml in the jboss-remoting module which describes the release structure of remoting. This will allow Tom to create a standalone release of remoting. I think all of this will take about a week. This doesn't address the issue of integrating the remoting jar back into head. As far as I can tell, this will have to wait until the new build is complete in head and is downloading dependencies. This looks like the beginning of May to me (milestone-3). View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3872913#3872913 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3872913 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
For the export functionality, we want to keep the syntax as simple as possible.
So to include the jmx project in your classpath you would want to do:
source id=main
| include component=jmx/
| /source
This would look for a component-info.xml first in ../jmx and then in
../thirdparty/jmx. The component-info would need to have an export declaration:
component id=jmx ...
|artifact id=jboss-jmx.jar/
|artifact id=jboss-jmx-core.jar/
|export
| include input=jboss-jmx.jar/
|/export
| /component
So that jboss-jmx.jar would be included in the classpath of the compilation.
However, I think you will still want the ability to use artifacts or other
includes besides the exported ones:
source id=main
|include component=jmx input=jboss-jmx-core.jar/
| /source
| This would cause the parsing as above, but would use the designated
reference id instead of the component's exports. So the export statement is
the default, but you retain the ability to reference an abitrary input.
To do this, I will need to add a component-info.xml for thirdparty/* in cvs. I
assme there is no problem with this? We'll need these eventually, anyway.
Basically, it will involve copying the existing thirdparty component
declarations from jbossas/jbossbuild.xml into the component-info.xml and
changing the {includes} to {export}.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3872967#3872967
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3872967
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
Yes, that is the one, but it doesn't include our convesation. Yes, I did test the parsing of the build.xml. The main problem I ran into was that of the ids of the various imported components conflicting. IE, every component has an source with an ID of main, so trying to import a half dozen components is going to end up with Ant overriding the reference to main a half dozen times. The solution to this, I think, is to have two files in each component directory. One is the component-info.xml (better name?) which contains the external metadata (interface) of each component, as outlined in the issue you refer to. It would also include the exports that we talked about at the dev conference. The other would be the build.xml which includes the componentdefs as now. Do you see any problems with seperating them as I suggest? IE, instead of remoting importing common/build.xml, it would import common/component-info.xml instead? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3872782#3872782 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3872782 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
Yes, the split makes sense. 1) It clearly separates the external definition from the internal implementation 2) Nobody is likely to be interested in how a jar is constructed or which source is used, only the end product. So the duplicate | source id=main/ | should be irrelevent. 3) It means the repository is not being continually updated with minor internal tweaks to the module builds. The other solution would be to use xml namespaces. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3872784#3872784 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3872784 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build - Standalone module - multiple builds
[EMAIL PROTECTED] wrote : | The other solution would be to use xml namespaces. I actually think namespace is technically a much better solution. However, I think will be more difficult for people to learn/use, so would not go with it because will lead to more build errors. So where does this leave things for JBossRemoting build? I obviously can't take the jbossbuild.xml from jboss-head/remoting/ directory and expect it to work as is. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3872791#3872791 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3872791 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: new build system and Eclipse
This is a know issue. Eclipse shouldn't be generating the list by parsing the ant file directly, it should be parsing then asking the ant project what are the targets? If it really is an issue, maybe you could look at providing a patch to the eclipse project? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3869594#3869594 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3869594 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: new build system and Eclipse
Weren't you complaining a few months ago that you couldn't use eclipse with buildmagic? At least we're not moving backwards :-) One possibility is that we have a few regular s in tasks.xml for Eclipse to read. Then the dynamic ones can use Project.addOrReplaceTarget() instead of just addTarget(). Duplicate targetdefs are a good indication you have something wrong with your build definition, so we could check to see if the existing target is instanceof DynamicTarget before overriding it... View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3869595#3869595 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3869595 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: new build system and Eclipse
I meant to say we could have a few regular targets in tasks.xml for Eclipse to read. Basicaly, no-op targets to work around Eclipse's desire to parse the ant file. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3869596#3869596 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3869596 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: new build system and Eclipse
Good point about the buildmagic issue :-) no-arg targets is a good idea - build, compile, etc. Something for Eclipse to see. I was thinking we can have a static target that builds a static script that Eclipse can read in. instead of pointing Eclipse to jbossbuild.xml, we point it to output/build.xml - it would basically be the full set of dynamic targets written to it (something like the show output, but with everyting in there). But no-arg targets might not be a bad idea and might be simpler to do. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3869598#3869598 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3869598 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: new build system and Eclipse
You can almost get that now except it includes the ant cruft:
| [EMAIL PROTECTED] kernel]$ ant -emacs -f jbossbuild.xml show test
|
produces:
| Buildfile: jbossbuild.xml
|
| show:
| !-- Build All --
| target name=all depends=build, doc, test
| /target
|
| !-- Javadoc --
| target name=api
| /target
|
| !-- Build --
| target name=build depends=build.etc, build.main, build.tests,
build.xml-test, build.jboss-microcontainer.jar
| mkdir dir=/home/ejort/jboss-head/workspace/kernel/output/etc/
| copy todir=/home/ejort/jboss-head/workspace/kernel/output/etc
filtering=yes
| fileset dir=/home/ejort/jboss-head/workspace/kernel/src/etc/
includes=**/
| /copy
| /target
|
| target name=build.etc
| mkdir dir=/home/ejort/jboss-head/workspace/kernel/output/etc/
| copy todir=/home/ejort/jboss-head/workspace/kernel/output/etc
filtering=yes
| fileset dir=/home/ejort/jboss-head/workspace/kernel/src/etc/
includes=**/
| filterset
| filter token=java.vm.version value=1.4.2_04-b05/
| filter token=java.vm.vendor value=Sun Microsystems Inc./
| filter token=specification.title value=JBossAS/
| filter token=specification.version value=5.0.0alpha/
| filter token=specification.vendor value=JBoss Inc./
| filter token=implementation.title value=JBossAS/
| filter token=implementation.url value=http://www.jboss.org/
| filter token=implementation.version value=5.0.0alpha/
| filter token=implementation.vendor value=JBoss Inc./
| filter token=implementation.vendor.id value=http://www.jboss.org/
| /filterset
| /copy
| /target
|
| !-- Build for the artifact jboss-microcontainer.jar --
| target name=build.jboss-microcontainer.jar
| mkdir dir=/home/ejort/jboss-head/workspace/kernel/output/lib/
| jar
destfile=/home/ejort/jboss-head/workspace/kernel/output/lib/jboss-microcontainer.jar
| manifest
| attribute name=Created-by value=1.4.2_04-b05 Sun Microsystems
Inc./
| attribute name=Specification-Title value=JBossAS/
| attribute name=Specification-Version value=5.0.0alpha/
| attribute name=Specification-Vendor value=JBoss Inc./
| attribute name=Implementation-Title value=JBossAS/
| attribute name=Implementation-URL value=http://www.jboss.org/
| attribute name=Implementation-Version value=5.0.0alpha/
| attribute name=Implementation-Vendor value=JBoss Inc./
| attribute name=Implementation-Vendor-Id
value=http://www.jboss.org/
| attribute name=Class-Path value=jboss-common.jar namespace.jar
jboss-container.jar concurrent.jar/
| /manifest
| zipfileset
file=/home/ejort/jboss-head/workspace/kernel/output/classes/main/
| /jar
| /target
|
| !-- Build for the source src/main --
| target name=build.main
| property name=javac.excludes value=/
| Unable to locate '../conf/' in Class-Path of jboss-container.jar
| mkdir dir=/home/ejort/jboss-head/workspace/kernel/output/classes/main/
| depend
destdir=/home/ejort/jboss-head/workspace/kernel/output/classes/main
srcdir=src/main
| classpath
| pathelement
location=/home/ejort/jboss-head/workspace/common/output/lib/namespace.jar/
| pathelement
location=/home/ejort/jboss-head/workspace/thirdparty/apache-xerces/lib/xercesImpl.jar/
| pathelement
location=/home/ejort/jboss-head/workspace/thirdparty/apache-log4j/lib/log4j.jar/
| pathelement
location=/home/ejort/jboss-head/workspace/common/output/lib/jboss-common.jar/
| pathelement
location=/home/ejort/jboss-head/workspace/thirdparty/oswego-concurrent/lib/concurrent.jar/
| pathelement
location=/home/ejort/jboss-head/workspace/kernel/output/classes/main/
| pathelement
location=/home/ejort/jboss-head/workspace/container/output/lib/jboss-container.jar/
| /classpath
| Unable to locate '../conf/' in Class-Path of jboss-container.jar
| /depend
| javac
destdir=/home/ejort/jboss-head/workspace/kernel/output/classes/main
deprecation=true srcdir=src/main debug=true excludes=${javac.excludes}
| classpath
| pathelement
location=/home/ejort/jboss-head/workspace/common/output/lib/namespace.jar/
| pathelement
location=/home/ejort/jboss-head/workspace/thirdparty/apache-xerces/lib/xercesImpl.jar/
| pathelement
location=/home/ejort/jboss-head/workspace/thirdparty/apache-log4j/lib/log4j.jar/
| pathelement
location=/home/ejort/jboss-head/workspace/common/output/lib/jboss-common.jar/
| pathelement
location=/home/ejort/jboss-head/workspace/thirdparty/oswego-concurrent/lib/concurrent.jar/
| pathelement
location=/home/ejort/jboss-head/workspace/kernel/output/classes/main/
| pathelement
location=/home/ejort/jboss-head/workspace/container/output/lib/jboss-container.jar/
| /classpath
| /javac
| copy todir=/home/ejort/jboss-head/workspace/kernel/output/classes/main
| fileset dir=src/main
| include name=**/*.properties/
|
[JBoss-dev] [Design of JBoss Build System] - Re: new build system and Eclipse
One of the big problems with buildmagic/eclipse is gone in jboss-head. It no longer uses xdoclet, so you don't have xjavadoc eating all your memory. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3869604#3869604 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3869604 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 dependencies: | source id=main | include input=common-project/ | include input=bcel/ | include input=junit/ | /source | and then the Class-Path from jboss-common.jar is expanded into my build path: | classpath | pathelement location=C:\projects\jboss-head\thirdparty\apache-xerces\lib\xercesImpl.jar/ | pathelement location=C:\projects\jboss-head\thirdparty\junit-junit\lib\junit.jar/ | pathelement location=C:\projects\jboss-head\jmx\output\classes\main/ | pathelement location=C:\projects\jboss-head\thirdparty\apache-jaxme\lib\jaxmexs.jar/ | pathelement location=C:\projects\jboss-head\thirdparty\apache-bcel\lib\bcel.jar/ | pathelement location=C:\projects\jboss-head\thirdparty\wutka-dtdparser\lib\dtdparser121.jar/ | pathelement location=C:\projects\jboss-head\thirdparty\apache-commons\lib\commons-httpclient.jar/ | pathelement location=C:\projects\jboss-head\thirdparty\oswego-concurrent\lib\concurrent.jar/ | pathelement location=C:\projects\jboss-head\thirdparty\gnu-regexp\lib\gnu-regexp.jar/ | pathelement location=C:\projects\jboss-head\common\output\lib\jboss-common.jar/ | pathelement location=C:\projects\jboss-head\thirdparty\dom4j-dom4j\lib\dom4j.jar/ | pathelement location=C:\projects\jboss-head\thirdparty\apache-slide\client\lib\webdavlib.jar/ | pathelement location=C:\projects\jboss-head\common\output\lib\namespace.jar/ | pathelement location=C:\projects\jboss-head\thirdparty\apache-log4j\lib\log4j.jar/ | /classpath | | This is undesirable because I jmx has direct dependencies on jars which are not documented in the input. This is fine for testing, but not in building where we want the build to fail if direct dependencies are not documented explicitly. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3864143#3864143 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3864143 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 : http://www.jboss.org/index.html?module=bbop=viewtopicp=3864145#3864145 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3864145 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3863391#3863391 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3863391 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 : http://www.jboss.org/index.html?module=bbop=viewtopicp=3863393#3863393 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3863393 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3863394 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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/ | include input=concurrent/ | /source | | source id=tests test=org/jboss/test/**/*TestCase.java | include input=main/ | include input=test-project/ | /source | This leads to all these jars and their depdencies getting included in the classpath for running the tests: | [EMAIL PROTECTED] kernel]$ ant -f jbossbuild.xml show -Dshow=runtest | Buildfile: jbossbuild.xml | | show: | !-- Run tests -- | target name=runtest depends=runtest.tests | /target | | !-- Run tests for the source src/tests -- | target name=runtest.tests | mkdir dir=/home/ejort/jboss-head/workspace/kernel/output/reports/tests/ | delete file=/home/ejort/jboss-head/workspace/kernel/output/reports/tests/test.log/ | junit printsummary=true fork=true | sysproperty key=org.jboss.test.logfile value=/home/ejort/jboss-head/workspace/kernel/output/reports/tests/test.log/ | formatter type=plain/ | classpath | pathelement location=/home/ejort/jboss-head/workspace/thirdparty/gnu-regexp/lib/gnu-regexp.jar/ | pathelement location=/home/ejort/jboss-head/workspace/common/output/lib/namespace.jar/ | pathelement location=/home/ejort/jboss-head/workspace/thirdparty/dom4j-dom4j/lib/dom4j.jar/ | pathelement location=/home/ejort/jboss-head/workspace/thirdparty/apache-xerces/lib/xercesImpl.jar/ | pathelement location=/home/ejort/jboss-head/workspace/thirdparty/apache-commons/lib/commons-httpclient.jar/ | pathelement location=/home/ejort/jboss-head/workspace/thirdparty/apache-log4j/lib/log4j.jar/ | pathelement location=/home/ejort/jboss-head/workspace/thirdparty/wutka-dtdparser/lib/dtdparser121.jar/ | pathelement location=/home/ejort/jboss-head/workspace/test/output/lib/jboss-test.jar/ | pathelement location=/home/ejort/jboss-head/workspace/kernel/output/classes/main/ | pathelement location=/home/ejort/jboss-head/workspace/thirdparty/oswego-concurrent/lib/concurrent.jar/ | pathelement location=/home/ejort/jboss-head/workspace/kernel/output/classes/tests/ | pathelement location=/home/ejort/jboss-head/workspace/thirdparty/apache-jaxme/lib/jaxmexs.jar/ | pathelement location=/home/ejort/jboss-head/workspace/common/output/lib/jboss-common.jar/ | pathelement location=/home/ejort/jboss-head/workspace/thirdparty/apache-slide/client/lib/webdavlib.jar/ | pathelement location=/home/ejort/jboss-head/workspace/thirdparty/junit-junit/lib/junit.jar/ | /classpath | batchtest todir=/home/ejort/jboss-head/workspace/kernel/output/reports/tests | fileset dir=/home/ejort/jboss-head/workspace/kernel/src/tests includes=org/jboss/test/**/*TestCase.java/ | /batchtest | /junit | /target | View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3863471#3863471 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3863471 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 in this case it is - all of them :-) View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3863472#3863472 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3863472 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 token=java.vm.version
value=@{component.build.VMVersion}/
| filter token=java.vm.vendor
value=@{component.build.VMVendor}/
| filter token=specification.title
value=@{component.specTitle}/
| filter token=specification.version
value=@{component.specVersion}/
| filter token=specification.vendor
value=@{component.specVendor}/
| filter token=implementation.title
value=@{component.implTitle}/
| filter token=implementation.url
value=@{component.implURL}/
| filter token=implementation.version
value=@{component.implVersion}/
| filter token=implementation.vendor
value=@{component.implVendor}/
| filter token=implementation.vendor.id
value=@{component.implURL}/
|/filterset
| /copy
| /component
|
The idea would be to extend this to add other information that will be useful
at runtime (including for support purposes).
In this case it would be a list of what a particular jar uses at runtime,
Rather than just a list of jars, this could also include thirdparty version
information and licenses.
We could also indicate that some are optional, e.g. jboss-common.jar
doesn't need log4j.jar (it is an optional plugin for logging with log4j)
We don't need to do this for thirdparty jars, only the our jars.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3863115#3863115
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3863115
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 if not the jars themselves. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3863122#3863122 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3863122 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 input=common-project/...
|
And I have a source node in tasks.xml's build targetdef which applies to
sources with rmic defined:
| source when=@{rmic}
| rmic base=@{output}
| includes=@{rmic}
| ...
|
However, when I run this, ant complians I have duplicate target definitions:
| $ ant -f jbossbuild.xml
| Buildfile: jbossbuild.xml
|
| BUILD FAILED
| C:\projects\jboss-head\naming\jbossbuild.xml:77: Duplicate target:
`build.main'
|
I expected the two targets to be concatenated instead of duplicated. I have
checked in my changes to tasks.xml, so the problem should be reproducible by
adding the rmic attribute as described above.
I think the issue is that SourceDefinition.generateTargets() is adding
SourceDefinitionTargets for each dynamic type regardless if another target for
that type is already defined. Any pointers on this appreciated...
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3863204#3863204
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3863204
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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. Not sure if we want to formalize this into an artifact. 2. I had to explicitly reference the libs that I needed from jboss-common. When I tried to do: | source id=main | include input=common/ | include input=servlet/ | include input=jaf/ | /source | ... the path was resolved to common/output. So instead I had to include the jars explicitly. | source id=main | include input=jboss-common.jar/ | include input=namespace.jar/ | include input=servlet/ | include input=jaf/ | /source | I shouldn't have to reference the jars for a local component any differently than for a non-local one, no? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3862969#3862969 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862969 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
[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 existing build path essentially does. Not sure if we want to formalize this into an artifact. | It is one of the issues on my list to sort out the javax.management classes. My current plan is to include them in a j2se module rather than j2ee. anonymous wrote : | 2. I had to explicitly reference the libs that I needed from jboss-common. When I tried to do: | | | source id=main | | include input=common/ | | include input=servlet/ | | include input=jaf/ | | /source | | | ... the path was resolved to common/output. So instead I had to include the jars explicitly. | | | source id=main | | include input=jboss-common.jar/ | | include input=namespace.jar/ | | include input=servlet/ | | include input=jaf/ | | /source | | | | I shouldn't have to reference the jars for a local component any differently than for a non-local one, no? The difference between servlet and jboss-common.jar is that an includes element has been created in the top level build for convenience: | includes id=servlet | include input=servlet-api.jar/ | include input=jsp-api.jar/ | /includes | The same code be done for common |includes id=jboss-common | include input=jboss-common.jar/ | include input=namespace.jar/ |/includes | This is similar to the way we have libraries.ent and modules.ent with the current build. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3862972#3862972 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862972 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 other dependencies of jboss-common.jar for it to be able to instantiate the classes, namely (in fact I only need a subset of these): | include input=commons/ | include input=concurrent/ | include input=dom4j/ | include input=jaxme/ | include input=log4j/ | include input=regexp/ | include input=slide/ | include input=wutka/ | include input=xerces/ | With the current build, this isn't a problem (I suppose it depends how you define problem) because the testsuite module just includes nearly all the modules and most of thirdparty. But I was thinking we could do better than that this by adding the dependencies to the manifest of the jar. e.g. jboss-microcontainer.jar would have Class-Path: jboss-common.jar, concurrent.jar We could then automatically add these artifacts to the classpath when running tests. This information could also be useful at runtime, potentially allowing the microcontainer to prevalidate the class dependencies. Whether we use the spec defined Class-Path manifest entry (which has some semantics we may not desire) or define our own entry is up for debate. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3862994#3862994 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862994 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 : http://www.jboss.org/index.html?module=bbop=viewtopicp=3863028#3863028 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3863028 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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]$ extcheck -verbose jacorb.jar | Target file:jacorb.jar | Specification title:JBoss | Specification version:4.0.1 | Specification vendor:JBoss (http://www.jboss.org/) | Implementation version:4.0.1 (build: CVSTag=JBoss_4_0_1 date=200412230944) | Implementation vendor:JBoss Inc. | | Comparing with file:/C:/usr/java/j2sdk1.4.2_06/jre/lib/ext/certj.jar | Comparing with file:/C:/usr/java/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar | Comparing with file:/C:/usr/java/j2sdk1.4.2_06/jre/lib/ext/jsafeFIPS.jar | Comparing with file:/C:/usr/java/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar | Comparing with file:/C:/usr/java/j2sdk1.4.2_06/jre/lib/ext/localedata.jar | Comparing with file:/C:/usr/java/j2sdk1.4.2_06/jre/lib/ext/rsajsse.jar | Comparing with file:/C:/usr/java/j2sdk1.4.2_06/jre/lib/ext/sslj.jar | Comparing with file:/C:/usr/java/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar | No conflicting installed jar found. | View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3863035#3863035 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3863035 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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/
| source when=@{rmic}
| rmic base=@{classesPath}
| classpath
| pathElements/
| /classpath
|/rmic
| /source
| /targetdef
|
I guess I would also need to add a depends attribute to the source element in
the build targetdef?
| targetdef target=build description=Build
|:
|source depends=rmic
| mkdir dir=@{output}/etc/
| :
|
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3862813#3862813
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862813
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 srcdir=@{sourcePath}
| ...
| /depend
| javac srcdir=@{sourcePath}
| ...
| /javac
| /source
| // end snipped
| // new rmic code
| source when=rmic
| rmic ...
| include name=@{rmic}/
| /rmic
| /source
|
jbossbuild allows multiple source elements in the targetdef and will take
only those definitions that apply to the given source.
It will append all the relevent tasks together in the order they were specified.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3862815#3862815
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862815
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 document
how jbossbuild works.
The basic philosophy of jbossbuild is that you declare:
Inputs (source and thirdparty jars)
Outputs (artifacts)
and the links between them.
These are then processed through common targetdefs
which can be read as (in the example below about junit tests)
for each source with the attribute test do this...
The parameterization comes from @{property}
which reads properties from the javabean typedefs declared in the build.xml
e.g.
| source when=@{test}
| mkdir dir=@{testDir}/
| junit fork=true
|printSummary=true
|formatter type=plain/
|classpath
| pathElements/
|/classpath
|batchtest todir=@{testDir}
| fileset dir=@{sourceDir} includes=@{test}/
|/batchtest
| /junit
| /source
|
reads as:
for each source in the build.xml that has a test attribute
make the directory returned by SourceDefinition.getTestDir()
(which is output/test/@{id} by default
and run junit over those sources in @{test} putting the results
in the @{testDir}
The pseudo pathElements/ creates a classpath
that includes both the classes from the source compilation and
its dependent jars as defined by the source's includes.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3862658#3862658
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862658
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 it
had
to be done lazily. There is almost certainly some code still present that is
legacy
from the previous way of doing it.
2) There is now an ant show which also takes an optional property
to see specific targets:
| [EMAIL PROTECTED] common]$ ant -f jbossbuild.xml show
-Dshow=build.namespace.jar
| Buildfile: jbossbuild.xml
|
| show:
| !-- Build for the artifact namespace.jar --
| target name=build.namespace.jar
| mkdir dir=/home/ejort/newjboss/jboss-head/common/output/lib/
| jar
manifest=/home/ejort/newjboss/jboss-head/common/output/etc/default.mf
destfile=/home/ejort/newjboss/jboss-head/common/output/lib/namespace.jar
| fileset dir=/home/ejort/newjboss/jboss-head/common/output/classes/main
| include name=javax/xml/namespace/*/
| /fileset
| /jar
| /target
|
3) You can now specify any attribute on a definition which negates the need
to explicitly add code for the use case where you want to pass a parameter from
the
definition to the targetdef.
This says run junit against all source definitions that have a test attribute
build.xml
| source id=test test=**/*TestCase.java
| include input=classes/
| include input=test.path/
| /source
|
tasks.xml
| source when=@{test}
| mkdir dir=@{testDir}/
| junit fork=true
|printSummary=true
|formatter type=plain/
|classpath
| pathElements/
|/classpath
|batchtest todir=@{testDir}
| fileset dir=@{sourceDir} includes=@{test}/
|/batchtest
| /junit
| /source
|
4) Allow an output path to be directly overriden:
This was done because slide is in apache-slide/client rather than lib
5) Allowed includes/excludes when using filesets. This needs to be generalized
to other groupings.
6) Added componentmain as a target definition. This allows the top level build
to run tasks against a component rather than running a target inside the
component
build file.
e.g. in the synchronize task we want to do either a cvs update or co depending
upon whether the component directory actually exists:
| targetdef target=synchronize description=Synchronize
|
| !-- Update the main build folder and tools from cvs
| then do the same for the components before running
| the after synchronization processing
| NOTE: Does not automatically invoke component builds
| as the list of components maybe out-of-date at this point
| and we need to conditionally do cvs co/update
| --
| main components=none
| cvs command=update -dP failonerror=true/
| invoke target=synchronize dir=../tools/
| execant target=synchronize.components/
| execant target=synchronize.after.main/
| /main
|
| !-- If the component exists we just do a cvs update --
| componentmain if=@{exists}
| invoke target=synchronize dir=@{dir}/
| execant target=synchronize.after dir=@{dir}/
| /componentmain
|
| !-- If the component doesn't exist and we want to
| get the source build check it out from cvs
| --
| componentmain unless=@{exists} if=@{local}
| cvs dest=@{dir.parent}
|commandline
| argument value=-d/
| argument value=@{build.cvsroot}/
| argument value=co/
| argument value=@{module}/
|/commandline
| /cvs
| execant target=synchronize.after dir=@{dir}/
| /componentmain
|
7) Some other minor changes I can't remember at the moment?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3862653#3862653
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862653
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: New Build in JBoss-Head
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 those components in jbossas/jbossbuild.xml along with adding references to thirdparty jars 2) Some things are missing from the targetdefs at time of writing: build.bin - processing for src/bin build.resources - processing for src/resources rmic, javacc, aopc compilation sar/war/ejb target builds docbook build (needs including in the overall doc target) I also haven't tested the notion of a file being an artifact, e.g. jbossjca-service.xml 3) Need to externalize the filesets for normal ant targets. The pseudo filesets/ is not available there. e.g. make the following | source id=main | include input=commons/ | include input=concurrent/ | include input=dom4j/ | include input=jaxme/ | include input=log4j/ | include input=regexp/ | include input=slide/ | include input=wutka/ | include input=xerces/ | /source | generate a main.filesets, main.sourcepaths, etc., that can be referenced in the normal fashion 4) Need to build the binary versioned repository (currently it is just using thirdparty as checked from cvs). This will enable developers to only checkout and build those components. 5) Need to complete the cvs checkout processing so it takes into account user ids in the path and passwords for those without sshd. Also need to allow developers to specify what source they want to work on and want can just be binary download from last nights build. This will probably be best implemented using a local.properties file in jbossas 6) Beyond (5) we then need to do the work for developing standalone projects alongside each other. e.g. 1) Allow the cache project to override the binary downloaded into thirdparty with their local source project e.g. 2) Allow the Seams/Portal projects to include a binary build of JBossAS which they can then deploy to rather than it being a multistage checkout/build process View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3862655#3862655 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862655 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
Max Rydahl Andersen wrote: On Thu, 6 Jan 2005 22:41:46 +0100, Christian Bauer [EMAIL PROTECTED] wrote: This looks like the right direction, subant and filelist is what we need. I might be intoxicated, but I actually think about using Maven. At least I'd like to have this feature (and it really looks like we all have to use Eclipse to standardize on our own dogfood): Maven can produce Eclipse .project and .classpath files automatically for you and there is a plugin that keeps your Eclipse configuration in sync with them. This would be killer if it includes code style settings etc. as well. Please no! - not Maven ,) 100% agree. I use Maven in my company and my feelings are : - maven just move the problems - the idea is cool, the implementation not - the plugins are not very well standardized - you'll have to rework some of the default plugins anyway to do what you want (the plugin itself or through a maven.xml file (kind of ant) If the only need/wish is for shared .project/.classpath then please use the ant task that does that instead ! (there is a few of these) +1 But AFAIK these (both the Maven and the Ant based tasks) isn't powerfull enough to be usable,( (and I *guess* this also goes for intellij) The generated files will not be able to include refs to the src and javadocs of the used .jars, thus I'll loose the ability to step through the source code of the external libs. Actually it's quite easy to fix considering we're using a standardized thirdparty structure and naming convention (i did that for maven) And that will (in my world atleast) be a serious pain-in-the-* since I would then need to recreate those links each time I accidently runs the build and overwriting my .classpath and .project. Plus, the automatic eclipse3 build don't really like some maven actions -- Emmanuel Bernard [EMAIL PROTECTED] callto://emmanuelbernard http://www.hibernate.org View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3861216#3861216 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861216 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
This looks like the right direction, subant and filelist is what we need. I might be intoxicated, but I actually think about using Maven. At least I'd like to have this feature (and it really looks like we all have to use Eclipse to standardize on our own dogfood): Maven can produce Eclipse .project and .classpath files automatically for you and there is a plugin that keeps your Eclipse configuration in sync with them. This would be killer if it includes code style settings etc. as well. -- Christian Bauer +49 171 455 66 53 callto://christian-bauer Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] http://jboss.com View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860993#3860993 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860993 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
For code style settings, I'd recommand using Jalopy and its eclipse plugin... but that's a post for another forum :-) About the Mevenide plugin - the sync functionality is great (sync'ing .classpath with the Maven dependencies) but I found it to be buggy also. Made Eclipse do funny things. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860995#3860995 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860995 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
And the developer should not only be able to check out a source tree, but also be able to *update* the tree without throwing things away and re-checking out some modules. This not only saves bandwidth, but also time. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860707#3860707 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860707 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
pilhuhn wrote : And the developer should not only be able to check out a source tree, but also be able to *update* the tree without throwing things away and re-checking out some modules. This not only saves bandwidth, but also time. Yes, that is the purpose of the build definition. If you look at the synchronize method it actually does the following when executed at the top level. 1) Synchronize the main build project (from cvs) 2) Reinvoke ant to pick up any new build.xml downloaded from cvs 3) Do the same for each component (including checking out any new components that may have appeared in the build definition) With the current JBoss build, any new modules or thirdparty jars requires the developer to look at CVSROOT/modules then go to the relevent directory and do a cvs co or blow away the whole thing and check out from scratch. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860774#3860774 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860774 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
The synchronize also regenerates any ide project files from the build definition so all you have to do is refresh inside the ide (and maybe import new projects) View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860776#3860776 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860776 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
[EMAIL PROTECTED] wrote :
| ${somedir}/JBossAS - the main integration build
| ${somedir}/test1 - test1 component
| ${somedir}/test2 - test2 component
| ${somedir}/tools - the tools directory containing jboss/tasks.xml
|
I notice that you declared jboss-common.jar as a dependency of JBossAS, so I
assume you see some of the existing components essentially becoming thirdparty
libraries of the AS -- being downloaded from the repository along with log4j.
At the same time, other components (test1 test2) are checked out of CVS and
compiled from source.
Why the difference? Why not just have all the existing components become
external libraries?
If all of the existing components were migrated to standalone projects, they
could be integrated into the AS just like any thirdparty library. Their
artifacts would be pulled from the repository just like log4j.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3860643#3860643
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860643
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
Hi Ryan, I don't anticipate that all builds will be standalone. And certainly developers won't want 20-50 standalone projects that they have to build separately, update the jars to some location then build the next until you get a final project. The idea of the build is that the developer can checkout the projects they want to work on. Where they aren't going to modify a project (or use a project under development) they can just download the binary into thirdparty. The projects they do want to work on, can be checked out from cvs as source components. For the nightly builds, cruise control could checkout all the projects as source and rebuild the whole thing in one go. In this example, the project is using the jboss-common.jar as a binary but test1 and test2 are under development. If I were to develop it further, I would add a local properties file where the developer could specify which elements of the project they want as binary and which they want the source/latest development version. The default being as now (all components checked out as source). View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860651#3860651 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860651 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
Just to clarify since none of the examples above has it, it would be something like: | build | cvsroot=cvs.sf.net/projects/jboss | tag=Branch_3_2 | location=http://www.jboss.org/jboss-3.2/ | | ... | | component id=common | cvsmodule=common | location=common | artifact id=jboss-common.jar/ | /component | ... | Then the developer can choose whether the common module is checked out from cvs or the artificats downloaded from a versioned repository. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860656#3860656 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860656 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
[EMAIL PROTECTED] wrote : | And certainly developers won't want 20-50 standalone projects that they have to build | separately, update the jars to some location then build the next until you get a final | project. | Right, I agree this is not what we want. You shouldn't have to build all standalone projects to build JBAS. Instead, the build script should just download the 20-50 jar files for you. [EMAIL PROTECTED] wrote : | In this example, the project is using the jboss-common.jar as a binary | but test1 and test2 are under development. | Ok, this makes sense. I agree that a developer should be able to check out specific dependencies and use the build artifacts from source rather than the downloaded binaries. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860660#3860660 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860660 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
So I was playing with ant over the Christmas holiday and after a couple of
iterations,
I came up with something that works and provides a more declaritive
way of building projects.
This is just a quick overview. I didn't work too hard on the thirdparty
libraries since I didn't have a copy of cvs server on my machine.
The basic idea is that you declare the top level integration build then declare
each component. All the common stuff is defined in a separate tasks file.
Although the declarations require some code, I tried to keep it user definable
as
possible.
Examples following in subsequent posts,
Imagine a project structured as follows:
${somedir}/JBossAS - the main integration build
${somedir}/test1 - test1 component
${somedir}/test2 - test2 component
${somedir}/tools - the tools directory containing jboss/tasks.xml
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3860507#3860507
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860507
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
The component build defines how to build the artifacts referenced in the main build: There is a componentdef and an artifactdef referencing the ids defined in the main build file. There are also definitions so you can differentiate the different source types. e.g. I can imagine source types of main (like we have now), interfaces, implementation, client (classes used on the client), test (the test classes not for distribution), etc. | ?xml version=1.0? | | !-- | JBoss, the OpenSource J2EE webOS | | Distributable under LGPL license. | See terms of license at gnu.org. | -- | project name=project | default=build | basedir=. | |!-- The main build -- |import file=../JBossAS/build.xml/ | |includes id=classes | include input=main/ |/includes | |!-- The component definition -- |componentdef component=test2 description=Project test2 | | source id=main | include input=test1.jar/ | include input=jboss-common.jar/ | /source | | artifactdef artifact=test2.jar | include input=classes/ | /artifactdef | | source id=test test=**/*TestCase.java | include input=classes/ | include input=test.path/ | /source | | artifactdef artifact=test2.api | include input=main/ | include input=test/ | /artifactdef |/componentdef | | /project | View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860510#3860510 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860510 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
The main build contains a declaration of the components that make up the overall integration project: | ?xml version=1.0? | | !-- | JBoss, the OpenSource J2EE webOS | | Distributable under LGPL license. | See terms of license at gnu.org. | -- | project name=main.build | default=build | basedir=. | |!-- Import the types -- |import file=../tools/jboss/tasks.xml/ | |!-- The test classpath -- |includes id=test.path | include input=junit.jar/ |/includes | |!-- The build -- |build id=JBossAS | version=5.0.0alpha | description=JBoss Application Server | targetdefs=targets | | component id=jboss | artifact id=jboss-common.jar | location=file:///home/ejort/jboss-head/workspace/common/output/lib/jboss-common.jar | / | /component | | component id=junit | artifact id=junit.jar | location=file:///home/ejort/jboss-head/workspace/thirdparty/junit-junit/lib/junit.jar | / | /component | | component id=test1 | artifact id=test1.jar release=lib/ | artifact id=test1.api/ | /component | | component id=test2 | artifact id=test2.jar release=lib/ | artifact id=test2.api/ | /component |/build | | /project | build - defines what you are building component - defines the subprojects which might be thirdparty rather than local projects artifact - defines what you expect to come out of the component and where it should be placed in the integration release structure. Like I said, I didn't do too much work on the thirdparty/download stuff. But you can imagine that it can contain the location of the components that maybe urls or cvs checkout parameters. I would imagine that the location would contain the version of the jar in the url? I would also image that most of the CVS parameters would be common and actually defined in the , e.g. the CVSROOT and the tag. You can ignored the this just works to define a common classpath in this case the jars required for running tests. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860509#3860509 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860509 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
Before I go further, the two files can be combined if you just want a standalone project, e.g.: This file will actually cause my ant classes to build themselves... | ?xml version=1.0? | | !-- | JBoss, the OpenSource J2EE webOS | | Distributable under LGPL license. | See terms of license at gnu.org. | -- | project name=project | default=build | basedir=. | |!-- Import the types -- |import file=src/resources/tasks.xml/ | |build id=JBossBuild targetdefs=targets description=The main build | | component id=ant | artifact id=ant.jar |location=file:///usr/java/apache-ant-1.6.2/lib/ant.jar | / | /component | | component id=jbossbuild | artifact id=jbossbuild.jar/ | artifact id=jbossbuild.api/ | /component |/build | |!-- The component definition -- |componentdef component=jbossbuild description=JBoss Build | | source id=main | include input=ant.jar/ | /source | | artifactdef artifact=jbossbuild.jar | include input=main/ | /artifactdef | | artifactdef artifact=jbossbuild.api | include input=main/ | /artifactdef |/componentdef | | /project | View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860511#3860511 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860511 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
Finally we have the tasks.xml where all the magic occurs:
| ?xml version=1.0?
|
| !--
| JBoss, the OpenSource J2EE webOS
|
| Distributable under LGPL license.
| See terms of license at gnu.org.
| --
| project name=jboss.ant.tasks
| default=help
|
|!-- PROPERTIES --
|
|!-- JBoss Tasks Classpath --
|property name=jboss.tasks.path
| value=../jbossbuild/output/eclipse-classes/main
|/
|
|!-- TYPEDEFS --
|
|!-- The build type --
|typedef name=build
| classname=org.jboss.ant.types.build.Build
| loaderRef=jboss.tasks.path
| classpath=${jboss.tasks.path}
|/
|
|!-- The artifact type definition type --
|typedef name=artifacttype
| classname=org.jboss.ant.types.build.ArtifactType
| loaderRef=jboss.tasks.path
| classpath=${jboss.tasks.path}
|/
|
|!-- The component definition type --
|typedef name=componentdef
| classname=org.jboss.ant.types.component.ComponentDefinition
| loaderRef=jboss.tasks.path
| classpath=${jboss.tasks.path}
|/
|
|!-- The includes type --
|typedef name=includes
| classname=org.jboss.ant.types.Includes
| loaderRef=jboss.tasks.path
| classpath=${jboss.tasks.path}
|/
|
|!-- The build targets type --
|typedef name=targets
| classname=org.jboss.ant.types.target.TargetDefinitions
| loaderRef=jboss.tasks.path
| classpath=${jboss.tasks.path}
|/
|
|!-- TASKDEFS --
|
|!-- Update ide info for the main build --
|taskdef name=idemain
| classname=org.jboss.ant.tasks.build.IDETask
| loaderRef=jboss.tasks.path
| classpath=${jboss.tasks.path}
|/
|
|!-- Update ide info for the component --
|taskdef name=idecomponent
| classname=org.jboss.ant.tasks.component.IDETask
| loaderRef=jboss.tasks.path
| classpath=${jboss.tasks.path}
|/
|
|!-- DEFINITIONS --
|
|!-- The artifact types --
|artifacttype id=jar outputtype=lib/
|artifacttype id=api outputtype=api/
|
|!-- The default targets --
|targets id=targets
|
| !-- Build All --
| targetdef target=all description=Build All
| main depends=build, doc, test, archives components=none/
| component depends=build, doc, test/
| /targetdef
|
| !-- Build --
| targetdef target=build description=Build
|
| !-- Build the main release --
| main
| mkdir dir=@{releaseDir}/
| antCall target=release/
| /main
|
| !-- Build the component --
| component
| mkdir dir=@{output}/
| /component
|
| !-- Compile the source --
| source
| mkdir dir=@{output}/
| depend srcdir=@{sourcePath} destdir=@{output}
|classpath
| pathelements/
|/classpath
| /depend
| javac srcdir=@{sourcePath} destdir=@{output}
|classpath
| pathelements/
|/classpath
| /javac
| /source
|
| !-- Create a jar archive --
| jar
| mkdir dir=@{parentDir}/
| jar destfile=@{output}
|filesets/
| /jar
| /jar
| /targetdef
|
| !-- Build the release --
| targetdef target=release
|
| !-- Copy the artifact into the release --
| artifact when=@{release}
| mkdir dir=@{release}/
| copy todir=@{release}
|output/
| /copy
| /artifact
| /targetdef
|
| !-- Build the release archives --
| targetdef target=archives
|
| !-- Make the archives --
| main
|
| !-- Create the zip file --
| zip destfile=@{output}/@{releaseName}.zip
| basedir=@{releaseDir}
| /
| /main
| /targetdef
|
| !-- Documentation --
| targetdef target=doc description=Documentation
|
| !-- Generate the documentation --
| component depends=api/
| /targetdef
|
| !-- Javadoc --
| targetdef target=api description=Javadoc
|
| !-- Generate the javadoc --
| component/
| api
| mkdir dir=@{output}/
| javadoc packagenames=*
| destdir=@{output}
|
|doctitle
|
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
targets/targetdefs
On the main build there was a reference to the targets
| build id=JBossAS
| ...
| targetdefs=targets
|
This defines a list of targetdefs and what each should do on the different
portions
of the build
main - the top level integration build
component - a component project
common - convenience type when main and component are the same
source - source targets, e.g. compilation
artifact - these are per artifact type so you actually see jar and api rather
than
artifact
Take a simple example:
| !-- Clean the output --
| targetdef target=clean description=Clean
| common
| delete dir=@{output}/
| /common
| /targetdef
|
This says for top level and component builds we delete the output directory
More complicated
|
| !-- Build the release --
| targetdef target=release
|
| !-- Copy the artifact into the release --
| artifact when=@{release}
| mkdir dir=@{release}/
| copy todir=@{release}
|output/
| /copy
| /artifact
| /targetdef
|
For each artifact that has a release attribute, we copy it to that release
location
Probably the most complicated?
|
| !-- Build --
| targetdef target=build description=Build
|
| !-- Build the main release --
| main
| mkdir dir=@{releaseDir}/
| antCall target=release/
| /main
|
| !-- Build the component --
| component
| mkdir dir=@{output}/
| /component
|
| !-- Compile the source --
| source
| mkdir dir=@{output}/
| depend srcdir=@{sourcePath} destdir=@{output}
|classpath
| pathelements/
|/classpath
| /depend
| javac srcdir=@{sourcePath} destdir=@{output}
|classpath
| pathelements/
|/classpath
| /javac
| /source
|
| !-- Create a jar archive --
| jar
| mkdir dir=@{parentDir}/
| jar destfile=@{output}
|filesets/
| /jar
| /jar
| /targetdef
|
On the top level build we create the release
The component level is trivial
The source level is just to compile it
The artifact level involves jaring the referenced source classes
The artifact definition
| source id=main
| include input=test1.jar/
| include input=jboss-common.jar/
| /source
| artifactdef artifact=test2.jar
| include input=main/
| /artifactdef
|
The source has an id main which the jar includes as its input
The targetdef:
| jar
| mkdir dir=@{parentDir}/
| jar destfile=@{output}
|filesets/
| /jar
| /jar
|
This says take all the files sets that are the input to a jar artifact
Each
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3860513#3860513
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860513
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
And this is the kind of targets that get generated: top level | [EMAIL PROTECTED] JBossAS]$ ant -projecthelp | Buildfile: build.xml | | Main targets: | | all Build All for everything | all.componentsBuild All for all the components | all.main Build All for the main build only | all.test1 Build All for the component test1 | all.test2 Build All for the component test2 | api Javadoc for everything | api.componentsJavadoc for all the components | api.test1 Javadoc for the component test1 | api.test2 Javadoc for the component test2 | build Build for everything | build.components Build for all the components | build.mainBuild for the main build only | build.test1 Build for the component test1 | build.test2 Build for the component test2 | clean Clean for everything | clean.components Clean for all the components | clean.mainClean for the main build only | clean.test1 Clean for the component test1 | clean.test2 Clean for the component test2 | clobber Clobber for everything | clobber.main Clobber for the main build only | commitCommit for everything | commit.components Commit for all the components | commit.main Commit for the main build only | commit.test1 Commit for the component test1 | commit.test2 Commit for the component test2 | doc Documentation for everything | doc.componentsDocumentation for all the components | doc.test1 Documentation for the component test1 | doc.test2 Documentation for the component test2 | rebuild Synchronize then build | rebuildallSynchronize then build all | synchronize Synchronize for everything | synchronize.componentsSynchronize for all the components | synchronize.jboss-common.jar Synchronize for the artifact jboss-common.jar | synchronize.junit.jar Synchronize for the artifact junit.jar | synchronize.main Synchronize for the main build only | synchronize.test1 Synchronize for the component test1 | synchronize.test2 Synchronize for the component test2 | test Run the Tests for everything | test.components Run the Tests for all the components | test.test1Run the Tests for the component test1 | test.test2Run the Tests for the component test2 | Default target: build | component level | [EMAIL PROTECTED] test2]$ ant -projecthelp | Buildfile: build.xml | | Main targets: | | all Build All | api Javadoc | api.test2.apiJavadoc for the artifact test2.api | buildBuild | build.main Build for the source src/main | build.test Build for the source src/test | build.test2.jar Build for the artifact test2.jar | cleanClean | commit Commit | doc Documentation | rebuild Synchronize then build | rebuildall Synchronize then build all | synchronize Synchronize | test Run the Tests | Default target: build | View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860514#3860514 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860514 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
A basic critique (broad brush stuff) PROS of this approach: 1) It is very declartive (though not very human readable) 2) The inputs and outputs are clearly defined and readily available to tools 3) The links between the components/artifacts are clearly defined (you can see what includes what) 4) The declaritive approach makes the build easy to validate 5) The build files are very small and simple CONS of this approach 1) It has the same problem as buildmagic in that the process of the build is obfuscated (although I believe the notions involved can be easily learnt) 2) The idea of an integration build doesn't sit well with the components also being a standalone project (they directly include the integeration project) | project name=project | default=build | basedir=. | |!-- The main build -- |import file=../JBossAS/build.xml/ | 3) The ant typedef has some limitations which I have been able to workaround 4) Internally it generates ant macros from the typedefs. This is not well defined in the ant documentation and I may have fallen foul of an undocmented feature. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3860515#3860515 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860515 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
Clarification. The targetdefs contain @ parameters. These are attributes
that come from each typedef,
e.g. test source is identified by a pattern to identify test case classes
| source id=test test=**/*TestCase.java
| include input=classes/
| include input=test.path/
| /source
|
This is used in the target def for running tests
| !-- Run the Test --
| targetdef target=runtest
| component/
| source when=@{test}
| mkdir dir=@{testDir}/
| junit fork=true
|printSummary=true
|formatter type=plain/
|classpath
| pathElements/
|/classpath
|batchtest todir=@{testDir}
| fileset dir=@{sourceDir} includes=@{test}/
|/batchtest
| /junit
| /source
| /targetdef
|
Most of the attributes have reasonable defaults that can be overriden
integration wide on the build element or for each component/artifact.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3860516#3860516
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3860516
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
Maven can produce Eclipse .project and .classpath files automatically for you. It also has the ability to pull down dependency jars (with versioning). It also has features for subcomponent and super project definitions (though I've never used that part of it). Have you considered maven? It does take getting used to and I admit I've had mixed results. However, it does have some very nice features. BTW: Mevenide is an Eclipse plugin that allows you to synchronize your Eclipse .classpath with the Maven config - so no more will you have to examine the ant build scripts to determine your environment and manually port that to your Eclipse environment. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859756#3859756 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859756 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
ok, so I read the other thread about To Maven Or Not and it seems most folks are dead set against it. So... never mind (I'm not married to maven; I was more or less curious as to what people think - now I know :-) View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859759#3859759 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859759 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
Some tools which provide maven-like dependency resolution: Savant - http://inversoft.com/online/savant/savant.html Antlion - http://antlion.sourceforge.net/inline-manual/ht-libraries.html Both of these are just Ant task libraries. They both can download depedencies from a repository and integrate with your build by producing ant paths which you can use in your compile target. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859765#3859765 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859765 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
[EMAIL PROTECTED] wrote : | However, I can't find a way to control the order in which subant builds each module. Perhaps this can be done by explicitly ordering the modules in the fileset passed to subant, but I don't think this ordering is guaranteed. | See the FileList subelement View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859610#3859610 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859610 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
I propose to spend some time fixing the build to use plain ant1.6 features and make the thing incremental. I tried before, but people have gradually broken it. That includes removing the totally unscalable xdoclet generation of mbean interfaces. Having, just started to use eclipse for development, it is so much easier when you build is incremental to get a turnaround on testing. i.e. Change the code, build (what has changed), run the test, takes a few seconds rather than a few minutes. We need this in the main JBoss build. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859484#3859484 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859484 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
This task looks like it can do most (if not all) of buildmagic is trying to achieve: http://ant.apache.org/manual/CoreTasks/subant.html View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859489#3859489 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859489 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
Hook up with Ryan to get this done. This is his top priority post the jira migration. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859513#3859513 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859513 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
I agree that ant 1.6 features can be used to replace large parts of buildmagic.tools/buildmagic/buildmagic.ent should become a template from which other build files can import and customize via properties and overrides. However, I can't find a way to control the order in which subant builds each module. Perhaps this can be done by explicitly ordering the modules in the fileset passed to subant, but I don't think this ordering is guaranteed. What is the alternative to xdoclet? View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859528#3859528 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859528 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
xdoclet is really a seperate issue from the existing structure problems and build system. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859532#3859532 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859532 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
It seems like many of these issues are symptomatic of the application server project hosting the code of so many super-subprojects like aop and the microcontainer. Are these going to be split into their own projects? IE, can aop become a thirdparty jar for the application server? I have put together some ideas on how the build system might deal with such an organization. http://www.jboss.org/wiki/Wiki.jsp?page=BuildDependencyManagement It also addresses management of thirdparty libraries in a more scalable manner. As an aside, by providing declarative dependencies, it would be possible to do things like automatically generate eclipse .classpath files automatically. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859536#3859536 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859536 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [Design of JBoss Build System] - Re: NEW BUILD
Yes, that is the idea. Seperation of the projects needs to be combined with increased integration tests not owned by the project developers to validate that the expected contracts are maintained across versions. View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=3859541#3859541 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3859541 --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
