You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Sam Ruby <ru...@us.ibm.com> on 2001/04/03 05:26:25 UTC
Re: ECS Usage Survey
Raphaël Luta wrote:
>
> I've updated Jetspeed CVS to work with the latest TDK. Remember that we
> follow TDK releases not Turbine CVS HEAD...
Thank you!
Question: if the difference between HEAD and the latest TDK is the addition
of a few new methods to an interface that you implement, would there be any
harm in implementing these new methods in advance?
I haven't looked to see if it is possible in this case. But on the off
chance that it is, just imagine: you can deliver the next release of
Jetspeed independent of the release cycles of Turbine, and yet leave open
the possibility that when the next release of Turbine happens. If all goes
well (and Turbine learns to deprecate properly!), your users can simply
drop in the jar for the next release of Turbine and be up and running...
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: ECS Usage Survey
Posted by Jason van Zyl <jv...@apache.org>.
Sean Legassick wrote:
>
> In message <3A...@apache.org>, Jason van Zyl
> <jv...@apache.org> writes
> >There is also a mechanism whereby the user only edits the
> >project.properties
> >and the values present there are inserted into the TR.props. What
> >should be added is the ability to repeatedly make changes to the
> >project.properties and have those changes reflected in the TR.props.
> >Right now it only works on the first pass during the init target.
>
> Surely as simple as "./build-project.sh update-tr-props", n'est-ce pas?!
>
> However right now this is only covering simple DB properties. I guess
> what I should have suggested is that the range of TR.props properties
> configurable via the project.properties file could be extended greatly,
> meaning that when I update the turbine jar to the latest version, rather
> than dropping in a new fresh TR.props and customizing it again, I could
> just rerun the update-tr-props ant target.
Yes, it's just when the project.properties file changes :-) Like
when things are added to torque and what not. The project.properties
and the TR.props is a major configuration management issue and is
something I'm thinking about a lot because I admit it can be a total
PITA to upgrade.
I think we need some form of migrator that can be used on sources
and on configuration files. Again, the family of regexes and/or
rules that can be applied to sources over N generations. Something
that would transform properties that have changed and add new entries.
This is where an XML configuration might be great because we could have
a set of stylesheets that could transform the TR.props from one
generation
to the next. I'm totally up for a discussion because it is a real
problem for developers. Even when we stablize, small changes in
configuration
can still be a problem and having a tool would be ideal. An incredible
amount
of work, as managing configuration issues always is because it's
tedious,
but could be a real boon.
>
> --
> Sean Legassick
> sean@informage.net
> Jeg er mann: Ingenting menneskelig er fremmed for meg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: ECS Usage Survey
Posted by Sean Legassick <se...@informage.net>.
In message <3A...@apache.org>, Jason van Zyl
<jv...@apache.org> writes
>There is also a mechanism whereby the user only edits the
>project.properties
>and the values present there are inserted into the TR.props. What
>should be added is the ability to repeatedly make changes to the
>project.properties and have those changes reflected in the TR.props.
>Right now it only works on the first pass during the init target.
Surely as simple as "./build-project.sh update-tr-props", n'est-ce pas?!
However right now this is only covering simple DB properties. I guess
what I should have suggested is that the range of TR.props properties
configurable via the project.properties file could be extended greatly,
meaning that when I update the turbine jar to the latest version, rather
than dropping in a new fresh TR.props and customizing it again, I could
just rerun the update-tr-props ant target.
--
Sean Legassick
sean@informage.net
Jeg er mann: Ingenting menneskelig er fremmed for meg
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: ECS Usage Survey
Posted by Jason van Zyl <jv...@apache.org>.
Sean Legassick wrote:
>
> In message <B6...@latchkey.com>, Jon Stevens
> <jo...@latchkey.com> writes
> >All in all, I really don't think that updating the file is that big of a
> >deal. It takes 10-15 minutes at most.
>
> Sure, but something automatic would be even easier :).
>
> What I've been thinking about is the possibility of integrating the
> TR.props build mechanism into the TDK, so that rather than editing
> TR.props you edit a meta-properties file like the ones in conf/view.
There is a TR.props mechanism in the TDK. The TR.props in the TDK
are automatically kept in sync with the TR.props in Turbine's CVS
with the little TR.props builder.
There is also a mechanism whereby the user only edits the
project.properties
and the values present there are inserted into the TR.props. What
should be added is the ability to repeatedly make changes to the
project.properties and have those changes reflected in the TR.props.
Right now it only works on the first pass during the init target.
>
> However this would only work where the user only wishes to customise
> properties that have their values replaced by @XXX@ macros. For more
> intricate customisations the TR.props would have to be hand
> maintained...
>
> --
> Sean Legassick
> sean@informage.net
> As a person, nothing human can be alien to me
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: ECS Usage Survey
Posted by Sean Legassick <se...@informage.net>.
In message <B6...@latchkey.com>, Jon Stevens
<jo...@latchkey.com> writes
>All in all, I really don't think that updating the file is that big of a
>deal. It takes 10-15 minutes at most.
Sure, but something automatic would be even easier :).
What I've been thinking about is the possibility of integrating the
TR.props build mechanism into the TDK, so that rather than editing
TR.props you edit a meta-properties file like the ones in conf/view.
However this would only work where the user only wishes to customise
properties that have their values replaced by @XXX@ macros. For more
intricate customisations the TR.props would have to be hand
maintained...
--
Sean Legassick
sean@informage.net
As a person, nothing human can be alien to me
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: ECS Usage Survey
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/3/01 10:45 AM, "Dan Diephouse" <di...@compassarts.org> wrote:
> Just an idea here on how it could be possible to cope with a constantly
> updating
> TR.p. In FreeBSD there is a /etc/defaults directory which holds a file called
> rc.conf. This file contains all the default configuration values...Then in
> the
> /etc directory there is a rc.conf file which overides properties in the
> /etc/defaults directory. Turbine could possibly do something like this.
> There
> could be a TurbineResources.defaults and TurbineResources.properites. Then
> people
> aren't cut and pasting so much from version to version... Of course there
> will
> still be a bit of work involved in large revisions and other problems, but its
> just
> an idea :) Comments?
>
> Dan Diephouse
The problem is that with the current Configuration scheme, you can't
override variables easily:
ie:
foo.bar=mojo
foo.bar=nixon
== foo.bar=mojo,nixon
All in all, I really don't think that updating the file is that big of a
deal. It takes 10-15 minutes at most.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: ECS Usage Survey
Posted by Dan Diephouse <di...@compassarts.org>.
Just an idea here on how it could be possible to cope with a constantly updating
TR.p. In FreeBSD there is a /etc/defaults directory which holds a file called
rc.conf. This file contains all the default configuration values...Then in the
/etc directory there is a rc.conf file which overides properties in the
/etc/defaults directory. Turbine could possibly do something like this. There
could be a TurbineResources.defaults and TurbineResources.properites. Then people
aren't cut and pasting so much from version to version... Of course there will
still be a bit of work involved in large revisions and other problems, but its just
an idea :) Comments?
Dan Diephouse
Raphaël Luta wrote:
> Sam Ruby wrote:
> >
> > Raphaël Luta wrote:
> > >
> > > I've updated Jetspeed CVS to work with the latest TDK. Remember that we
> > > follow TDK releases not Turbine CVS HEAD...
> >
> > Thank you!
> >
> > Question: if the difference between HEAD and the latest TDK is the addition
> > of a few new methods to an interface that you implement, would there be any
> > harm in implementing these new methods in advance?
> >
> > I haven't looked to see if it is possible in this case. But on the off
> > chance that it is, just imagine: you can deliver the next release of
> > Jetspeed independent of the release cycles of Turbine, and yet leave open
> > the possibility that when the next release of Turbine happens. If all goes
> > well (and Turbine learns to deprecate properly!), your users can simply
> > drop in the jar for the next release of Turbine and be up and running...
> >
>
> I'd love to but right now the main issues is *not* updating the code to add new
> methods but updating the TR.p file whenever there's a new feature in Turbine :
> the way Turbine configuration works right now, each time we update Turbine
> dependency, I need to manually compare the TR.p in Turbine and the latest TR.p
> in Jetspeed and update the new keys and values while still preserving Jetspeed
> specific properties.
> If there was a way to simply drop in a new standard TR.p file whenever we update
> and keep all Jetspeed specific keys in a separate file the update process would
> be way easier.
>
> Unfortunately, GUMP doesn't help for tracking incompatible TR.p changes...
>
> --
> Raphaël Luta - raphael.luta@networks.groupvu.com
> Vivendi Universal Networks - Services Manager / Paris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: ECS Usage Survey
Posted by Raphaël Luta <ra...@networks.groupvu.com>.
Sam Ruby wrote:
>
> Raphaël Luta wrote:
> >
> > I've updated Jetspeed CVS to work with the latest TDK. Remember that we
> > follow TDK releases not Turbine CVS HEAD...
>
> Thank you!
>
> Question: if the difference between HEAD and the latest TDK is the addition
> of a few new methods to an interface that you implement, would there be any
> harm in implementing these new methods in advance?
>
> I haven't looked to see if it is possible in this case. But on the off
> chance that it is, just imagine: you can deliver the next release of
> Jetspeed independent of the release cycles of Turbine, and yet leave open
> the possibility that when the next release of Turbine happens. If all goes
> well (and Turbine learns to deprecate properly!), your users can simply
> drop in the jar for the next release of Turbine and be up and running...
>
I'd love to but right now the main issues is *not* updating the code to add new
methods but updating the TR.p file whenever there's a new feature in Turbine :
the way Turbine configuration works right now, each time we update Turbine
dependency, I need to manually compare the TR.p in Turbine and the latest TR.p
in Jetspeed and update the new keys and values while still preserving Jetspeed
specific properties.
If there was a way to simply drop in a new standard TR.p file whenever we update
and keep all Jetspeed specific keys in a separate file the update process would
be way easier.
Unfortunately, GUMP doesn't help for tracking incompatible TR.p changes...
--
Raphaël Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Services Manager / Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org