You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2006/03/30 16:48:43 UTC
Changes in trunk after cleanup + what else needs to be done
First, this mail is rather long but everybody who works with trunk (or wants to
work with it again) should read it!!! There are some changes and a couple of
questions and TODOs which can't be solved by me (alone).
What did I change:
~~~~~~~~~~~~~~~~~~
As proposed, I split up trunk into
- blocks
- blocks-tobeconverted
- commons
- core
[- site]
- tools
_blocks_ contains all blocks that already follow the new structure of
src/main/java (sources) and src/main/resources/COB-INF (samples) and
src/main/resources/META-INF/legacy (configuration files).
_blocks-tobeconverted_ cntains all blocks that have already been mavenzied but
don't follow the new structure. They require some more work.
_commons_ contains all the stuff that we need for distributions and general
stuff like logo, awards, etc. This will be the home directory of the Maven
assembly configurations that describe our future binary distributions.
_core_ contains the core stuff and the blocks-fw. I'm sure that core can be
split up into more blocks so that it gets even slimmer.
_site_ doesn't exist ATM. I will be filled with a Maven 2 module that contains
our core stuff. (my next task is providing a DaisyMojo as discussed two weeks ago)
_tools_ contains all modules that are used to develop *with* Cocoon or stuff
that we use to e.g. generate our documentation. You'll also find there our
archetypes Currently this is only the blocks-archetype but another archtetype
will be useful that creates a minimal webapp module.
- o -
What's next?
~~~~~~~~~~~~
Checkout trunk from SVN and run
$ mvn install -Dmaven.test.skip=true
from the root directory.
Then, if you use Eclipse, call
$ mvn eclipse:eclipse
and create the Eclispe project descriptors.
Next step is getting familiar with the new directory structure and where to find
which module.
And, as I mentioned several times in the past, if you're not familiar with Maven
2, follow their tutorial which is a good starting point
(http://maven.apache.org/guides/getting-started/index.html).
- o -
I also created a directory "attic". It contains all the stuff that doesn't seem
to be useful any longer. Please, review this. I will delete the folder on April,
30th. This should be enough time for everybody. Also have a look the things in
whiteboard. I guess there is a lot of outdated stuff there too.
Btw, the size of trunk was reduced from 214mb to 129mb.
- o -
The blocks conversion script by Andreas was very helpful and certainly saved a
lot of time. One thing that we would need is a script that moves all resources
from src/main/java to src/main/resources. Could some bash-guru out there take
care of it please?
- o -
Here is a list of blocks that are special to some extend:
hsqldb: It contains the database. How do we deal with it in the future?
javaflow: It contains a compile directory. I've no idea whether we need it any
longer.
scratchpad: Contains garbage and javacApi. Garbage could be its own block and
javacApi is the first implementation of the compiling classloader by Chris
Oliver, IIRC and should be completly replaced by commons-jci IIUC.
(there might be more but these where the warnings/errors produced by the
conversion script)
If you convert one of these blocks, please find some solution for them.
- o -
Because of the new structure in trunk, I had to work on the Maven build system.
Currently it builds
- cocoon-core
- cocoon-webapp
- cocoon-forms
- cocoon-block-deployer
All other modules are commented out ATM. If you are familiar with a particular
block, try to uncomment it (either to blocks/pom.xml or
blocks-tobeconverted/pom.xml) and build it. Three things you should be aware of:
- I used the version "x-SNAPSHOT" for all pom-modules. Pom-modules are modules
that don't generate an artifact but are only used within the build system.
I used the "x" as version to show that this is *not* a usual version number.
Up-to-now the version number was 2.2.0 which isn't correct as we can start
to have separate release cycles for modules soon!
Though I'm not sure if this is a good idea to use a letter and not a number.
Jorg (and others), WDYT? Would something like "x1" be better? I wonder
what reasons could cause a version number change there ...
For consistency we should use this pattern also for the pom-modules that
are collections for impl/sample/mocks, WDYT?
- Please use 3-digits version numbers for blocks. Unfortunatly I created
2-digits version numbers for all converted blocks and noticed my mistake
too late :-(
As you have to touch pom.xml anyway, there shouldn't be too much overhead.
- Blocks in 'blocks-tobeconverted' are the manually converted blocks and
don't follow the structure yet. After changing the structure, please move
them in the repo into /trunk/blocks.
- o -
One very important thing: Can somebody take care of the unit-tests of
cocoon-core? I got 79 errors and 2 failurs. Either we throw the failing tests
away or fix them. Carsten, WDYT?
I want to use Continuum for continous integration very soon so that we see
incompatible changes very soon.
- o -
Thanks for reading so far :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
>
>> I also disabled the rest of the non working test until someone fix
>> them. So now one can run the tests at cocoon-core, at least.
>
> That's good news! From now on we can use Continuum for continious
> integration builds. Jorg, do we already get notification messages, if
> the build fails?
I wrote cocoon-core not cocoon-trunk ;) After a little bit more work and
test disabling all enabled tests in the build in trunk works.
It should be noted however that most of the blocks are disabled in the
trunk, so there is a lot left to do.
Anyway, we have a starting point for clean integration builds, which is
great.
/Daniel
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Jorg Heymans <jh...@domek.be>.
Reinhard Poetz wrote:
> That's good news! From now on we can use Continuum for continious
> integration builds. Jorg, do we already get notification messages, if
> the build fails?
Not for the moment no, I figured it would be just flooding the list with
more failure messages.
I'll try this week to get continuum up and running again with the new
repository structure and will enable build failure notification to the list.
Regards
Jorg
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> I also disabled the rest of the non working test until someone fix them.
> So now one can run the tests at cocoon-core, at least.
That's good news! From now on we can use Continuum for continious integration
builds. Jorg, do we already get notification messages, if the build fails?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Carsten Ziegeler schrieb:
>> Daniel Fagerstrom wrote:
>>> Agree, but a first step could be to look at the error messages. I did
>>> that and the vast majority of errors are due to that the component
>>> testing framework doesn't find find the role of the component. So before
>>> deactivating all of the test it could be a good idea to see if it is
>>> easy to make the component testing framework work again (Carsten?).
>> Hmm, when I rewrote the core to use Spring, I think I also fixed the
>> testing framework - but apparently not in the right way :( I'll have a
>> look at this in the next days.
>>
> I fixed most of the test cases,
Great!
> some are still failing, I'll look at
> them in the next
> days. It would be great if someone could have a look at the failing test
> cases for the virtual pipeline components. They currently fail because
> wiring.xml can't be found and I have no clue how to fix this.
I fixed that part, but I'm afraid that there are a number of other
things that needs to be fixed as well. Also the test takes a lot of time
to run, so I disabled them and return to them at some other time.
I also disabled the rest of the non working test until someone fix them.
So now one can run the tests at cocoon-core, at least.
/Daniel
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler schrieb:
> Daniel Fagerstrom wrote:
>> Agree, but a first step could be to look at the error messages. I did
>> that and the vast majority of errors are due to that the component
>> testing framework doesn't find find the role of the component. So before
>> deactivating all of the test it could be a good idea to see if it is
>> easy to make the component testing framework work again (Carsten?).
> Hmm, when I rewrote the core to use Spring, I think I also fixed the
> testing framework - but apparently not in the right way :( I'll have a
> look at this in the next days.
>
I fixed most of the test cases, some are still failing, I'll look at
them in the next
days. It would be great if someone could have a look at the failing test
cases for the virtual pipeline components. They currently fail because
wiring.xml can't be found and I have no clue how to fix this.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> Agree, but a first step could be to look at the error messages. I did
> that and the vast majority of errors are due to that the component
> testing framework doesn't find find the role of the component. So before
> deactivating all of the test it could be a good idea to see if it is
> easy to make the component testing framework work again (Carsten?).
Hmm, when I rewrote the core to use Spring, I think I also fixed the
testing framework - but apparently not in the right way :( I'll have a
look at this in the next days.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Jorg Heymans wrote:
>> Jorg Heymans wrote:
>>
>>
>>>> One very important thing: Can somebody take care of the unit-tests of
>>>> cocoon-core? I got 79 errors and 2 failurs. Either we throw the
>>>> failing tests away or fix them. Carsten, WDYT?
>>>
>>> I'll have a look at this.
>>
>>
>> oops i interpreted these test errors as compile errors , i now see that
>> they compile fine. I'll leave the actual fixing of the tests to the
>> better initiated :-)
>
> <hint>Deactivating them for now would be a good start<hint/> ;-)
Agree, but a first step could be to look at the error messages. I did
that and the vast majority of errors are due to that the component
testing framework doesn't find find the role of the component. So before
deactivating all of the test it could be a good idea to see if it is
easy to make the component testing framework work again (Carsten?).
After that we could deactivate the non working tests and fix one at the
time.
/Daniel
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
> Jorg Heymans wrote:
>
>
>>>One very important thing: Can somebody take care of the unit-tests of
>>> cocoon-core? I got 79 errors and 2 failurs. Either we throw the
>>>failing tests away or fix them. Carsten, WDYT?
>>
>>I'll have a look at this.
>
>
> oops i interpreted these test errors as compile errors , i now see that
> they compile fine. I'll leave the actual fixing of the tests to the
> better initiated :-)
<hint>Deactivating them for now would be a good start<hint/> ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Jorg Heymans <jh...@domek.be>.
Jorg Heymans wrote:
>> One very important thing: Can somebody take care of the unit-tests of
>> cocoon-core? I got 79 errors and 2 failurs. Either we throw the
>> failing tests away or fix them. Carsten, WDYT?
>
> I'll have a look at this.
oops i interpreted these test errors as compile errors , i now see that
they compile fine. I'll leave the actual fixing of the tests to the
better initiated :-)
Jorg
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Jorg Heymans <jh...@domek.be>.
Reinhard Poetz wrote:
>
> The blocks conversion script by Andreas was very helpful and
> certainly saved a lot of time. One thing that we would need is a
> script that moves all resources from src/main/java to
> src/main/resources. Could some bash-guru out there take care of it
> please?
i used some oneliner with find a while ago when i did the initial
conversion, i'll see if i can dig it up again.
> I used the version "x-SNAPSHOT" for all pom-modules. Pom-modules are
> modules that don't generate an artifact but are only used within the
> build system. I used the "x" as version to show that this is *not* a
> usual version number. Up-to-now the version number was 2.2.0 which
> isn't correct as we can start to have separate release cycles for
> modules soon!
The idea behind versioning the multi-module poms (or pom-modules as you
call them) is that you can effectively have different parent poms for
different module releases. At the moment we don't use the multi-module
poms for anything else but declaring the different modules (except for
the root pom). At some point however we might decide to put some more
information in there that is common to all sub-modules of a module (eg
extra <build> that is only needed from that version onwards), and that's
where the versioning comes in handy.
> Though I'm not sure if this is a good idea to use a letter and not a
> number. Jorg (and others), WDYT? Would something like "x1" be better?
....... checking maven repo and #maven ........
<quote who="John Casey">
Poms that do not participate in the release cycle of the application can
carry a singledigit version (or "serialnumber" as they call it) to
distinguish the fact that they are "special".
</quote>
Based upon this i would suggest:
- we start all multi-module poms for the blocks at version 1-SNAPSHOT.
- core/pom.xml should follow the current development version ie
2.2.0-SNAPSHOT (or whatever version number we decide to assign to the
next release).
(if all this is not clear let me know i'll clarify with an example)
> I wonder what reasons could cause a version number change there ...
see above about versioning.
> One very important thing: Can somebody take care of the unit-tests of
> cocoon-core? I got 79 errors and 2 failurs. Either we throw the
> failing tests away or fix them. Carsten, WDYT?
I'll have a look at this.
Regards,
Jorg
PS And *thanks* for the great work !
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> Is someone working on moving the "tobeconverted" blocks?
>>
>> What needs to be done to correctly convert a block?
>
> Please read http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114373029111189&w=2
> and compare the directory structure of a block and a tobeconverted block. I'm
> not sure but I think the svn:externals properties could be a problem in 2.1
> because of the seperation of java and resources. I guess that the Ant build in
> 2.1 has to be enhanced.
>
I just updated the ant build in 2.1.x - you can now mount a "resources"
and a "test-resources" directory using svn:externals. These directories
are optional of course. I tested this for the forms block and it seems
to work.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Is someone working on moving the "tobeconverted" blocks?
>
> What needs to be done to correctly convert a block?
Please read http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114373029111189&w=2
and compare the directory structure of a block and a tobeconverted block. I'm
not sure but I think the svn:externals properties could be a problem in 2.1
because of the seperation of java and resources. I guess that the Ant build in
2.1 has to be enhanced.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Carsten Ziegeler <cz...@apache.org>.
Is someone working on moving the "tobeconverted" blocks?
What needs to be done to correctly convert a block?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Reinhard Poetz schrieb:
>
> The blocks conversion script by Andreas was very helpful and certainly
> saved a
> lot of time. One thing that we would need is a script that moves all
> resources
> from src/main/java to src/main/resources. Could some bash-guru out there
> take
> care of it please?
They are not so much, perhaps it makes sense to move them manually.
Here's the list I found:
./cocoon-axis/cocoon-axis-impl/src/main/java/org/apache/cocoon/components/axis/axis.roles
./cocoon-axis/cocoon-axis-impl/src/main/java/org/apache/cocoon/webservices/cache/DeploymentDescriptor.wsdd
./cocoon-axis/cocoon-axis-impl/src/main/java/org/apache/cocoon/webservices/memory/DeploymentDescriptor.wsdd
./cocoon-axis/cocoon-axis-impl/src/main/java/org/apache/cocoon/webservices/system/DeploymentDescriptor.wsdd
./cocoon-deli/cocoon-deli-impl/src/main/java/org/apache/cocoon/components/deli/deli.roles
./cocoon-hsqldb/cocoon-hsqldb-impl/src/main/java/org/apache/cocoon/components/hsqldb/hsqldb.roles
./cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/components/jms/jms.roles
./cocoon-jsp/cocoon-jsp-impl/src/main/java/org/apache/cocoon/components/jsp/jsp.roles
./cocoon-lucene/cocoon-lucene-impl/src/main/java/org/apache/cocoon/components/search/lucene.roles
./cocoon-lucene/cocoon-lucene-impl/src/main/java/org/apache/cocoon/components/search/package.html
./cocoon-mail/cocoon-mail-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/sendmail.xsl
./cocoon-ojb/cocoon-ojb-impl/src/main/java/org/apache/cocoon/ojb/ojb.roles
./cocoon-petstore/cocoon-petstore-impl/src/main/java/org/apache/cocoon/components/flow/javascript/Database.js
./cocoon-poi/cocoon-poi-impl/src/main/java/org/apache/cocoon/components/elementprocessor/impl/poi/hssf/elements/Anchors.java.rep
./cocoon-profiler/cocoon-profiler-impl/src/main/java/org/apache/cocoon/components/profiler/profiler.roles
./cocoon-python/cocoon-python-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/python/xsp.xsl
./cocoon-repository/cocoon-repository-impl/src/main/java/org/apache/cocoon/components/repository/repository.roles
./cocoon-scratchpad/cocoon-scratchpad-impl/src/main/java/org/apache/cocoon/ant/readme.txt
./cocoon-scratchpad/cocoon-scratchpad-impl/src/main/java/org/apache/cocoon/components/flow/javascript/fom/ao_fom_system.js
./cocoon-scratchpad/cocoon-scratchpad-impl/src/main/java/org/apache/cocoon/components/readme.txt
./cocoon-slide/cocoon-slide-impl/src/main/java/org/apache/cocoon/components/slide/slide.roles
./cocoon-web3/cocoon-web3-impl/src/main/java/org/apache/cocoon/components/web3/web3.roles
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/action.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/capture.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/cookie.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/esql.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/form-validator.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/input.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/jpath.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/log.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/logicsheet-util.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/request.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/response.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/sel.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/session-fw.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/session.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/soap.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/util.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/xscript-lib.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/xscript.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/java/xsp.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/javascript/request.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/javascript/response.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/javascript/session.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/language/markup/xsp/javascript/xsp.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/xscript/xslt/copy-of.xsl
./cocoon-xsp/cocoon-xsp-impl/src/main/java/org/apache/cocoon/components/xscript/xslt/value-of.xsl
If still needed I can provide some generated commands for the creation
of the directories in src/main/resources and the svn commands for moving
the files.
Cheers,
Andreas
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> One very important thing: Can somebody take care of the unit-tests of
> cocoon-core? I got 79 errors and 2 failurs. Either we throw the failing tests
> away or fix them. Carsten, WDYT?
>
I think we should try to fix the unit tests - they should have a value
after all. But I can't help atm, so perhaps we could disable the failing
tests first (I guess there is a exclude for junit tests in maven).
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>> What about branch? We supposed to have a svn freeze tomorrow, but
>> branch can't be checked out at the moment due to (at least) template
>> block being in blocks-tobeconverted:
>
> I'll (try) to fix this.
Is fixed now - sorry for any inconveniences.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>
>>
>> First, this mail is rather long but everybody who works with trunk (or
>> wants to work with it again) should read it!!!
>
>
> What about branch? We supposed to have a svn freeze tomorrow, but branch
> can't be checked out at the moment due to (at least) template block
> being in blocks-tobeconverted:
I'll (try) to fix this.
>> _blocks-tobeconverted_ cntains all blocks that have already been
>> mavenzied but
>> don't follow the new structure. They require some more work.
>
>
> Is there anybody already focusing on this? Do we postpone 2.1.9?
We should wait with this until 2.1.9 is out as I'm not sure if it's possible to
use the new block structure via svn:externals without major changes in the 2.1.x
Ant build ... :-/
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Changes in trunk after cleanup + what else needs to be done
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
>
> First, this mail is rather long but everybody who works with trunk (or
> wants to work with it again) should read it!!!
What about branch? We supposed to have a svn freeze tomorrow, but branch can't
be checked out at the moment due to (at least) template block being in
blocks-tobeconverted:
> _blocks-tobeconverted_ cntains all blocks that have already been
> mavenzied but
> don't follow the new structure. They require some more work.
Is there anybody already focusing on this? Do we postpone 2.1.9?
Vadim