[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
[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
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
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
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
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,
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
[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
[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
[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
[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
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.
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
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
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
[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
16 matches
Mail list logo
