You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/11/20 19:41:45 UTC
Planning 2.2
Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
2.2 release we should at least finish the following things:
- Finish the maven2 build
- Sync everything with 2.1.x (apply changes that were only applied to
2.1.x if appropriate)
- Separate samples from blocks
- Remove author tags
While imho the first two items on the list are a simple must, I think we
should really do the other ones as well. If we don't aim to do them for
2.2 we'll simply never do them. And it's really not that hard to do it.
And finally, we should make a stable forms block (and perhaps others as
well).
WDYT
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Planning 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
Daniel Fagerstrom wrote:
>
> The question is if we are going to start to have separate release
> cycles of the blocks with 2.2. In that case the important part is a
> cocoon-core 2.2 release. Then we should preferably have releases of
> CForms, Template, Portal and some other important blocks that are
> compatible with the cocoon-core 2.2. But all blocks need not to have
> stable releases some of them can be milestone releases or even "alpha".
>
> IMO we should go for separate release cycles for 2.2. Then the we
> should release "2.2" when the core is stable enough, and consider
> whether the blocks are stable enough, a separate concern.
>
> /Daniel
I think we should follow the model maven has been taking with its
plugins. A core group of them are incorporated into every maven
release. You can upgrade them manually or install new ones but you
always have some set of them available in a normal install. This
amounts to nothing more than specifying dependencies on the latest
version at the time of release.
Ralph
Re: Planning 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 21 nov. 05, à 13:23, Jorg Heymans a écrit :
>> ...We could start this process incrementally today by just deploying
>> snapshots of the 2.2 core jar. No huge announcements or anything, just
>> get it out there for the bleeding-edgers and to test the release
>> process..
>
> Sounds like a good idea, I think several of us (like me) are
> unfamiliar with Maven-based distributions, so some kind of trial and
> error phase would be good.
+1 for the maven-based distro and the trial and error phase!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Planning 2.2
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 21 nov. 05, à 13:23, Jorg Heymans a écrit :
> ...We could start this process incrementally today by just deploying
> snapshots of the 2.2 core jar. No huge announcements or anything, just
> get it out there for the bleeding-edgers and to test the release
> process..
Sounds like a good idea, I think several of us (like me) are unfamiliar
with Maven-based distributions, so some kind of trial and error phase
would be good.
-Bertrand
Re: Planning 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Jorg Heymans wrote:
>
> +1, separate release cycles for more and quicker releases.
>
> We could start this process incrementally today by just deploying
> snapshots of the 2.2 core jar. No huge announcements or anything, just
> get it out there for the bleeding-edgers and to test the release
> process. Once we feel comfortable we can do the same for a few blocks.
> To avoid the deployment issue, we can opt to just distribute the jars
> and assume the bleeding-edgers being clever enough to add the block
> configuration themselves from the docs.
>
> In parallel we can maintain a core 2.2 archetype that sets up a working
> webapp structure for the 2.2 core (and perhaps some samples to
> demonstrate). This should satisfy the "curious-but-not-bleeding-edge"
> people in their eagerness to explore the new and noteworthy in 2.2 core.
>
>
> How does that sound?
>
+1
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Planning 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Jorg Heymans wrote:
>
> +1, separate release cycles for more and quicker releases.
>
> We could start this process incrementally today by just deploying
> snapshots of the 2.2 core jar. No huge announcements or anything, just
> get it out there for the bleeding-edgers and to test the release
> process. Once we feel comfortable we can do the same for a few blocks.
> To avoid the deployment issue, we can opt to just distribute the jars
> and assume the bleeding-edgers being clever enough to add the block
> configuration themselves from the docs.
>
> In parallel we can maintain a core 2.2 archetype that sets up a working
> webapp structure for the 2.2 core (and perhaps some samples to
> demonstrate). This should satisfy the "curious-but-not-bleeding-edge"
> people in their eagerness to explore the new and noteworthy in 2.2 core.
>
>
> How does that sound?
>
+1
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Planning 2.2
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jorg Heymans wrote:
>Daniel Fagerstrom wrote:
>
>
>>The question is if we are going to start to have separate release cycles
>>of the blocks with 2.2. In that case the important part is a cocoon-core
>>2.2 release. Then we should preferably have releases of CForms,
>>Template, Portal and some other important blocks that are compatible
>>with the cocoon-core 2.2. But all blocks need not to have stable
>>releases some of them can be milestone releases or even "alpha".
>>
>>IMO we should go for separate release cycles for 2.2. Then the we should
>>release "2.2" when the core is stable enough, and consider whether the
>>blocks are stable enough, a separate concern.
>>
>>
>+1, separate release cycles for more and quicker releases.
>
>We could start this process incrementally today by just deploying
>snapshots of the 2.2 core jar. No huge announcements or anything, just
>get it out there for the bleeding-edgers and to test the release
>process. Once we feel comfortable we can do the same for a few blocks.
>To avoid the deployment issue, we can opt to just distribute the jars
>and assume the bleeding-edgers being clever enough to add the block
>configuration themselves from the docs.
>
>In parallel we can maintain a core 2.2 archetype that sets up a working
>webapp structure for the 2.2 core (and perhaps some samples to
>demonstrate). This should satisfy the "curious-but-not-bleeding-edge"
>people in their eagerness to explore the new and noteworthy in 2.2 core.
>
>
>How does that sound?
>
>
It sounds great!
/Daniel
Re: Planning 2.2
Posted by Jorg Heymans <jh...@domek.be>.
Daniel Fagerstrom wrote:
>
> The question is if we are going to start to have separate release cycles
> of the blocks with 2.2. In that case the important part is a cocoon-core
> 2.2 release. Then we should preferably have releases of CForms,
> Template, Portal and some other important blocks that are compatible
> with the cocoon-core 2.2. But all blocks need not to have stable
> releases some of them can be milestone releases or even "alpha".
>
> IMO we should go for separate release cycles for 2.2. Then the we should
> release "2.2" when the core is stable enough, and consider whether the
> blocks are stable enough, a separate concern.
+1, separate release cycles for more and quicker releases.
We could start this process incrementally today by just deploying
snapshots of the 2.2 core jar. No huge announcements or anything, just
get it out there for the bleeding-edgers and to test the release
process. Once we feel comfortable we can do the same for a few blocks.
To avoid the deployment issue, we can opt to just distribute the jars
and assume the bleeding-edgers being clever enough to add the block
configuration themselves from the docs.
In parallel we can maintain a core 2.2 archetype that sets up a working
webapp structure for the 2.2 core (and perhaps some samples to
demonstrate). This should satisfy the "curious-but-not-bleeding-edge"
people in their eagerness to explore the new and noteworthy in 2.2 core.
How does that sound?
Jorg
Re: Planning 2.2
Posted by Jorg Heymans <jh...@domek.be>.
Daniel Fagerstrom wrote:
>
> Maybe we could have automatic daily snapshot releases, preferably to an
> m2 repository.
>
we sure can :-)
1. cron daily maven deployment to snapshot repository
2. declare a dependency like
<groupId>cocoon</groupId>
<artifactId>cocoon-core</artifactId>
<version>2.2-SNAPSHOT</version>
The snapshot bit is resolved to the latest timestamped snapshot in the
repository if available (eg cocoon-core-2.2-20051107.013155.jar ), or
just "SNAPSHOT" if we choose to overwrite snapshots upon deployment.
Additionally you can configure a snapshotrespository in settings.xml and
tell it to only update snapshots from this repository using a configured
frequency.
HTH
Jorg - who needs to get kicking on the maven stuff again
Re: Planning 2.2
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bertrand Delacretaz wrote:
> Le 21 nov. 05, à 10:54, Daniel Fagerstrom a écrit :
>
>> ...IMO we should go for separate release cycles for 2.2. Then the we
>> should release "2.2" when the core is stable enough, and consider
>> whether the blocks are stable enough, a separate concern...
>
>
> I'm all for this, but how would people get unreleased blocks if they
> want to use them?
>
> Would they have to grab them from SVN, or do you see a better way?
Maybe we could have automatic daily snapshot releases, preferably to an
m2 repository.
/Daniel
Re: Planning 2.2
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 21 nov. 05, à 10:54, Daniel Fagerstrom a écrit :
> ...IMO we should go for separate release cycles for 2.2. Then the we
> should release "2.2" when the core is stable enough, and consider
> whether the blocks are stable enough, a separate concern...
I'm all for this, but how would people get unreleased blocks if they
want to use them?
Would they have to grab them from SVN, or do you see a better way?
-Bertrand
Re: Planning 2.2
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
>Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
>2.2 release we should at least finish the following things:
>
>- Finish the maven2 build
>- Sync everything with 2.1.x (apply changes that were only applied to
>2.1.x if appropriate)
>- Separate samples from blocks
>- Remove author tags
>
>While imho the first two items on the list are a simple must, I think we
>should really do the other ones as well. If we don't aim to do them for
>2.2 we'll simply never do them. And it's really not that hard to do it.
>
>
+1
>And finally, we should make a stable forms block (and perhaps others as
>well).
>
>
Would be nice.
The question is if we are going to start to have separate release cycles
of the blocks with 2.2. In that case the important part is a cocoon-core
2.2 release. Then we should preferably have releases of CForms,
Template, Portal and some other important blocks that are compatible
with the cocoon-core 2.2. But all blocks need not to have stable
releases some of them can be milestone releases or even "alpha".
IMO we should go for separate release cycles for 2.2. Then the we should
release "2.2" when the core is stable enough, and consider whether the
blocks are stable enough, a separate concern.
/Daniel
Re: 2.2 Documentation
Posted by hepabolu <he...@gmail.com>.
Bruno Dumon wrote:
> Are you sure this is unnecessary? The current setup shares the same
> documents in the new docs and the legacy docs. Thus when the new docs
> are updated, refactored, retired etc, this influences the legacy docs
> too. This was fine as long as the legacy docs served exactly for this
> purpose, but now the legacy docs have turned into the official 2.1.8
> documentation. If we don't make a branch for 2.1.8, there's no way the
> 2.1.x docs can still be produced and maintained in the future.
Hmm. Currently there is so much "crap" (i.e. outdated documents or
documents describing ideas rather than real implementations) among the
documentation in the legacydocs collection, that I'm all for retiring
documents in that collection or slightly modifying the ones that are
still mostly valid.
That would improve the 2.1.8 documentation as well as the 2.2 documentation.
OTOH you're right that over time, the documentation of the 2.1 branche
would change too, which is unwanted.
My suggestion is a temporary solution, a kind of transition phase when
2.1.X is becoming "obsolete" and 2.2 is taking over. Once the
"official" 2.2 is released, we should create a branch to ensure that
2.1.X is "frozen". At that time, we might also decide that there will be
no more changes in the 2.1.X documentation at which point they will be
removed from Daisy entirely and the only copy resides in the SVN repository.
Bye, Helma
Re: 2.2 Documentation
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2005-11-23 at 12:58 +0100, hepabolu wrote:
> Regarding the documentation of 2.2:
>
> Let me first give you some Daisy background to clarify things, before I
> explain what I have in mind.
> Note that this is the quick & dirty explanation. The Outerthought boys
> can give a much more detailed overview.
>
> Daisy supports "sites" (the already mentioned Legacy docs and
> Documentation) and "collections". A collection is merely a set of
> documents and a site can be considered as a view on one or more
> collections. That's what is currently the case in our Daisy setup in the
> zones:
>
> Collection "legacydocs" contains all documentation as it was present in
> the xdocs of BRANCH_2.1.X. Collection "documentation" contains all new
> documents that are written in Daisy.
> Bruno has marked documents part of "legacydocs" with a two line red
> warning at the top of the document. You can see this when you open such
> a page in Daisy.
>
> There are already two sites in Daisy: Legacy docs and Documentation.
> Both use documents from both collections.
>
> My idea was this:
>
> I've used Legacy docs site to recreate the "old" cocoon.apache.org site
> as best as possible. If this is not enough, a little bit of work needs
> to be done.
> This site will be restricted to the 2.1 branch. Since Cocoon 2.1 is
> frozen when it comes to new features, I suggest that the documentation
> is only updated when some blatant errors or typos are found.
>
> For the 2.2 version please use the Documentation site. That's where new
> documentation is supposed to be entered. This site also contains links
> to all available documents in the legacydocs collection, see the last
> line in the navigation bar.
> This is added for convenience: if you find documentation in the
> legacydocs that is still valid for the 2.2 version, just move the
> documentation from the legacydocs collection to the documentation
> collection. This has no impact on the documentation in the Legacydocs site.
> I know it's possible that a document resides in both collections, but I
> want to end up with a collection of legacydocs that holds information
> that is either completely outdated or only valid for the 2.1 branch.
>
> I know we can make branches in Daisy, but at the moment I don't think
> this is necessary. I'd rather use that feature when we move from 2.2 to 3.0.
Are you sure this is unnecessary? The current setup shares the same
documents in the new docs and the legacy docs. Thus when the new docs
are updated, refactored, retired etc, this influences the legacy docs
too. This was fine as long as the legacy docs served exactly for this
purpose, but now the legacy docs have turned into the official 2.1.8
documentation. If we don't make a branch for 2.1.8, there's no way the
2.1.x docs can still be produced and maintained in the future.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: 2.2 Documentation
Posted by hepabolu <he...@gmail.com>.
Regarding the documentation of 2.2:
Let me first give you some Daisy background to clarify things, before I
explain what I have in mind.
Note that this is the quick & dirty explanation. The Outerthought boys
can give a much more detailed overview.
Daisy supports "sites" (the already mentioned Legacy docs and
Documentation) and "collections". A collection is merely a set of
documents and a site can be considered as a view on one or more
collections. That's what is currently the case in our Daisy setup in the
zones:
Collection "legacydocs" contains all documentation as it was present in
the xdocs of BRANCH_2.1.X. Collection "documentation" contains all new
documents that are written in Daisy.
Bruno has marked documents part of "legacydocs" with a two line red
warning at the top of the document. You can see this when you open such
a page in Daisy.
There are already two sites in Daisy: Legacy docs and Documentation.
Both use documents from both collections.
My idea was this:
I've used Legacy docs site to recreate the "old" cocoon.apache.org site
as best as possible. If this is not enough, a little bit of work needs
to be done.
This site will be restricted to the 2.1 branch. Since Cocoon 2.1 is
frozen when it comes to new features, I suggest that the documentation
is only updated when some blatant errors or typos are found.
For the 2.2 version please use the Documentation site. That's where new
documentation is supposed to be entered. This site also contains links
to all available documents in the legacydocs collection, see the last
line in the navigation bar.
This is added for convenience: if you find documentation in the
legacydocs that is still valid for the 2.2 version, just move the
documentation from the legacydocs collection to the documentation
collection. This has no impact on the documentation in the Legacydocs site.
I know it's possible that a document resides in both collections, but I
want to end up with a collection of legacydocs that holds information
that is either completely outdated or only valid for the 2.1 branch.
I know we can make branches in Daisy, but at the moment I don't think
this is necessary. I'd rather use that feature when we move from 2.2 to 3.0.
In summary:
- don't use the legacydocs site
- new documents, about new features of Cocoon 2.2, go into the
Documentation site. They are part of the documentation collection
(automatically if you have the Documentation site open) and they are of
type "Document" (not SimpleDocument).
- if the documentation you want to write is already present in the
legacydocs and is valid for both versions, move the document to the
"documentation" collection:
- select the document, select "edit" (you have to be logged in),
select the "Misc" tab and make sure the "selected" list contains only
"documentation".
- if the documentation you want to write is already present in the
legacydocs, but is not entirely correct:
- are the changes you want to add also valid for 2.1?
- yes: go ahead, change the document and move it from the
legacydocs to documentation.
- no: are the changes minor?
- yes: add one or more "notes" (paragraphs marked Note)
that explain the differences between 2.1 and 2.2 and move the document
from the legacydocs to documentation.
- no: create a new document in the documentation collection
and write the information as if the legacydocs document didn't exist.
- if you find documentation in the legacydocs that is outdated for both
2.1 and 2.2, then retire the document (Misc tab, under the Options section)
- if you find documentation in the wiki that is useful:
- copy the information to a Daisy document and finish this
- mark the wiki page with a message that the information is added to
the "official" Cocoon documentation.
- if there is information in the mailing lists that is useful:
- copy the information and elaborate it, turn it into a coherent
piece of information.
- if necessary, add the links to the relevant messages (each Daisy
document has a separate links section that ends up at the bottom of the
page). PLEASE DON'T SIMPLY REFER TO THE MAIL MESSAGES.
Most of this info is also written on the home page of the Cocoon
Documentation site in Daisy:
http://cocoon.zones.apache.org/daisy/documentation/659.html
If the above is clear, I'll update that page to reflect this information.
Bye, Helma
2.2 Documentation
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
was: Re: Planning 2.2
Ezkovich Glen wrote:
...
> I agree. But if you release today, then no one except those that have
> touched those things or followed the developer list will know what
> those features are much less how to use them.
A 2.2 M1 is for the benefit of the community and early adapters rather
than for a broad audience. It is for channeling community focus and
energy, which will cretate value for a broader audience after a while.
Neither the less we need to start a 2.2 Documentation effort:
> Point me in the right direction, give me a tentative release date and
> I will write up some documentation. Best offer I can give you today.
Thanks for the offer. Can't give you a tentative release date, but at
least some pointers:
We need a 2.2 branch of our documentation (maybe there allready is one?)
Documentation of (please everyone, provide relevant links to mail and
other documentation):
> - ECM++
> - Virtual sitemap components
(not particullary mature yet, but start with
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111316710610638&w=2 and
ask on the list)
> - blocks (sitemap blocks, exposing blocks)
Ongoing work, but the "sitemap aspect"
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111791016006393&w=2 is
based on a large amount of community driven design, so it might be
worthwhile to start documenting. The "component aspect", and the OSGi
part need more work and discussion.
> - per sitemap reloading classloader (for dev)
> - reworked property management
> - Spring integration (Spring block)
> - possible to listen to sitemap events
> - refactoring of Javaflow (uses now the commons-javaflow project which
> was started by Thorsten)
> - introduction of CTemplate (refactoring of JXTemplate in 2.1.x)
It should be completely back compatible with the original JXTG, but can
also be used in non flow environment. Leszek have added some features,
can you give links to relevant mails please.
--- o0o ---
I guess, collecting relevant links to mail and current documentation
snippets in the Wiki or in Daisy, would be a good first step.
WDYT?
/Daniel
Re: Planning 2.2
Posted by Ezkovich Glen <gl...@hard-bop.com>.
On Nov 22, 2005, at 5:12 PM, Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
>> Ezkovich Glen wrote:
>>> On Nov 22, 2005, at 1:18 AM, Reinhard Poetz wrote:
>>>
>>>> Glen Ezkovich wrote:
>
> ...
>
>>> This is what I thought. I was in effect questioning wether these
>>> new features are ready to go. My concern is the documentation
>>> for these new changes and features. An admittedly quick perusal
>>> of SVN didn't reveal much at all. Even a M1 release requires a
>>> bit of documentation so that the changes and new things get tested.
>> First it is an M1 so it is not like that everything have to be
>> completely finished and polished. Second it is a little bit of a
>> chicken and egg problem, as long as we don't start to release the
>> new features, they will feel like a moving target that not is
>> worthwhile to use and document yet.
Ahhhh, where software with market share differs from software without
and why cocoon's documentation needs so much work. Documentation is
an integral part of a release. It should be developed along side the
source code not months after the release.
>> And as long as no one use it and document it we who develop the
>> new stuff doesn't have any presure to stabilize it and stop
>> changing the interfaces.
>> By releasing an M1 we focus the community on 2.2 and hopefully
>> make the things you asking for, happen.
>> Also, while some of the above improvements still are experimental
>> (blocks, virtual sitemap components ...), much of it isn't. ECM++,
>> reloading classloader, refactored JXTemplate, ... really
>> simplifies use of Cocoon, so we should make it available for a
>> larger audience ASAP.
>
> Exactly.
I agree. But if you release today, then no one except those that have
touched those things or followed the developer list will know what
those features are much less how to use them.
Point me in the right direction, give me a tentative release date and
I will write up some documentation. Best offer I can give you today.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: Planning 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
> Ezkovich Glen wrote:
>
>> On Nov 22, 2005, at 1:18 AM, Reinhard Poetz wrote:
>>
>>> Glen Ezkovich wrote:
...
>> This is what I thought. I was in effect questioning wether these new
>> features are ready to go. My concern is the documentation for these
>> new changes and features. An admittedly quick perusal of SVN didn't
>> reveal much at all. Even a M1 release requires a bit of documentation
>> so that the changes and new things get tested.
>
> First it is an M1 so it is not like that everything have to be
> completely finished and polished. Second it is a little bit of a chicken
> and egg problem, as long as we don't start to release the new features,
> they will feel like a moving target that not is worthwhile to use and
> document yet. And as long as no one use it and document it we who
> develop the new stuff doesn't have any presure to stabilize it and stop
> changing the interfaces.
>
> By releasing an M1 we focus the community on 2.2 and hopefully make the
> things you asking for, happen.
>
> Also, while some of the above improvements still are experimental
> (blocks, virtual sitemap components ...), much of it isn't. ECM++,
> reloading classloader, refactored JXTemplate, ... really simplifies use
> of Cocoon, so we should make it available for a larger audience ASAP.
Exactly.
Vadim
Re: Planning 2.2
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Ezkovich Glen wrote:
> On Nov 22, 2005, at 1:18 AM, Reinhard Poetz wrote:
>
>> Glen Ezkovich wrote:
>
...
>>> I'm a bit confused, is this the only difference between 2.1 and
>>> 2.2 or are the other changes complete and ready to roll? These
>>> changes amount to a refactoring. What distinguishes 2.2 from 2.1.8?
>>
>> not at all :-)
>>
>> - ECM++
>> - Virtual sitemap components
>> - blocks (sitemap blocks, exposing blocks)
>> - per sitemap reloading classloader (for dev)
>> - reworked property management
>> - Spring integration (Spring block)
>> - possible to listen to sitemap events
>> - refactoring of Javaflow (uses now the commons-javaflow project which
>> was started by Thorsten)
>> - introduction of CTemplate (refactoring of JXTemplate in 2.1.x)
>>
>> ... and maybe some other things
>
>
> This is what I thought. I was in effect questioning wether these new
> features are ready to go. My concern is the documentation for these
> new changes and features. An admittedly quick perusal of SVN didn't
> reveal much at all. Even a M1 release requires a bit of documentation
> so that the changes and new things get tested.
First it is an M1 so it is not like that everything have to be
completely finished and polished. Second it is a little bit of a chicken
and egg problem, as long as we don't start to release the new features,
they will feel like a moving target that not is worthwhile to use and
document yet. And as long as no one use it and document it we who
develop the new stuff doesn't have any presure to stabilize it and stop
changing the interfaces.
By releasing an M1 we focus the community on 2.2 and hopefully make the
things you asking for, happen.
Also, while some of the above improvements still are experimental
(blocks, virtual sitemap components ...), much of it isn't. ECM++,
reloading classloader, refactored JXTemplate, ... really simplifies use
of Cocoon, so we should make it available for a larger audience ASAP.
/Daniel
Re: Planning 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Ezkovich Glen wrote:
> This is what I thought. I was in effect questioning wether these new
> features are ready to go. My concern is the documentation for these new
> changes and features. An admittedly quick perusal of SVN didn't reveal
> much at all. Even a M1 release requires a bit of documentation so that
> the changes and new things get tested.
The idea is that milestone releases help us to get early adopters that support
us with finding bugs and writing documentation.
If we waited for 100 % stable implementation and finished documentation, I guess
we will never release 2.2
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Planning 2.2
Posted by Ezkovich Glen <gl...@hard-bop.com>.
On Nov 22, 2005, at 1:18 AM, Reinhard Poetz wrote:
> Glen Ezkovich wrote:
>> On Nov 21, 2005, at 12:16 AM, Reinhard Poetz wrote:
>>> Carsten Ziegeler wrote:
>>>
>>>> Now as 2.1.8 is out, we should think about a 2.2 release. I
>>>> think for a
>>>> 2.2 release we should at least finish the following things:
>>>> - Finish the maven2 build
>>>> - Sync everything with 2.1.x (apply changes that were only
>>>> applied to
>>>> 2.1.x if appropriate)
>>>> - Separate samples from blocks
>>>> - Remove author tags
>>>> While imho the first two items on the list are a simple must, I
>>>> think we
>>>> should really do the other ones as well. If we don't aim to do
>>>> them for
>>>> 2.2 we'll simply never do them. And it's really not that hard
>>>> to do it.
>>>> And finally, we should make a stable forms block (and perhaps
>>>> others as
>>>> well).
>>>> WDYT
>>>
>>>
>>> Aren't we aiming at a 2.2M1 release? If yes, the only must is a
>>> working build system IMHO.
>> I'm a bit confused, is this the only difference between 2.1 and
>> 2.2 or are the other changes complete and ready to roll? These
>> changes amount to a refactoring. What distinguishes 2.2 from 2.1.8?
>
> not at all :-)
>
> - ECM++
> - Virtual sitemap components
> - blocks (sitemap blocks, exposing blocks)
> - per sitemap reloading classloader (for dev)
> - reworked property management
> - Spring integration (Spring block)
> - possible to listen to sitemap events
> - refactoring of Javaflow (uses now the commons-javaflow project which
> was started by Thorsten)
> - introduction of CTemplate (refactoring of JXTemplate in 2.1.x)
>
> ... and maybe some other things
This is what I thought. I was in effect questioning wether these new
features are ready to go. My concern is the documentation for these
new changes and features. An admittedly quick perusal of SVN didn't
reveal much at all. Even a M1 release requires a bit of documentation
so that the changes and new things get tested.
>
> We also have the plan that Cocoon 3.0 will be based on blocks that
> run in a shielded classloader. Currently OSGi ist our best bet (and
> I'm quite optimistic that it will fit our needs).
>
I'm hoping to see this by the end of next year. As long as I have
nothing to do with it it should be doable. Seems like everything I
touch these days falls behind schedule. :(
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: Planning 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Glen Ezkovich wrote:
>
> On Nov 21, 2005, at 12:16 AM, Reinhard Poetz wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
>>> 2.2 release we should at least finish the following things:
>>> - Finish the maven2 build
>>> - Sync everything with 2.1.x (apply changes that were only applied to
>>> 2.1.x if appropriate)
>>> - Separate samples from blocks
>>> - Remove author tags
>>> While imho the first two items on the list are a simple must, I
>>> think we
>>> should really do the other ones as well. If we don't aim to do them for
>>> 2.2 we'll simply never do them. And it's really not that hard to do it.
>>> And finally, we should make a stable forms block (and perhaps others as
>>> well).
>>> WDYT
>>
>>
>> Aren't we aiming at a 2.2M1 release? If yes, the only must is a
>> working build system IMHO.
>
>
> I'm a bit confused, is this the only difference between 2.1 and 2.2 or
> are the other changes complete and ready to roll? These changes amount
> to a refactoring. What distinguishes 2.2 from 2.1.8?
not at all :-)
- ECM++
- Virtual sitemap components
- blocks (sitemap blocks, exposing blocks)
- per sitemap reloading classloader (for dev)
- reworked property management
- Spring integration (Spring block)
- possible to listen to sitemap events
- refactoring of Javaflow (uses now the commons-javaflow project which
was started by Thorsten)
- introduction of CTemplate (refactoring of JXTemplate in 2.1.x)
... and maybe some other things
We also have the plan that Cocoon 3.0 will be based on blocks that run in a
shielded classloader. Currently OSGi ist our best bet (and I'm quite optimistic
that it will fit our needs).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Planning 2.2
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Nov 21, 2005, at 12:16 AM, Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> Now as 2.1.8 is out, we should think about a 2.2 release. I think
>> for a
>> 2.2 release we should at least finish the following things:
>> - Finish the maven2 build
>> - Sync everything with 2.1.x (apply changes that were only applied to
>> 2.1.x if appropriate)
>> - Separate samples from blocks
>> - Remove author tags
>> While imho the first two items on the list are a simple must, I
>> think we
>> should really do the other ones as well. If we don't aim to do
>> them for
>> 2.2 we'll simply never do them. And it's really not that hard to
>> do it.
>> And finally, we should make a stable forms block (and perhaps
>> others as
>> well).
>> WDYT
>
> Aren't we aiming at a 2.2M1 release? If yes, the only must is a
> working build system IMHO.
I'm a bit confused, is this the only difference between 2.1 and 2.2
or are the other changes complete and ready to roll? These changes
amount to a refactoring. What distinguishes 2.2 from 2.1.8?
>
> As date I agree with Sylvain that we should schedule it for the mid
> or the of January so that people (like me that nearly don't have
> any time) can contribute over the Chrismas break.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: Planning 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
>
> I wouldn't say that there are no other features in trunk than the
> build system ;-)
>
> Maybe the Maven build is the feature that you you're waiting for.
> Others may wait for the virtual sitemap components or something else -
> don't know.
I didn't mean to imply that there aren't. From the list of features
that was presented though, most users won't see them. Of course, there
are other features that I want in 2.2; more Ajax, more generators,
transformers, and serializers implemented as thread safe compoents, and
improvements to the portal to name a few. But, for me, these can all be
phased in during milestone releases.
Yes - I'm anxiously waiting for the maven build. I don't expect M1 to
get it completely right, but IMO it needs to be there, because to me
2.2 is all about simplifying and we need to start that by creating a
simple download that doesn't require the end user to build Cocoon to use
it and integrate with it.
Ralph
Re: Planning 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
>
>
> Vadim Gritsenko wrote:
>
>> Ralph Goers wrote:
>>
>>> If we aren't going to upgrade the build system right away then I
>>> might as well stay on 2.1.
>>
>>
>>
>> We are discussing 2.2 *m* 1 (it's not even alpha) release. You
>> probably ought to stay on 2.1 anyway :)
>>
> I understand. But the point of milestone releases is to give folks a
> preview of coming attractions and to get them to provide suggestions and
> feedback. IMO, without the maven build there isn't much of a compelling
> reason to do that since most of the items listed are invisible. Also,
> that is what I want the most lead time on so I can get my projects at
> work ready to take advantage of 2.2.0 once it is released.
I wouldn't say that there are no other features in trunk than the build system ;-)
Maybe the Maven build is the feature that you you're waiting for. Others may
wait for the virtual sitemap components or something else - don't know.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Planning 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
Vadim Gritsenko wrote:
> Ralph Goers wrote:
>
>> If we aren't going to upgrade the build system right away then I
>> might as well stay on 2.1.
>
>
> We are discussing 2.2 *m* 1 (it's not even alpha) release. You
> probably ought to stay on 2.1 anyway :)
>
I understand. But the point of milestone releases is to give folks a
preview of coming attractions and to get them to provide suggestions and
feedback. IMO, without the maven build there isn't much of a compelling
reason to do that since most of the items listed are invisible. Also,
that is what I want the most lead time on so I can get my projects at
work ready to take advantage of 2.2.0 once it is released.
Ralph
Re: Planning 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ralph Goers wrote:
> If we aren't going to upgrade the build system right away then I might
> as well stay on 2.1.
We are discussing 2.2 *m* 1 (it's not even alpha) release. You probably ought to
stay on 2.1 anyway :)
Vadim
Re: Planning 2.2
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 22 Nov 2005, Carsten Ziegeler wrote:
> Date: Tue, 22 Nov 2005 08:59:31 +0100
> From: Carsten Ziegeler <cz...@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Planning 2.2
>
> Ralph Goers wrote:
>>
>> Actually, I disagree. The one compelling (and exciting) thing for me
>> about 2.2 is the ability to download a small core and to be able to use
>> maven (or a tool that hides maven) to create my application. I want to
>> be able to use maven 2 to create my component(s) and integrate them into
>> the Cocoon webapp.
>>
> Agreed, one of the biggest problems of Cocoon is how to develop with it
> and building Cocoon (or parts of it) is really a pita. Providing own
> blocks to others is really hard to do - and the maven build solves all
> these problems. Jorg has already done a great job on this and we are
> really not that far away from a workable system. If we don't switch now
> and see this as a requirement for the first release, we will never
> switch and that would be bad.
I totally agree with Carsten.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDgvaLLNdJvZjjVZARAhQAAJ9eYko9rSA2VGnEF4yTCc23FAaBDACgtqE8
9dXJdsp8iSsk3eprEl9d5xw=
=EYII
-----END PGP SIGNATURE-----
Re: Planning 2.2
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
>Ralph Goers wrote:
>
>
>>Actually, I disagree. The one compelling (and exciting) thing for me
>>about 2.2 is the ability to download a small core and to be able to use
>>maven (or a tool that hides maven) to create my application. I want to
>>be able to use maven 2 to create my component(s) and integrate them into
>>the Cocoon webapp.
>>
>>
>Agreed, one of the biggest problems of Cocoon is how to develop with it
>and building Cocoon (or parts of it) is really a pita. Providing own
>blocks to others is really hard to do - and the maven build solves all
>these problems. Jorg has already done a great job on this and we are
>really not that far away from a workable system. If we don't switch now
>and see this as a requirement for the first release, we will never
>switch and that would be bad.
>
>
+1
/Daniel
Re: Planning 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
>
> Actually, I disagree. The one compelling (and exciting) thing for me
> about 2.2 is the ability to download a small core and to be able to use
> maven (or a tool that hides maven) to create my application. I want to
> be able to use maven 2 to create my component(s) and integrate them into
> the Cocoon webapp.
>
Agreed, one of the biggest problems of Cocoon is how to develop with it
and building Cocoon (or parts of it) is really a pita. Providing own
blocks to others is really hard to do - and the maven build solves all
these problems. Jorg has already done a great job on this and we are
really not that far away from a workable system. If we don't switch now
and see this as a requirement for the first release, we will never
switch and that would be bad.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Planning 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>
>> Reinhard Poetz wrote:
>>
>>> Carsten Ziegeler wrote:
>>>
>>>
>>> Aren't we aiming at a 2.2M1 release? If yes, the only must is a
>>> working build system IMHO.
>>
>>
>>
>> IIRC, ant build is working, so it's not a pre-requisite. No need to
>> rush maven into 2.2m1.
>>
>> Vadim
>>
>
> yes right
Actually, I disagree. The one compelling (and exciting) thing for me
about 2.2 is the ability to download a small core and to be able to use
maven (or a tool that hides maven) to create my application. I want to
be able to use maven 2 to create my component(s) and integrate them into
the Cocoon webapp.
If we aren't going to upgrade the build system right away then I might
as well stay on 2.1.
Re: Planning 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
>>> 2.2 release we should at least finish the following things:
>>>
>>> - Finish the maven2 build
>>> - Sync everything with 2.1.x (apply changes that were only applied to
>>> 2.1.x if appropriate)
>>> - Separate samples from blocks
>>> - Remove author tags
>>>
>>> While imho the first two items on the list are a simple must, I think we
>>> should really do the other ones as well. If we don't aim to do them for
>>> 2.2 we'll simply never do them. And it's really not that hard to do it.
>>>
>>> And finally, we should make a stable forms block (and perhaps others as
>>> well).
>>>
>>> WDYT
>>
>>
>>
>> Aren't we aiming at a 2.2M1 release? If yes, the only must is a
>> working build system IMHO.
>
>
> IIRC, ant build is working, so it's not a pre-requisite. No need to rush
> maven into 2.2m1.
>
> Vadim
>
yes right
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Planning 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>
>> Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
>> 2.2 release we should at least finish the following things:
>>
>> - Finish the maven2 build
>> - Sync everything with 2.1.x (apply changes that were only applied to
>> 2.1.x if appropriate)
>> - Separate samples from blocks
>> - Remove author tags
>>
>> While imho the first two items on the list are a simple must, I think we
>> should really do the other ones as well. If we don't aim to do them for
>> 2.2 we'll simply never do them. And it's really not that hard to do it.
>>
>> And finally, we should make a stable forms block (and perhaps others as
>> well).
>>
>> WDYT
>
>
> Aren't we aiming at a 2.2M1 release? If yes, the only must is a working
> build system IMHO.
IIRC, ant build is working, so it's not a pre-requisite. No need to rush maven
into 2.2m1.
Vadim
Re: Planning 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
> 2.2 release we should at least finish the following things:
>
> - Finish the maven2 build
> - Sync everything with 2.1.x (apply changes that were only applied to
> 2.1.x if appropriate)
> - Separate samples from blocks
> - Remove author tags
>
> While imho the first two items on the list are a simple must, I think we
> should really do the other ones as well. If we don't aim to do them for
> 2.2 we'll simply never do them. And it's really not that hard to do it.
>
> And finally, we should make a stable forms block (and perhaps others as
> well).
>
> WDYT
Aren't we aiming at a 2.2M1 release? If yes, the only must is a working build
system IMHO.
As date I agree with Sylvain that we should schedule it for the mid or the of
January so that people (like me that nearly don't have any time) can contribute
over the Chrismas break.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Planning 2.2
Posted by Peter Hunsberger <pe...@gmail.com>.
On 11/23/05, Jorg Heymans <jh...@domek.be> wrote:
>
> Antonio Fiol Bonnín wrote:
>
> >><replaceregexp byline="true">
> >> <regexp pattern="\*(\s*@author.*)"/>
> >> <substitution expression="*"/>
> >> <fileset dir="." includes="**/*.java" />
> >></replaceregexp>
> >>
> >>This can't possibly be what we need, as anyone would have done it
> >>faster than me, but anyway, here it goes.
>
> I'ld say just give it a spin on a checked out copy of trunk, then have a
> look at the diff. It should be fairly easy to spot if things went wrong.
>
> Now i'm not sure if we wanted to collect all removed authors as well, my
> memory is failing me :( It might make the task a bit more interesting
> though ;)
If you do the diff would give them to you on one nice single spot.... :-)
--
Peter Hunsberger
Re: Planning 2.2
Posted by Jorg Heymans <jh...@domek.be>.
Antonio Fiol Bonnín wrote:
>><replaceregexp byline="true">
>> <regexp pattern="\*(\s*@author.*)"/>
>> <substitution expression="*"/>
>> <fileset dir="." includes="**/*.java" />
>></replaceregexp>
>>
>>This can't possibly be what we need, as anyone would have done it
>>faster than me, but anyway, here it goes.
I'ld say just give it a spin on a checked out copy of trunk, then have a
look at the diff. It should be fairly easy to spot if things went wrong.
Now i'm not sure if we wanted to collect all removed authors as well, my
memory is failing me :( It might make the task a bit more interesting
though ;)
Jorg
Re: Planning 2.2
Posted by Antonio Fiol Bonnín <an...@gmail.com>.
2005/11/23, Antonio Fiol Bonnín <an...@gmail.com>:
> 2005/11/23, Sylvain Wallez <sy...@apache.org>:
> > Antonio Fiol Bonnín wrote:
> > >>> - Remove author tags
> > >>>
> > >> +1, but who does it? Do we want to split the blocks among ourselves, or
> > >> does anyone have enough time to do it all?
> > >>
> > >
> > > This looks quite simple. Tedious but simple. If someone could explain
> > > exactly what to do (private e-mail is OK), it would be a way for me to
> > > make a first "code" contribution to cocoon.
> > >
> > > However, I would only be able to create a patch, that some committer
> > > would have to commit. Is that OK?
> > >
> >
> > IMO it would be better to contribute a script that automates this process.
> >
> > That would avoid both a giant patch and some potential merge problems if
> > the code changes while you're removing the tags.
> >
> > My 0.02 euros...
> >
> > Sylvain
>
> You're right...
>
> If what we need is removing all @author tags in all javadoc on all
> .java files, and it is easily done (in an ant script):
>
> <replaceregexp byline="true">
> <regexp pattern="\*(\s*@author.*)"/>
> <substitution expression="*"/>
> <fileset dir="." includes="**/*.java" />
> </replaceregexp>
>
> This can't possibly be what we need, as anyone would have done it
> faster than me, but anyway, here it goes.
Please note it leaves the "*" at the beginning of the line (so it
leaves a blank javadoc line).
--
Antonio
Re: author tags (Was: Planning 2.2)
Posted by Jorg Heymans <jh...@domek.be>.
Carsten Ziegeler wrote:
> I think we can easily remove all authors who are committers and then see
> who is remaining. For each remaining author we add an entry in the
> status file.
+1
Jorg
Re: author tags (Was: Planning 2.2)
Posted by Carsten Ziegeler <cz...@apache.org>.
David Crossley wrote:
> Joerg Heinicke wrote:
>
>>Antonio Fiol Bonn?n wrote:
>>
>>
>>>This can't possibly be what we need, as anyone would have done it
>>>faster than me, but anyway, here it goes.
>>
>>IIRC the problem was not the pure removal, but the mentioning of the
>>authors in a contrib file file.
>
>
> Exactly. If it was an easy job, then we would have done
> it by now. There is discussion in the archives about
> how the attribution should be done. One suggestion was
> adding to the status.xml file so that they get listed
> at the changes.html page. Another suggestion was a
> "contrib" type file.
>
I think we can easily remove all authors who are committers and then see
who is remaining. For each remaining author we add an entry in the
status file.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: author tags (Was: Planning 2.2)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>Joerg Heinicke wrote:
>>>
>>>
>>>>Antonio Fiol Bonn?n wrote:
>>>>
>>>>
>>>>
>>>>>This can't possibly be what we need, as anyone would have done it
>>>>>faster than me, but anyway, here it goes.
>>>>
>>>>IIRC the problem was not the pure removal, but the mentioning of the
>>>>authors in a contrib file file.
>>>
>>>
>>>Exactly. If it was an easy job, then we would have done
>>>it by now. There is discussion in the archives about
>>>how the attribution should be done. One suggestion was
>>>adding to the status.xml file so that they get listed
>>>at the changes.html page. Another suggestion was a
>>>"contrib" type file.
>>
>>Status.xml already supports authors:
>>
>><developers>
>> <!-- in fifo order -->
>> <person name="Stefano Mazzocchi" email="stefano@apache.org"
>> id="SM" />
>> <person name="Sam Ruby" email="rubys@apache.org"
>> id="SR" />
>>
>>It's a small job to modify the Forrest projectInfo plugin to render
>>these in changes or any other location.
>
>
> That is not what i was referring to. Rather i meant the
> attribute due-to="Donald Duck". The contributor is not
> always a committer. It is just a matter of making sure
> that there is an entry for each major contribution.
OK, I've added the required features to the projectInfo plugin in Forrest:
- add a contributor list to each release (derived from @due-to)
- add a committer list to the end of changes.html
Both of these sections can be turned on or off as required, so if you
want to use the developer list and the @due-to attribute in status.xml
go ahead.
The Forrest zone version of the docs are showing the new build.
I've also added a previously requested feature for Cocoon: control the
sort order of issues, in the cocoon docs they are no
longer sorted.
Ross
Re: author tags (Was: Planning 2.2)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Joerg Heinicke wrote:
> >
> >>Antonio Fiol Bonn?n wrote:
> >>
> >>
> >>>This can't possibly be what we need, as anyone would have done it
> >>>faster than me, but anyway, here it goes.
> >>
> >>IIRC the problem was not the pure removal, but the mentioning of the
> >>authors in a contrib file file.
> >
> >
> >Exactly. If it was an easy job, then we would have done
> >it by now. There is discussion in the archives about
> >how the attribution should be done. One suggestion was
> >adding to the status.xml file so that they get listed
> >at the changes.html page. Another suggestion was a
> >"contrib" type file.
>
> Status.xml already supports authors:
>
> <developers>
> <!-- in fifo order -->
> <person name="Stefano Mazzocchi" email="stefano@apache.org"
> id="SM" />
> <person name="Sam Ruby" email="rubys@apache.org"
> id="SR" />
>
> It's a small job to modify the Forrest projectInfo plugin to render
> these in changes or any other location.
That is not what i was referring to. Rather i meant the
attribute due-to="Donald Duck". The contributor is not
always a committer. It is just a matter of making sure
that there is an entry for each major contribution.
-David
> I want to do a little work on
> that plugin anyway so that the sorting of actions can be turned off
> (i.e. display them chronologically), I can do this at the same time.
>
> Ross
Re: author tags (Was: Planning 2.2)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Joerg Heinicke wrote:
>
>>Antonio Fiol Bonn?n wrote:
>>
>>
>>>This can't possibly be what we need, as anyone would have done it
>>>faster than me, but anyway, here it goes.
>>
>>IIRC the problem was not the pure removal, but the mentioning of the
>>authors in a contrib file file.
>
>
> Exactly. If it was an easy job, then we would have done
> it by now. There is discussion in the archives about
> how the attribution should be done. One suggestion was
> adding to the status.xml file so that they get listed
> at the changes.html page. Another suggestion was a
> "contrib" type file.
Status.xml already supports authors:
<developers>
<!-- in fifo order -->
<person name="Stefano Mazzocchi" email="stefano@apache.org"
id="SM" />
<person name="Sam Ruby" email="rubys@apache.org"
id="SR" />
It's a small job to modify the Forrest projectInfo plugin to render
these in changes or any other location. I want to do a little work on
that plugin anyway so that the sorting of actions can be turned off
(i.e. display them chronologically), I can do this at the same time.
Ross
author tags (Was: Planning 2.2)
Posted by David Crossley <cr...@apache.org>.
Joerg Heinicke wrote:
> Antonio Fiol Bonn?n wrote:
>
> >This can't possibly be what we need, as anyone would have done it
> >faster than me, but anyway, here it goes.
>
> IIRC the problem was not the pure removal, but the mentioning of the
> authors in a contrib file file.
Exactly. If it was an easy job, then we would have done
it by now. There is discussion in the archives about
how the attribution should be done. One suggestion was
adding to the status.xml file so that they get listed
at the changes.html page. Another suggestion was a
"contrib" type file.
http://search.gmane.org/?query=author+tags&email=&group=gmane.text.xml.cocoon.devel
... as you can see there is lots of discussion.
There were various votes and polls. Here is one:
http://thread.gmane.org/gmane.text.xml.cocoon.devel/34114
-David
Re: Contributors (was Re: Planning 2.2)
Posted by Antonio Fiol Bonnín <an...@gmail.com>.
2005/11/25, Upayavira <uv...@odoko.co.uk>:
> Antonio Fiol Bonnín wrote:
> > 2005/11/24, Pier Fumagalli <pi...@betaversion.org>:
> >
> >>On 23 Nov 2005, at 21:34, Joerg Heinicke wrote:
> >>
> >>>On 23.11.2005 16:33, Antonio Fiol Bonnín wrote:
> >>>
> >>>
> >>>>This can't possibly be what we need, as anyone would have done it
> >>>>faster than me, but anyway, here it goes.
> >>>
> >>>IIRC the problem was not the pure removal, but the mentioning of
> >>>the authors in a contrib file file.
> >>
> >>"svn blame" <http://svnbook.red-bean.com/en/1.0/re02.html>
> >
> >
> >
> > So, if I understood correctly, you would like to extract the "history"
> > of authors for every file:
> >
> > #!/bin/bash
> > for i in $(find . -type f -not -name '*.svn-????' | grep -v /\\.svn/)
> > do
> > echo $i
> > svn blame $i | awk '{print $2}' | sort | uniq
> > echo
> > done
> >
> > But I find it hard to do it in a platform-independent way.
>
> Well,
> (a) I'm impressed with your little script
> (b) it doesn't need to be platform independent - it will only be run
> once.
> (c) Actually, I wonder if this is something of a redherring. All it
> will show us is the committers who have committed to CVS or SVN.
> But we know that already. What we want to know is who has
> contributed other than committers.
>
> >>And if someone submits a patch, we can track the contribution in Jira.
> >
> > I don't understand how this should work.
>
> Well, we can use Jira to note contributions, and then manually copy them
> into our contribution records. I imagine that is what Pier means.
>
> Regards, Upayavira
>
I had missed the related ongoing thread (Re: author tags) when I sent
the e-mail with the script. It says basically the same as (c), that
is, that the committers are not the important info to gather. Even
some previous discussion (2004 to mid 2005) about the issue is
mentioned.
So I'm basically lost (again).
But thank you very much for your feedback...
I will try to get things clearer on the other thread.
--
Antonio
Contributors (was Re: Planning 2.2)
Posted by Upayavira <uv...@odoko.co.uk>.
Antonio Fiol Bonnín wrote:
> 2005/11/24, Pier Fumagalli <pi...@betaversion.org>:
>
>>On 23 Nov 2005, at 21:34, Joerg Heinicke wrote:
>>
>>>On 23.11.2005 16:33, Antonio Fiol Bonnín wrote:
>>>
>>>
>>>>This can't possibly be what we need, as anyone would have done it
>>>>faster than me, but anyway, here it goes.
>>>
>>>IIRC the problem was not the pure removal, but the mentioning of
>>>the authors in a contrib file file.
>>
>>"svn blame" <http://svnbook.red-bean.com/en/1.0/re02.html>
>
>
>
> So, if I understood correctly, you would like to extract the "history"
> of authors for every file:
>
> #!/bin/bash
> for i in $(find . -type f -not -name '*.svn-????' | grep -v /\\.svn/)
> do
> echo $i
> svn blame $i | awk '{print $2}' | sort | uniq
> echo
> done
>
> But I find it hard to do it in a platform-independent way.
Well,
(a) I'm impressed with your little script
(b) it doesn't need to be platform independent - it will only be run
once.
(c) Actually, I wonder if this is something of a redherring. All it
will show us is the committers who have committed to CVS or SVN.
But we know that already. What we want to know is who has
contributed other than committers.
>>And if someone submits a patch, we can track the contribution in Jira.
>
> I don't understand how this should work.
Well, we can use Jira to note contributions, and then manually copy them
into our contribution records. I imagine that is what Pier means.
Regards, Upayavira
Re: Planning 2.2
Posted by Antonio Fiol Bonnín <an...@gmail.com>.
2005/11/24, Pier Fumagalli <pi...@betaversion.org>:
> On 23 Nov 2005, at 21:34, Joerg Heinicke wrote:
> > On 23.11.2005 16:33, Antonio Fiol Bonnín wrote:
> >
> >> This can't possibly be what we need, as anyone would have done it
> >> faster than me, but anyway, here it goes.
> >
> > IIRC the problem was not the pure removal, but the mentioning of
> > the authors in a contrib file file.
>
> "svn blame" <http://svnbook.red-bean.com/en/1.0/re02.html>
So, if I understood correctly, you would like to extract the "history"
of authors for every file:
#!/bin/bash
for i in $(find . -type f -not -name '*.svn-????' | grep -v /\\.svn/)
do
echo $i
svn blame $i | awk '{print $2}' | sort | uniq
echo
done
But I find it hard to do it in a platform-independent way.
> And if someone submits a patch, we can track the contribution in Jira.
I don't understand how this should work.
--
Antonio
Re: Planning 2.2
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 23 Nov 2005, at 21:34, Joerg Heinicke wrote:
> On 23.11.2005 16:33, Antonio Fiol Bonnín wrote:
>
>> This can't possibly be what we need, as anyone would have done it
>> faster than me, but anyway, here it goes.
>
> IIRC the problem was not the pure removal, but the mentioning of
> the authors in a contrib file file.
"svn blame" <http://svnbook.red-bean.com/en/1.0/re02.html>
And if someone submits a patch, we can track the contribution in Jira.
Pier
Re: Planning 2.2
Posted by Joerg Heinicke <jo...@gmx.de>.
On 23.11.2005 16:33, Antonio Fiol Bonnín wrote:
> This can't possibly be what we need, as anyone would have done it
> faster than me, but anyway, here it goes.
IIRC the problem was not the pure removal, but the mentioning of the
authors in a contrib file file.
Jörg
Re: Planning 2.2
Posted by Antonio Fiol Bonnín <an...@gmail.com>.
2005/11/23, Sylvain Wallez <sy...@apache.org>:
> Antonio Fiol Bonnín wrote:
> >>> - Remove author tags
> >>>
> >> +1, but who does it? Do we want to split the blocks among ourselves, or
> >> does anyone have enough time to do it all?
> >>
> >
> > This looks quite simple. Tedious but simple. If someone could explain
> > exactly what to do (private e-mail is OK), it would be a way for me to
> > make a first "code" contribution to cocoon.
> >
> > However, I would only be able to create a patch, that some committer
> > would have to commit. Is that OK?
> >
>
> IMO it would be better to contribute a script that automates this process.
>
> That would avoid both a giant patch and some potential merge problems if
> the code changes while you're removing the tags.
>
> My 0.02 euros...
>
> Sylvain
You're right...
If what we need is removing all @author tags in all javadoc on all
.java files, and it is easily done (in an ant script):
<replaceregexp byline="true">
<regexp pattern="\*(\s*@author.*)"/>
<substitution expression="*"/>
<fileset dir="." includes="**/*.java" />
</replaceregexp>
This can't possibly be what we need, as anyone would have done it
faster than me, but anyway, here it goes.
--
Antonio
Re: Planning 2.2
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Fiol Bonnín wrote:
>>> - Remove author tags
>>>
>> +1, but who does it? Do we want to split the blocks among ourselves, or
>> does anyone have enough time to do it all?
>>
>
> This looks quite simple. Tedious but simple. If someone could explain
> exactly what to do (private e-mail is OK), it would be a way for me to
> make a first "code" contribution to cocoon.
>
> However, I would only be able to create a patch, that some committer
> would have to commit. Is that OK?
>
IMO it would be better to contribute a script that automates this process.
That would avoid both a giant patch and some potential merge problems if
the code changes while you're removing the tags.
My 0.02 euros...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Planning 2.2
Posted by Antonio Fiol Bonnín <an...@gmail.com>.
> > - Remove author tags
>
> +1, but who does it? Do we want to split the blocks among ourselves, or
> does anyone have enough time to do it all?
This looks quite simple. Tedious but simple. If someone could explain
exactly what to do (private e-mail is OK), it would be a way for me to
make a first "code" contribution to cocoon.
However, I would only be able to create a patch, that some committer
would have to commit. Is that OK?
--
Antonio
Re: Planning 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> Le 20 nov. 05, à 19:41, Carsten Ziegeler a écrit :
>
>
>>Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
>>2.2 release we should at least finish the following things:
>>
>>- Finish the maven2 build
>
>
> And get rid of the ant-based build?
Exactly :)
> I think we should remove it as soon as the maven build is good enough.
>
>
>
> That's a lot of work if we do it for all blocks. Concentrating on a few
> blocks only (see also Daniel's separate release cycles proposal) would
> lessen the amount.
>
Ok.
>
>>- Remove author tags
>
>
> +1, but who does it? Do we want to split the blocks among ourselves, or
> does anyone have enough time to do it all?
>
I think this could simply be a release creteria for a block.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Planning 2.2
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 20 nov. 05, à 19:41, Carsten Ziegeler a écrit :
> Now as 2.1.8 is out, we should think about a 2.2 release. I think for a
> 2.2 release we should at least finish the following things:
>
> - Finish the maven2 build
And get rid of the ant-based build?
I think we should remove it as soon as the maven build is good enough.
> - Sync everything with 2.1.x (apply changes that were only applied to
> 2.1.x if appropriate)
+1
> - Separate samples from blocks
That's a lot of work if we do it for all blocks. Concentrating on a few
blocks only (see also Daniel's separate release cycles proposal) would
lessen the amount.
> - Remove author tags
+1, but who does it? Do we want to split the blocks among ourselves, or
does anyone have enough time to do it all?
-Bertrand