You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/03/14 19:20:23 UTC
[GUMP] Good news and bad
First the good news:
Avalon is no longer the problem preventing GUMP builds. As Avalon has
been going through its growing pains in its infancy, we have been taking
some serious strides toward stability and simplifying our code base.
As part of that effort, we are releasing all the Avalon components so
that all releases from this year forward (including LogKit 1.2,
Framework 4.1.4 which were released earlier this year) will be
guaranteed to interroperate. We also took strides to make sure we
have compatibility and make sure that GUMP does not fail as a result
of our activities.
It has been painful, but I think we are better for it.
Now, the bad news:
Cocoon still does not compile with GUMP. Currently the problem is with
FOP.
Now, more good news:
On March 18, 2003 Avalon will be releasing a new set of Excalibur
components (as part of our continuing effort stated above). You will
have a new version of ECM and its dependencies. ECM now has a
"big jar" option which merges ECM's Avalon dependencies into one
JAR file. This will be part of the release. As a result, you can
get rid of a few jars in CVS and replace it with one.
After that, we will be releasing a "Compatibility" jar which is
for the sole expressed purpose of providing binary compatibility
with code that has been using us for a while. This compatibility
JAR will again allow you to replace a few CVS jars for that one.
There are no Avalon dependencies on the classes in that JAR--although
there might be some Cocoon dependencies.
Avalon is getting out of the business of maintaining utility jars,
and focusing on components, containers, and the contracts (framework)
between them. As we remove these libraries from the officially
supported list of Avalon subprojects they will be moved into the
compatibility JAR and a replacement will be available.
I will keep you posted as more details unfold.
Re: Gump and CocoonDev
Posted by Steven Noels <st...@outerthought.org>.
On 17/03/2003 14:06 Sam Ruby wrote:
> I still don't think I am communicating. Let me try a specific example:
Yep, we weren't.
> bruno is in cocoondev, but his primary group is ot. If he were to
> create files in /usr/serverlocal/gump, by default, I couldn't change them.
Indeed.
> I'd like bruno's primary group to be cocoondev, or myself added to group
> ot. Or for bruno's primary group to be changed to something that you
> would feel comfortable adding me to.
... which, given the number of projects (-> groups) and possible
interrelations in-between means I would be better off putting all users
in one group (i.e. cocoondev).
On icarus/daedalus, each user has its own group as a primary group. I
assume the problem lives there, too, and that they solved this using
sticky bits?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Gump and CocoonDev
Posted by Sam Ruby <ru...@apache.org>.
Steven Noels wrote:
> Sam Ruby wrote:
>
>> *If* there are people who might be predisposed to make changes to
>> /usr/serverlocal/gump, *then* I would like to be included as a member
>> of whatever group they might have as their primary group.
>
> Ah. I'm pretty sure now we _do_ understand each other. :-)
>
> cocoondev is the group for serverwide, general stuff - I consider our
> Gump installation to be such a precious thing.
I still don't think I am communicating. Let me try a specific example:
bruno is in cocoondev, but his primary group is ot. If he were to
create files in /usr/serverlocal/gump, by default, I couldn't change them.
I'd like bruno's primary group to be cocoondev, or myself added to group
ot. Or for bruno's primary group to be changed to something that you
would feel comfortable adding me to.
> </Steven>
- Sam Ruby
Re: Gump and CocoonDev
Posted by Steven Noels <st...@outerthought.org>.
Sam Ruby wrote:
> *If* there are people who might be predisposed to make changes to
> /usr/serverlocal/gump, *then* I would like to be included as a member of
> whatever group they might have as their primary group.
Ah. I'm pretty sure now we _do_ understand each other. :-)
cocoondev is the group for serverwide, general stuff - I consider our
Gump installation to be such a precious thing.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Gump and CocoonDev
Posted by Sam Ruby <ru...@apache.org>.
Steven Noels wrote:
> Sam Ruby wrote:
>
>> What this requires is that whatever id is used to execute the nightly
>> builds has ability to update any files that people might produce.
>> Umask 002 is an important part of ths - and making sure that I (or
>> whoever is running the nightly build) am in the all the primary groups
>> of everybody who might create files in this directory is another.
>
> 002 is being tackled ATM, and can be taken care of locally if people
> can't wait.
>
> That primary group thing... I assume that will eventually work out. I
> made cocoondev the primary group for a number of people. Part of the
> containment/isolation between projects however is based on the one
> group/project thing, and since some people are bound to work on multiple
> projects, they belong to multiple groups.
Let me restate what I am asking for, more clearly this time.
*If* there are people who might be predisposed to make changes to
/usr/serverlocal/gump, *then* I would like to be included as a member of
whatever group they might have as their primary group.
If this is not done, then the quality of nightly builds will deteriorate
over time and inevitably will result in one or more people spending
significant time debugging non-problems.
At the moment, this is not a problem as I am the only one playing. I'm
just trying to think ahead.
> </Steven>
- Sam Ruby
P.S. I committed a change which will get Ant and Xerces Jars to be
included in the builds of the various blocks. There appears to be other
problems with the build.xml. Tonight's run will show the issues.
I did not add the various <nag> elements.
Re: Gump and CocoonDev
Posted by Steven Noels <st...@outerthought.org>.
Sam Ruby wrote:
> What this requires is that whatever id is used to execute the nightly
> builds has ability to update any files that people might produce. Umask
> 002 is an important part of ths - and making sure that I (or whoever is
> running the nightly build) am in the all the primary groups of everybody
> who might create files in this directory is another.
002 is being tackled ATM, and can be taken care of locally if people
can't wait.
That primary group thing... I assume that will eventually work out. I
made cocoondev the primary group for a number of people. Part of the
containment/isolation between projects however is based on the one
group/project thing, and since some people are bound to work on multiple
projects, they belong to multiple groups.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Gump and CocoonDev
Posted by Sam Ruby <ru...@apache.org>.
Steven Noels wrote:
> Sam Ruby wrote:
>
>> Ultimately, we'll have to discuss what groups people are assigned to
>> and whether or not /etc/bashrc should be modified so that umask is set
>> to 002 for everybody. What we need to ensure is that there is no
>> problem with permissions of files that people create.
>
> umask isn't automatically set to 002 - I'll see this eventually gets
> changed (I've been suggesting to people to change it in
> ~/.bash_profile). All 'system-wide capable' people are in the cocoondev
> group, there are some other people who are only in project-specific groups.
>
> If other cocoondev.org account owners want to be in the cocoondev group
> to help Sam out, please indicate so. Currently, there's Jeff, Bruno and
> Marc, Ovidiu, Sylvain, Tom Klaasen, Sam, and myself. I just added David,
> too.
At the present time, the various cocoon blocks have gone from yellow
(prereq failed) to red (build failed). These are now unblocked because
the core build of cocoon now successfully produces a jar. Yea! They
fail because these project definitions don't include a dependency on Ant
(or Xerces for that matter). These project definitions also don't
contain nag entries.
If somebody wants to make a change and test it out on cocoondev, simply
update cocoon-2.1/gump.xml and issue the following two commands on
cocoondev.org:
build gump scripts
build cocoon-block-html
You will find 'build' and a few other useful scripts and utilities in
/usr/serverlocal/gump/bin. Add this to your PATH.
Since the project definitions for cocoon's core and blocks are not in
gump's cvs but are defined to be retrieved from cocoon's cvs, an extra
step is required: namely to commit these changes before building.
> Since quite a few people are in multiple groups, and cocoondev isn't
> necesseraly their primary group, so some chgrp might be needed when you
> create new files.
Making people take extra actions to 'do the right thing' invites problems.
Let me describe how I would like to encourage this shared resource being
used. I gave an example above: make a change and try it out. Build one
project then build another that depends on it. No need to worry about
classpaths or copying jars - all that is taken care of for you.
Whatever change you make is immediately effective.
Make a change any way you like - for example, directly edit the files
using your favorite editor, or simply do cvs update commands. Being
able to do a cvs update with a "-D date" option is particuarly powerful
- you can roll back changes made to projects you depend on and rebuild
first that project and then cocoon. With a simple binary search over
dates, you can isolate and identify the precise change that broke you.
If you are so inclined, make a fix, verify that it works, and send a
patch to the owners.
Don't worry too much about how you leave things. Every night (currently
at midnight CET), the cocoondev will update to the latest from cvs and
these directories will be restored via efficient 'rsync' commands and
rebuilt. In fact, if you mess things up too much, simply rm -rf the
project directory and do a build - the contents will automatically be
restored to the last cvs checkout.
What this requires is that whatever id is used to execute the nightly
builds has ability to update any files that people might produce. Umask
002 is an important part of ths - and making sure that I (or whoever is
running the nightly build) am in the all the primary groups of everybody
who might create files in this directory is another.
I'm still tweaking and improving, but don't be shy. Go forth and play.
> Document root is /www/gump.cocoondev.org/webapps/ROOT which is owned by
> rubys, group cocoondev
>
> </Steven>
Re: Gump and CocoonDev
Posted by Steven Noels <st...@outerthought.org>.
Sam Ruby wrote:
> Ultimately, we'll have to discuss what groups people are assigned to and
> whether or not /etc/bashrc should be modified so that umask is set to
> 002 for everybody. What we need to ensure is that there is no problem
> with permissions of files that people create.
umask isn't automatically set to 002 - I'll see this eventually gets
changed (I've been suggesting to people to change it in
~/.bash_profile). All 'system-wide capable' people are in the cocoondev
group, there are some other people who are only in project-specific groups.
If other cocoondev.org account owners want to be in the cocoondev group
to help Sam out, please indicate so. Currently, there's Jeff, Bruno and
Marc, Ovidiu, Sylvain, Tom Klaasen, Sam, and myself. I just added David,
too.
Since quite a few people are in multiple groups, and cocoondev isn't
necesseraly their primary group, so some chgrp might be needed when you
create new files.
Document root is /www/gump.cocoondev.org/webapps/ROOT which is owned by
rubys, group cocoondev
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Gump and CocoonDev
Posted by Sam Ruby <ru...@apache.org>.
Steven Noels wrote:
>
>> Once this is accomplished, I'll look into two things: publishing the
>> results and moving the data to a location where everybody with the
>> ability to log onto cocoondev can do updates and builds of any and all
>> individual projects in between nightly runs. I fully expect people
>> will find this ability to be very addictive and helpful in isolating
>> and resolving inter component issues.
>
> We need to discuss this, as I don't fully understand what that would
> involve. In any case, I start to think this should be set up as a shared
> resource. We use /usr/serverlocal for that, you'll see Jeff & I left
> there some shared apps already. The document root for the visible
> website is currently /www/gump.cocoondev.org/webapps/ROOT.
Mostly, letting me know into what directory you would like the share
resource to be placed, and what the document root for the visible
website is. ;-)
Ultimately, we'll have to discuss what groups people are assigned to and
whether or not /etc/bashrc should be modified so that umask is set to
002 for everybody. What we need to ensure is that there is no problem
with permissions of files that people create.
I'll keep everybody posted if I need anything else.
- Sam Ruby
Re: Gump and CocoonDev
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 15/3/03 16:31, "Steven Noels" <st...@outerthought.org> wrote:
>> Before I do a full build, I would like to note a few things and ask a
>> few questions. Execution of a number of builds involve testing. Some
>> builds require Xvfb in order to work. I notice that there is an
>> instance of this process currently running: can I depend on that? What
>
> You should be able to depend on that, yes. Other processes do, too. Mine
> is set to DISPLAY=:0.0
If you're running JDK 1.4, you can run a headless AWT:
http://java.sun.com/j2se/1.4/docs/guide/awt/AWTChanges.html#headless
You won't need to rely on a virtual X server for drawing off-screen images.
Pier
Re: Gump and CocoonDev
Posted by Steven Noels <st...@outerthought.org>.
Sam Ruby wrote:
> I've prep'ed cocoondev.org, and am nearly ready to try a full build.
> Preping involved installing the necessary packages [1], tailoring some
> of the paths in nagoya.xml to produce cocoondev.xml, and determining the
> appropriate value for JAVA_HOME. I've done some limited testing,
> including running gen, update all, and individual builds of
> bootstrap-ant and ant.
Glad to hear that went well already.
> Before I do a full build, I would like to note a few things and ask a
> few questions. Execution of a number of builds involve testing. Some
> builds require Xvfb in order to work. I notice that there is an
> instance of this process currently running: can I depend on that? What
You should be able to depend on that, yes. Other processes do, too. Mine
is set to DISPLAY=:0.0
> should I set DISPLAY to? Also a number of tests involve attempts to
> create test web servers. Inevitably, this involves port 8080 which I
> note is currently in use. This may be a problem. Suggestions?
Ha. You should coordinate with Jeff. As far as I can see, the port is
not in use ATM but people can grab as they like, and Jeff habitually
runs Jetty from his homedir to test things.
> In order to minimize impact to others, builds will be run only once a
> day, and will utilize the "nice" command to allow all other processes to
> have priority. Builds will be run during the late night hours in most
> European locations - the first portion of which will be mostly cvs
> update and local rsync, neither of which are CPU or memory intensive
> operations. The builds themselves will be single threaded and run in a
> low priority as indicated above.
OK.
> Once this is accomplished, I'll look into two things: publishing the
> results and moving the data to a location where everybody with the
> ability to log onto cocoondev can do updates and builds of any and all
> individual projects in between nightly runs. I fully expect people will
> find this ability to be very addictive and helpful in isolating and
> resolving inter component issues.
We need to discuss this, as I don't fully understand what that would
involve. In any case, I start to think this should be set up as a shared
resource. We use /usr/serverlocal for that, you'll see Jeff & I left
there some shared apps already. The document root for the visible
website is currently /www/gump.cocoondev.org/webapps/ROOT.
> Finally, I'll look into establishing a cocoon profile which does not
> include everything that gump normally builds, but only contains those
> elements which are part of the greater cocoon ecosystem.
:-D
> Steven, let me know what you think and if this is the wrong mailing list
> to discuss these items.
Looking good so far. This list is fine, if other people are not bored
too much with it.
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Gump and CocoonDev
Posted by Sam Ruby <ru...@apache.org>.
OK, it looks like Cocoon's core well on its way to reliably compiling
every day with Gump. Lately Avalon has gotten a reappreciation of the
importance of backwards compatibility. This is very very good.
Progress towards compiling cocoon's blocks is held up due to the fact
that the indicated target, gump-core, does not in fact build a jar.
Looking into the build.xml, this appears to be due to an architectural
issue that is being worked. Once this issue is resolved, progress will
resume. The goal is clearly to get Forrest to build and run.
I've prep'ed cocoondev.org, and am nearly ready to try a full build.
Preping involved installing the necessary packages [1], tailoring some
of the paths in nagoya.xml to produce cocoondev.xml, and determining the
appropriate value for JAVA_HOME. I've done some limited testing,
including running gen, update all, and individual builds of
bootstrap-ant and ant.
Before I do a full build, I would like to note a few things and ask a
few questions. Execution of a number of builds involve testing. Some
builds require Xvfb in order to work. I notice that there is an
instance of this process currently running: can I depend on that? What
should I set DISPLAY to? Also a number of tests involve attempts to
create test web servers. Inevitably, this involves port 8080 which I
note is currently in use. This may be a problem. Suggestions?
In order to minimize impact to others, builds will be run only once a
day, and will utilize the "nice" command to allow all other processes to
have priority. Builds will be run during the late night hours in most
European locations - the first portion of which will be mostly cvs
update and local rsync, neither of which are CPU or memory intensive
operations. The builds themselves will be single threaded and run in a
low priority as indicated above.
Once this is accomplished, I'll look into two things: publishing the
results and moving the data to a location where everybody with the
ability to log onto cocoondev can do updates and builds of any and all
individual projects in between nightly runs. I fully expect people will
find this ability to be very addictive and helpful in isolating and
resolving inter component issues.
Finally, I'll look into establishing a cocoon profile which does not
include everything that gump normally builds, but only contains those
elements which are part of the greater cocoon ecosystem.
Steven, let me know what you think and if this is the wrong mailing list
to discuss these items.
- Sam Ruby
[1] http://cvs.apache.org/builds/gump/latest/packages.html
Re: [GUMP] Good news and bad
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>>> Now, more good news:
>>>
>>> On March 18, 2003 Avalon will be releasing a new set of Excalibur
>>> components (as part of our continuing effort stated above). You will
>>> have a new version of ECM and its dependencies. ECM now has a
>>> "big jar" option which merges ECM's Avalon dependencies into one
>>> JAR file. This will be part of the release. As a result, you can
>>> get rid of a few jars in CVS and replace it with one.
>>
>>
>>
>> Hmmm, this would force us to update the jar everytime a new release of
>> a component package is done. is this a good thing at the end?
>
>
> Only for the direct dependencies of ECM. These dependencies are:
>
> Logger, Instrument, Instrument-Manager, (AltRMI is in the big jar
> too), and Pool.
>
> Truth is that there won't be alot of major changes to those JARs.
>
> You have a choice. You can use the smaller jar that has *just*
> the ECM classes, and upgrade the other jars independently.
>
> Keep in mind that the big jar option is what Cocoon used in the
> past when Excalibur was one big project.
And that's the reason why we moved from single jar to many different
jars... but that was before those things were released.
anyway, I'm really +0 on such changes, I'll let more excalibur-wise
people choose what to do.
>> As long as you provide feedback on how to migrate, we'll be happy to
>> follow what is considered best practice.
>
>
> The first set of projects that are already in the draft compatibility
> JAR are: Concurrent, Collections, IO, and CLI.
>
> With the exception of Excalibur CLI, I believe that Cocoon does not
> have any dependencies on those libraries.
Then it would be kinda cool to remove all those dependencies right now
and forget about it so one less jar into the classpath.
> We want to point our users to Jakarta Commons CLI--which is just as
> capable. The end user will never know the difference with the change.
Cool.
Re: [GUMP] Good news and bad
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
>> First the good news:
>>
>> Avalon is no longer the problem preventing GUMP builds. As Avalon has
>> been going through its growing pains in its infancy, we have been taking
>> some serious strides toward stability and simplifying our code base.
>> As part of that effort, we are releasing all the Avalon components so
>> that all releases from this year forward (including LogKit 1.2,
>> Framework 4.1.4 which were released earlier this year) will be
>> guaranteed to interroperate. We also took strides to make sure we
>> have compatibility and make sure that GUMP does not fail as a result
>> of our activities.
>>
>> It has been painful, but I think we are better for it.
>
>
> Awesome!!! Thanks much for your work on this.
>
>> Now, the bad news:
>>
>> Cocoon still does not compile with GUMP. Currently the problem is with
>> FOP.
>
>
> Err, no. The 'fop-block' doesn't compile. Cocoon-core does. it's simply
> the gump target that is dependent on the 'block' target and it shouldn't
> be.
>
> I'm fixing this right away.
>
>>
>> Now, more good news:
>>
>> On March 18, 2003 Avalon will be releasing a new set of Excalibur
>> components (as part of our continuing effort stated above). You will
>> have a new version of ECM and its dependencies. ECM now has a
>> "big jar" option which merges ECM's Avalon dependencies into one
>> JAR file. This will be part of the release. As a result, you can
>> get rid of a few jars in CVS and replace it with one.
>
>
> Hmmm, this would force us to update the jar everytime a new release of a
> component package is done. is this a good thing at the end?
Only for the direct dependencies of ECM. These dependencies are:
Logger, Instrument, Instrument-Manager, (AltRMI is in the big jar
too), and Pool.
Truth is that there won't be alot of major changes to those JARs.
You have a choice. You can use the smaller jar that has *just*
the ECM classes, and upgrade the other jars independently.
Keep in mind that the big jar option is what Cocoon used in the
past when Excalibur was one big project.
>> After that, we will be releasing a "Compatibility" jar which is
>> for the sole expressed purpose of providing binary compatibility
>> with code that has been using us for a while. This compatibility
>> JAR will again allow you to replace a few CVS jars for that one.
>> There are no Avalon dependencies on the classes in that JAR--although
>> there might be some Cocoon dependencies.
>
> Removing that jar from classpath should be
....
I am assuming you are meaning to say "trivial"?
It would only be needed to maintain backwards binary compatibility
with users of Cocoon that may have used the contents of those utilities.
>> Avalon is getting out of the business of maintaining utility jars,
>> and focusing on components, containers, and the contracts (framework)
>> between them. As we remove these libraries from the officially
>> supported list of Avalon subprojects they will be moved into the
>> compatibility JAR and a replacement will be available.
>
>
> As long as you provide feedback on how to migrate, we'll be happy to
> follow what is considered best practice.
The first set of projects that are already in the draft compatibility
JAR are: Concurrent, Collections, IO, and CLI.
With the exception of Excalibur CLI, I believe that Cocoon does not
have any dependencies on those libraries.
We want to point our users to Jakarta Commons CLI--which is just as
capable. The end user will never know the difference with the change.
Re: [GUMP] Good news and bad
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> First the good news:
>
> Avalon is no longer the problem preventing GUMP builds. As Avalon has
> been going through its growing pains in its infancy, we have been taking
> some serious strides toward stability and simplifying our code base.
> As part of that effort, we are releasing all the Avalon components so
> that all releases from this year forward (including LogKit 1.2,
> Framework 4.1.4 which were released earlier this year) will be
> guaranteed to interroperate. We also took strides to make sure we
> have compatibility and make sure that GUMP does not fail as a result
> of our activities.
>
> It has been painful, but I think we are better for it.
Awesome!!! Thanks much for your work on this.
> Now, the bad news:
>
> Cocoon still does not compile with GUMP. Currently the problem is with
> FOP.
Err, no. The 'fop-block' doesn't compile. Cocoon-core does. it's simply
the gump target that is dependent on the 'block' target and it shouldn't be.
I'm fixing this right away.
>
> Now, more good news:
>
> On March 18, 2003 Avalon will be releasing a new set of Excalibur
> components (as part of our continuing effort stated above). You will
> have a new version of ECM and its dependencies. ECM now has a
> "big jar" option which merges ECM's Avalon dependencies into one
> JAR file. This will be part of the release. As a result, you can
> get rid of a few jars in CVS and replace it with one.
Hmmm, this would force us to update the jar everytime a new release of a
component package is done. is this a good thing at the end?
> After that, we will be releasing a "Compatibility" jar which is
> for the sole expressed purpose of providing binary compatibility
> with code that has been using us for a while. This compatibility
> JAR will again allow you to replace a few CVS jars for that one.
> There are no Avalon dependencies on the classes in that JAR--although
> there might be some Cocoon dependencies.
Removing that jar from classpath should be
> Avalon is getting out of the business of maintaining utility jars,
> and focusing on components, containers, and the contracts (framework)
> between them. As we remove these libraries from the officially
> supported list of Avalon subprojects they will be moved into the
> compatibility JAR and a replacement will be available.
As long as you provide feedback on how to migrate, we'll be happy to
follow what is considered best practice.
> I will keep you posted as more details unfold.
Thanks.