You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Weston M. Price" <wp...@redhat.com> on 2012/05/04 16:41:55 UTC
Project Dependencies
In the JCA example code, we have a dependency on the Servlet API. Currently we include a few JEE jars from Geronimo (ejb, jca etc). I would like the include the geronimo-servlet-spec jar as well. Is it as simple as taking a copy of the jar and putting it in the java/lib directory or is there something more to it?
Regards,
Weston
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Project Dependencies
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, May 04, 2012 at 12:26:31PM -0400, Weston M. Price wrote:
>
> On May 4, 2012, at 12:17 PM, Darryl L. Pierce wrote:
>
> > On Fri, May 04, 2012 at 10:41:55AM -0400, Weston M. Price wrote:
> >> In the JCA example code, we have a dependency on the Servlet API. Currently we include a few JEE jars from Geronimo (ejb, jca etc). I would like the include the geronimo-servlet-spec jar as well. Is it as simple as taking a copy of the jar and putting it in the java/lib directory or is there something more to it?
> >
> > Side question:
> >
> > Are there any plans to, in future, go with a Maven development
> > environment for the Java code? That way we can avoid versioning
> > artifacts.
> >
> I believe we tried this before and it was rife with issues. Personally, I have never been a big fan of Maven for a variety of reasons. Robbie has proposed using Ivy for our dependency management which I believe, and again, this is my own opinion, does a good job of giving you dependency management without forcing a particular project structure, build system etc.
I'm looking at it from the perspective of not wanting to carry tons of
binary blogs in our version history. If we had our own public Maven repo
we could use it to ensure availability of dependencies (in cases where
the public maven repo somehow loses or doesn't carry one) if that was
one of the objections.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Project Dependencies
Posted by "Weston M. Price" <wp...@redhat.com>.
On May 4, 2012, at 12:17 PM, Darryl L. Pierce wrote:
> On Fri, May 04, 2012 at 10:41:55AM -0400, Weston M. Price wrote:
>> In the JCA example code, we have a dependency on the Servlet API. Currently we include a few JEE jars from Geronimo (ejb, jca etc). I would like the include the geronimo-servlet-spec jar as well. Is it as simple as taking a copy of the jar and putting it in the java/lib directory or is there something more to it?
>
> Side question:
>
> Are there any plans to, in future, go with a Maven development
> environment for the Java code? That way we can avoid versioning
> artifacts.
>
I believe we tried this before and it was rife with issues. Personally, I have never been a big fan of Maven for a variety of reasons. Robbie has proposed using Ivy for our dependency management which I believe, and again, this is my own opinion, does a good job of giving you dependency management without forcing a particular project structure, build system etc.
Regards,
Weston
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Project Dependencies
Posted by Robbie Gemmell <ro...@gmail.com>.
Hi Darryl,
Looks like you night have missed the mail thread I started yesterday
about stopping versioning dependency artifacts.We should be doing
somthing almost immediately (i.e next week, I have already put
together part of it) on that point.
On using Maven, that would be a larger discussion and work effort to
move us over. I admit I would use Maven if we were starting from
scratch, there is little doubt it offers benefits, but it would be a
fair amount of effort to swap over that is hard to justify in some
ways and there is an unfortunate history with its prior usage in the
project that I think puts many off.
I also wouldnt want to end up with 2 build systems running side by
side before anyone suggests it, thats been done already :)
Robbie
On 4 May 2012 17:17, Darryl L. Pierce <dp...@redhat.com> wrote:
> On Fri, May 04, 2012 at 10:41:55AM -0400, Weston M. Price wrote:
>> In the JCA example code, we have a dependency on the Servlet API. Currently we include a few JEE jars from Geronimo (ejb, jca etc). I would like the include the geronimo-servlet-spec jar as well. Is it as simple as taking a copy of the jar and putting it in the java/lib directory or is there something more to it?
>
> Side question:
>
> Are there any plans to, in future, go with a Maven development
> environment for the Java code? That way we can avoid versioning
> artifacts.
>
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Project Dependencies
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, May 04, 2012 at 10:41:55AM -0400, Weston M. Price wrote:
> In the JCA example code, we have a dependency on the Servlet API. Currently we include a few JEE jars from Geronimo (ejb, jca etc). I would like the include the geronimo-servlet-spec jar as well. Is it as simple as taking a copy of the jar and putting it in the java/lib directory or is there something more to it?
Side question:
Are there any plans to, in future, go with a Maven development
environment for the Java code? That way we can avoid versioning
artifacts.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Project Dependencies
Posted by "Weston M. Price" <wp...@redhat.com>.
On May 4, 2012, at 12:38 PM, Weston M. Price wrote:
>
> On May 4, 2012, at 12:23 PM, Weston M. Price wrote:
>
>>
>> On May 4, 2012, at 11:39 AM, Robbie Gemmell wrote:
>>
>>> You would also need to add an entry to the build.deps file for the new
>>> jar, and update the existing entry for the ra module in build.deps to
>>> say it depends on it.
>> Yep, this I knew, but the question was primarily around where to get/access the jar. Sounds like it's a manual process versus automated.
>>>
>>> This also reminds me to bring up something. There is a hack in the
>>> build.deps file for the adapter with a comment saying it has to
>>> duplicate some definitions because the systests module is looking for
>>> jca instead of ra. It wasnt clear to be why the systests module had
>>> been configured to depend on something that doesnt actually exist in
>>> the first place?
>>>
>> From what I remember, when I was setting this up this was a naming thing when one project was looking for 'ra' but the jca project itself needed 'jca'. I remember changing the name and for some reason the artifacts that were generated suddenly were named qpid-jca-0.x.rar versus qpid-ra-0.x.rar. Admittedly I didn't dig too deeply. I have some time today to look at it further.
>>> Robbie
> Ah, ok, now I remember. The issue seems to be that the in the jca build.xml file, the module is listed as:
>
> <property name="module.name" value="ra"/>
>
> While the directory itself is named jca. This was causing issues because the jca project needed ra.libs to build, but the tests didn't know what to do with ra.libs because there is no directory by that name. Unfortunately, it was at a point where we couldn't change things as people had already started to depend on the RAR being named qpid-ra-<version>.rar.
>
> Probably time to revisit this.
In looking closer, I believe I can change the module.name to jca (which it should be) and just use this to generate the RAR name:
<property name="module.rar" value="${build.lib}/${project.name}-ra-${project.version}.rar"/>
This actually makes a lot more sense as JCA should be the module, while the artifact, the resource adapter can still be appropriately named.
Regards,
Weston
>
> Weston
>>>
>>
>> Thanks again.
>>
>> Regards,
>>
>> Weston
>>> On 4 May 2012 15:41, Weston M. Price <wp...@redhat.com> wrote:
>>>> In the JCA example code, we have a dependency on the Servlet API. Currently we include a few JEE jars from Geronimo (ejb, jca etc). I would like the include the geronimo-servlet-spec jar as well. Is it as simple as taking a copy of the jar and putting it in the java/lib directory or is there something more to it?
>>>>
>>>> Regards,
>>>>
>>>> Weston
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Project Dependencies
Posted by "Weston M. Price" <wp...@redhat.com>.
On May 4, 2012, at 12:23 PM, Weston M. Price wrote:
>
> On May 4, 2012, at 11:39 AM, Robbie Gemmell wrote:
>
>> You would also need to add an entry to the build.deps file for the new
>> jar, and update the existing entry for the ra module in build.deps to
>> say it depends on it.
> Yep, this I knew, but the question was primarily around where to get/access the jar. Sounds like it's a manual process versus automated.
>>
>> This also reminds me to bring up something. There is a hack in the
>> build.deps file for the adapter with a comment saying it has to
>> duplicate some definitions because the systests module is looking for
>> jca instead of ra. It wasnt clear to be why the systests module had
>> been configured to depend on something that doesnt actually exist in
>> the first place?
>>
> From what I remember, when I was setting this up this was a naming thing when one project was looking for 'ra' but the jca project itself needed 'jca'. I remember changing the name and for some reason the artifacts that were generated suddenly were named qpid-jca-0.x.rar versus qpid-ra-0.x.rar. Admittedly I didn't dig too deeply. I have some time today to look at it further.
>> Robbie
Ah, ok, now I remember. The issue seems to be that the in the jca build.xml file, the module is listed as:
<property name="module.name" value="ra"/>
While the directory itself is named jca. This was causing issues because the jca project needed ra.libs to build, but the tests didn't know what to do with ra.libs because there is no directory by that name. Unfortunately, it was at a point where we couldn't change things as people had already started to depend on the RAR being named qpid-ra-<version>.rar.
Probably time to revisit this.
Weston
>>
>
> Thanks again.
>
> Regards,
>
> Weston
>> On 4 May 2012 15:41, Weston M. Price <wp...@redhat.com> wrote:
>>> In the JCA example code, we have a dependency on the Servlet API. Currently we include a few JEE jars from Geronimo (ejb, jca etc). I would like the include the geronimo-servlet-spec jar as well. Is it as simple as taking a copy of the jar and putting it in the java/lib directory or is there something more to it?
>>>
>>> Regards,
>>>
>>> Weston
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Project Dependencies
Posted by "Weston M. Price" <wp...@redhat.com>.
On May 4, 2012, at 11:39 AM, Robbie Gemmell wrote:
> You would also need to add an entry to the build.deps file for the new
> jar, and update the existing entry for the ra module in build.deps to
> say it depends on it.
Yep, this I knew, but the question was primarily around where to get/access the jar. Sounds like it's a manual process versus automated.
>
> This also reminds me to bring up something. There is a hack in the
> build.deps file for the adapter with a comment saying it has to
> duplicate some definitions because the systests module is looking for
> jca instead of ra. It wasnt clear to be why the systests module had
> been configured to depend on something that doesnt actually exist in
> the first place?
>
From what I remember, when I was setting this up this was a naming thing when one project was looking for 'ra' but the jca project itself needed 'jca'. I remember changing the name and for some reason the artifacts that were generated suddenly were named qpid-jca-0.x.rar versus qpid-ra-0.x.rar. Admittedly I didn't dig too deeply. I have some time today to look at it further.
> Robbie
>
Thanks again.
Regards,
Weston
> On 4 May 2012 15:41, Weston M. Price <wp...@redhat.com> wrote:
>> In the JCA example code, we have a dependency on the Servlet API. Currently we include a few JEE jars from Geronimo (ejb, jca etc). I would like the include the geronimo-servlet-spec jar as well. Is it as simple as taking a copy of the jar and putting it in the java/lib directory or is there something more to it?
>>
>> Regards,
>>
>> Weston
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Project Dependencies
Posted by Robbie Gemmell <ro...@gmail.com>.
You would also need to add an entry to the build.deps file for the new
jar, and update the existing entry for the ra module in build.deps to
say it depends on it.
This also reminds me to bring up something. There is a hack in the
build.deps file for the adapter with a comment saying it has to
duplicate some definitions because the systests module is looking for
jca instead of ra. It wasnt clear to be why the systests module had
been configured to depend on something that doesnt actually exist in
the first place?
Robbie
On 4 May 2012 15:41, Weston M. Price <wp...@redhat.com> wrote:
> In the JCA example code, we have a dependency on the Servlet API. Currently we include a few JEE jars from Geronimo (ejb, jca etc). I would like the include the geronimo-servlet-spec jar as well. Is it as simple as taking a copy of the jar and putting it in the java/lib directory or is there something more to it?
>
> Regards,
>
> Weston
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org