You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Steve Vinoski <vi...@iona.com> on 2006/12/07 20:04:12 UTC
[java] generated framing code
I recently emailed about build avoidance issues with the generated
framing code under common. The way it's done means that it builds
every single time through, and does nothing at all to try to avoid
the build if the spec file hasn't changed.
Rajith and I have now both independently run into more problems with
this code: it won't work under Eclipse. The code is generated into
directory names that contain spec version numbers (e.g., org/apache/
qpid/framing_8_0), but the actual code itself is declared to reside
in the org.apache.qpid.framing package. This is clearly a no-no, and
Eclipse refuses to build it.
So, anybody have an idea as to when we'll start using the new code
generation approach? The code seems to have existed for weeks now,
but to the best of my knowledge, nobody's stated any intent regarding
making it part of the normal trunk build.
Also, will this new code address the build avoidance issues and the
Eclipse issues?
I need to know, because I don't want to go off and fix issues with
the current stuff if it's all about to be replaced. We have several
people who want to use Eclipse for Qpid work, and they're currently
blocked by this.
--steve
Re: [java] generated framing code
Posted by Steve Vinoski <vi...@iona.com>.
On Dec 7, 2006, at 2:35 PM, Daniel Kulp wrote:
> On Thursday 07 December 2006 14:04, Steve Vinoski wrote:
>> I recently emailed about build avoidance issues with the generated
>> framing code under common. The way it's done means that it builds
>> every single time through, and does nothing at all to try to avoid
>> the build if the spec file hasn't changed.
>>
>> Rajith and I have now both independently run into more problems with
>> this code: it won't work under Eclipse. The code is generated into
>> directory names that contain spec version numbers (e.g., org/apache/
>> qpid/framing_8_0), but the actual code itself is declared to reside
>> in the org.apache.qpid.framing package. This is clearly a no-no, and
>> Eclipse refuses to build it.
>>
>> So, anybody have an idea as to when we'll start using the new code
>> generation approach? The code seems to have existed for weeks now,
>> but to the best of my knowledge, nobody's stated any intent regarding
>> making it part of the normal trunk build.
>>
>> Also, will this new code address the build avoidance issues and the
>> Eclipse issues?
>>
>> I need to know, because I don't want to go off and fix issues with
>> the current stuff if it's all about to be replaced. We have several
>> people who want to use Eclipse for Qpid work, and they're currently
>> blocked by this.
>>
>> --steve
>
> I've included a patch below to fix that generation problem. There
> is still a
> problem in the client tests with a .java file in the wrong
> directory. That
> and 618 warnings if you use a "default" Eclipse workspace.
Hi Dan, I can look into applying this patch, but a big part of the
problem here is that this code is intended to somehow magically
support multiple versions of the spec.xml file. I guess the intent is
to generate it into versioned directories but use a non-versioned
package name so that no version numbers would appear in the code. I
don't know how that can actually work in practice, though.
Unless someone objects, perhaps for now I'll just work around all the
"multiple versions" stuff here and fix these problems for now, given
that we have only a single spec version at the moment, and then
whoever switches over to the new generator can make sure it all keeps
working when they commit the new stuff.
--steve
Re: [java] generated framing code
Posted by Daniel Kulp <da...@iona.com>.
On Thursday 07 December 2006 14:04, Steve Vinoski wrote:
> I recently emailed about build avoidance issues with the generated
> framing code under common. The way it's done means that it builds
> every single time through, and does nothing at all to try to avoid
> the build if the spec file hasn't changed.
>
> Rajith and I have now both independently run into more problems with
> this code: it won't work under Eclipse. The code is generated into
> directory names that contain spec version numbers (e.g., org/apache/
> qpid/framing_8_0), but the actual code itself is declared to reside
> in the org.apache.qpid.framing package. This is clearly a no-no, and
> Eclipse refuses to build it.
>
> So, anybody have an idea as to when we'll start using the new code
> generation approach? The code seems to have existed for weeks now,
> but to the best of my knowledge, nobody's stated any intent regarding
> making it part of the normal trunk build.
>
> Also, will this new code address the build avoidance issues and the
> Eclipse issues?
>
> I need to know, because I don't want to go off and fix issues with
> the current stuff if it's all about to be replaced. We have several
> people who want to use Eclipse for Qpid work, and they're currently
> blocked by this.
>
> --steve
I've included a patch below to fix that generation problem. There is still a
problem in the client tests with a .java file in the wrong directory. That
and 618 warnings if you use a "default" Eclipse workspace.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Index: common/protocol-version.xml
===================================================================
--- common/protocol-version.xml (revision 483576)
+++ common/protocol-version.xml (working copy)
@@ -61,8 +61,8 @@
flags="s" byline="true"/>
<!-- Create directory; generate from specification file -->
- <mkdir
dir="${generated.dir}_${@{ver}.amqp(major)}_${@{ver}.amqp(minor)}"/>
- <saxon
out="${generated.dir}_${@{ver}.amqp(major)}_${@{ver}.amqp(minor)}/results.out"
+ <mkdir dir="${generated.dir}"/>
<!--_${@{ver}.amqp(major)}_${@{ver}.amqp(minor)}"/-->
+ <saxon out="${generated.dir}/results.out"
src="${specs.dir}/amqp-@{ver}.xml"
xsl="${spec.stylesheet}">
<arg value="major=${@{ver}.amqp(major)}"/>
@@ -70,14 +70,14 @@
<arg value="registry_name=MainRegistry"/>
</saxon>
<!-- -->
- <saxon
out="${generated.dir}_${@{ver}.amqp(major)}_${@{ver}.amqp(minor)}/cluster.out"
+ <saxon out="${generated.dir}/cluster.out"
src="${cluster.asl}"
xsl="${spec.stylesheet}">
<arg value="major=${@{ver}.amqp(major)}"/>
<arg value="minor=${@{ver}.amqp(minor)}"/>
<arg value="registry_name=ClusterRegistry"/>
</saxon>
- <saxon
out="${generated.dir}_${@{ver}.amqp(major)}_${@{ver}.amqp(minor)}/registry.out"
+ <saxon out="${generated.dir}/registry.out"
src="${registry.template}"
xsl="${registry.stylesheet}">
<arg value="major=${@{ver}.amqp(major)}"/>
Re: [java] generated framing code
Posted by Steve Vinoski <vi...@iona.com>.
On Dec 7, 2006, at 3:19 PM, Steve Vinoski wrote:
> On Dec 7, 2006, at 2:37 PM, Carl Trieloff wrote:
>
>>
>> We should just get onto the new code generators - they are working
>> and just need to be integrated, then work from
>> that point forward. Think Kim will get to it next week, but I am
>> sure he will respond or point you in the right direction
>> if you want to help integrate them.
>
> Next week is too late. We have people who've been wanting to use
> Eclipse for awhile now, and it's become a stopper.
>
> As I said in my earlier response to Dan, I think I'll fix what's
> there now so it'll work with Eclipse. I know nothing about the new
> code generators and have no idea whether they'll even work with
> Eclipse, and so would rather fix the current stuff while the new
> stuff is verified to work with Eclipse.
I see Kim beat me to it! :-) I also have some top-level pom changes
I'm working on for Eclipse support, which I'll hopefully commit shortly.
thanks,
--steve
Re: [java] generated framing code
Posted by Steve Vinoski <vi...@iona.com>.
On Dec 7, 2006, at 2:37 PM, Carl Trieloff wrote:
>
> We should just get onto the new code generators - they are working
> and just need to be integrated, then work from
> that point forward. Think Kim will get to it next week, but I am
> sure he will respond or point you in the right direction
> if you want to help integrate them.
Next week is too late. We have people who've been wanting to use
Eclipse for awhile now, and it's become a stopper.
As I said in my earlier response to Dan, I think I'll fix what's
there now so it'll work with Eclipse. I know nothing about the new
code generators and have no idea whether they'll even work with
Eclipse, and so would rather fix the current stuff while the new
stuff is verified to work with Eclipse.
--steve
Re: [java] generated framing code
Posted by Carl Trieloff <cc...@redhat.com>.
We should just get onto the new code generators - they are working and
just need to be integrated, then work from
that point forward. Think Kim will get to it next week, but I am sure he
will respond or point you in the right direction
if you want to help integrate them.
Carl.
Steve Vinoski wrote:
> I recently emailed about build avoidance issues with the generated
> framing code under common. The way it's done means that it builds
> every single time through, and does nothing at all to try to avoid the
> build if the spec file hasn't changed.
>
> Rajith and I have now both independently run into more problems with
> this code: it won't work under Eclipse. The code is generated into
> directory names that contain spec version numbers (e.g.,
> org/apache/qpid/framing_8_0), but the actual code itself is declared
> to reside in the org.apache.qpid.framing package. This is clearly a
> no-no, and Eclipse refuses to build it.
>
> So, anybody have an idea as to when we'll start using the new code
> generation approach? The code seems to have existed for weeks now, but
> to the best of my knowledge, nobody's stated any intent regarding
> making it part of the normal trunk build.
>
> Also, will this new code address the build avoidance issues and the
> Eclipse issues?
>
> I need to know, because I don't want to go off and fix issues with the
> current stuff if it's all about to be replaced. We have several people
> who want to use Eclipse for Qpid work, and they're currently blocked
> by this.
>
> --steve
Re: [java] generated framing code
Posted by Kim van der Riet <ki...@redhat.com>.
I'll probably be starting the integration of the new generator into Java
next week. (This week I'm tied down with AMQP 0-9 spec editing and
release issues).
In the mean time, I have checked in a change that generates to the
framing directory. Be aware that if a second version is introduced, it
will overwrite the files of the first version. So as long as this is in
use, only one version at a time.
As I'm sending this, I see Daniel Kulp suggested an almost identical
patch. Thanks, Daniel.
Kim
On Thu, 2006-12-07 at 14:04 -0500, Steve Vinoski wrote:
> I recently emailed about build avoidance issues with the generated
> framing code under common. The way it's done means that it builds
> every single time through, and does nothing at all to try to avoid
> the build if the spec file hasn't changed.
>
> Rajith and I have now both independently run into more problems with
> this code: it won't work under Eclipse. The code is generated into
> directory names that contain spec version numbers (e.g., org/apache/
> qpid/framing_8_0), but the actual code itself is declared to reside
> in the org.apache.qpid.framing package. This is clearly a no-no, and
> Eclipse refuses to build it.
>
> So, anybody have an idea as to when we'll start using the new code
> generation approach? The code seems to have existed for weeks now,
> but to the best of my knowledge, nobody's stated any intent regarding
> making it part of the normal trunk build.
>
> Also, will this new code address the build avoidance issues and the
> Eclipse issues?
>
> I need to know, because I don't want to go off and fix issues with
> the current stuff if it's all about to be replaced. We have several
> people who want to use Eclipse for Qpid work, and they're currently
> blocked by this.
>
> --steve