You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/06/25 16:09:44 UTC
removing fortress deps
I have just updated the Excalibur Datasource build.xml and the
corresponding Gump descriptor to remove fortress deps. The updates
remove the fortress dependency that has been breaking the gump build for
the last week.
http://marc.theaimsgroup.com/?t=101947957300001&r=1&w=2
The result of this change is that the fortress auto-meta generation will
not run which may break other things. If someone can put together a
static version of the meta generated content that Fortress needs, commit
this and adjust the build.xml as required, then everything should be
hunky-dory.
If gump generates datasource without problem, we can apply the same
changes to excalibur-store and excalibur-monitor.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: removing fortress deps
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> I think this is a bad idea. Gump needs to be fixed to be able to do
> the same thing as a developer does when building; we should not remove
> automation because of build setup.
Guess what - I agree with you!
But we should also avoid breaking other gump runs due to a container
specific dependency.
> FWIW, me and berin have been looking into this.
That's good to know - I had not seen any actions (cvs comits or posts to
the list) and there were no suggests or comments raised when I posted
the issue to the list back on the 22nd. The datasource failure
(Fortress Vertex class stuff) has been occuring since the 17th and as a
result the avalon-corenerstone gump process has not run even once
against the updated structure.
> The problem at the moment is that we have
>
> <ant><depend project="avalon-fortress-tools property="blah"
> inherit="runtime"/></ant>
>
> but the 'inherit="runtime"' is ignored when you specify a dependency
> inside the <ant/> tag. One can either put the <depend/> tag outside
> the <ant/> tag or modify the gump code to provide support.
>
> Either is, imho, a better idea than committing descriptors to cvs. I
> can see lots of difficult-to-trace build errors arriving in the future
> because of this.
Whatever the solution - I think it is a bad thing to introduce container
depedencies into the build of what should be a container independent
resource. I am not saying that the auto generation is a bad thing, I
just saying that the generation of the jar file (independenty of
Fortress) takes priority. Can these concerns be seperated out somwhow -
e.g. a build that generates the artifact, and another build (and
corresponding gump descriptor) that adds supplimentary container
specific information?
Steve.
>
>
> cheers,
>
>
> - Leo
>
> Stephen McConnell wrote:
>
>> I have just updated the Excalibur Datasource build.xml and the
>> corresponding Gump descriptor to remove fortress deps. The updates
>> remove the fortress dependency that has been breaking the gump build
>> for the last week.
>> http://marc.theaimsgroup.com/?t=101947957300001&r=1&w=2
>>
>> The result of this change is that the fortress auto-meta generation
>> will not run which may break other things. If someone can put
>> together a static version of the meta generated content that Fortress
>> needs, commit this and adjust the build.xml as required, then
>> everything should be hunky-dory.
>>
>> If gump generates datasource without problem, we can apply the same
>> changes to excalibur-store and excalibur-monitor.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: removing fortress deps
Posted by Leo Simons <le...@apache.org>.
I think this is a bad idea. Gump needs to be fixed to be able to do the
same thing as a developer does when building; we should not remove
automation because of build setup. FWIW, me and berin have been looking
into this. The problem at the moment is that we have
<ant><depend project="avalon-fortress-tools property="blah"
inherit="runtime"/></ant>
but the 'inherit="runtime"' is ignored when you specify a dependency
inside the <ant/> tag. One can either put the <depend/> tag outside the
<ant/> tag or modify the gump code to provide support.
Either is, imho, a better idea than committing descriptors to cvs. I can
see lots of difficult-to-trace build errors arriving in the future
because of this.
cheers,
- Leo
Stephen McConnell wrote:
> I have just updated the Excalibur Datasource build.xml and the
> corresponding Gump descriptor to remove fortress deps. The updates
> remove the fortress dependency that has been breaking the gump build for
> the last week.
> http://marc.theaimsgroup.com/?t=101947957300001&r=1&w=2
>
> The result of this change is that the fortress auto-meta generation will
> not run which may break other things. If someone can put together a
> static version of the meta generated content that Fortress needs, commit
> this and adjust the build.xml as required, then everything should be
> hunky-dory.
>
> If gump generates datasource without problem, we can apply the same
> changes to excalibur-store and excalibur-monitor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org