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/27 09:39:47 UTC
Questions on cleaning up trunk
Andreas asked in http://issues.apache.org/jira/browse/COCOON-1802 a couple of
questions. I will try to answer them but please add your comments in the case of
a different opinion. Changes now are easy, after Wednesday (not Thursday as I
wrote in my previous mails) when Andreas and I will actually do it they are much
more difficult:
* Agree on a naming convention for artifact ID suffixes (singular vs. plural):
e.g. *-mocks, *-impl, *-sample
fine for me.
* What happens with the following dirs within cocoon trunk: lib, misc, src, tools?
lib: remove it
misc: goes into trunk/common
src:
# confpatch/ remove it - replaced by Maven build
# deprecated/ remove it - things deprecated in 2.1.x are not necessary
in trunk, right?
# osgi-servlet/ remove it - replaced by blocks-fw-osgi-impl
# resources/ no idea - if nobody speaks up till Wednesday, we will
remove them
# samples/ remove it - old or duplicates
# schema/ remove it - outdated
# test/ remove it - Anteater tests: in branch we have a working
httpunit environment. needs to be ported
* Why are databases and xmldb in directory blocks as well as inCocoon trunk?
probably the person who moved them forgot to delete them. Jean-Baptist, wasn't
it you who did the move? If yes, can we delete them in /cocoon/blocks?
* What happens with scratchpad? Still needed?
yes unfortunatly there is some valuable stuff there, e.g. the caching source
* What's the right version for cocoon-core dependencies: 2.2.0-SNAPSHOT or
2.2-SNAPSHOT?
2.2.0-SNAPSHOT - we should use the 3-digits pattern IMO
* How should the 'mocks' directory be mapped to the new directory structure?
- Solution 1: Map to cocoon-<block>-mocks/src/main/java (separate artifact)
- Solution 2: Map to cocoon-<block>-impl/src/mock/java (not a standard Maven
way I think - currently used for the JSP block)
- Solution 3: Include them in cocoon-mocks/src/mock/java (possibly prefered,
since it already exists?)
- Solution 4: May have to be mapped manually (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114277568815707&w=2)
If mocks are specific for a particular block, we should put the classes into a
separate module. How do we express the dependency so that it compiles with the
mocks but runs with the implementation?
* Add 'name' tag to each POM in a consistent way:
- parent POM: <name>
- impl POM: <name> Implementation
- sample POM: <name> Samples
- mock POM: <name> Mocks
agreed
* Copy/move status.xml
- There are some inconsistencies for the current new blocks
- Some are located in the parent block, some in the impl block
- Where should they be located?
- May there be more than one? e.g. for impl, sample, ...
Put status.xml into the impl module as for them we will create the documentation.
Here some more files that need to be moved:
# CREDITS.txt - Where do we need them? For the distribution?
For now I'd put them into the trunk/commons directory
Thinking more about this, I propose to configure
the assembly plugin for commons so that we can
build distribution packages from there.
# DESKTOP.INI - remains where it is
# INSTALL.txt - move to trunk/commons
# KEYS - move to trunk/commons
# LICENSE.txt - move to trunk/commons
# NOTICE.txt - move to trunk/commons
# README.blocksmode.txt - remove it (outdated)
# README.m10n.txt - leave it where it is
# README.osgi.txt - remove it (outdated)
# README.txt - move to trunk/commons
# TO-SYNC-FROM-BRANCH.txt - leave it
# announcement.xml - move to trunk/commons
Anything else that needs to be considered by Andreas and me?
--
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: Questions on cleaning up trunk
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
> Reinhard Poetz wrote:
>
>
>>* What's the right version for cocoon-core dependencies: 2.2.0-SNAPSHOT
>>or 2.2-SNAPSHOT?
>>
>>2.2.0-SNAPSHOT - we should use the 3-digits pattern IMO
>>
>
> +1
>
>
>> - Solution 3: Include them in cocoon-mocks/src/mock/java (possibly
>>prefered, since it already exists?)
>
>
> +1
>
> Having a separate block level module just for a few mock classes is
> overkill.
>
>
>>If mocks are specific for a particular block, we should put the classes
>>into a separate module. How do we express the dependency so that it
>>compiles with the mocks but runs with the implementation?
>
>
> <scope>provided</scope>
ok. Using this scope, I agree with you that one mocks module should usually be
enough.
>>* Copy/move status.xml
>> - There are some inconsistencies for the current new blocks
>> - Some are located in the parent block, some in the impl block
>> - Where should they be located?
>> - May there be more than one? e.g. for impl, sample, ...
>
>
> Perhaps you could just keep them at the module level for now and split
> them up later when the need arises (eg different implementations for one
> block)
I'd just have one status.xml per module (if we define module as a group of
-impl, -samples) and would put it into the impl sub-module.
--
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: Questions on cleaning up trunk
Posted by Jorg Heymans <jh...@domek.be>.
Reinhard Poetz wrote:
> * What's the right version for cocoon-core dependencies: 2.2.0-SNAPSHOT
> or 2.2-SNAPSHOT?
>
> 2.2.0-SNAPSHOT - we should use the 3-digits pattern IMO
>
+1
> - Solution 3: Include them in cocoon-mocks/src/mock/java (possibly
> prefered, since it already exists?)
+1
Having a separate block level module just for a few mock classes is
overkill.
> If mocks are specific for a particular block, we should put the classes
> into a separate module. How do we express the dependency so that it
> compiles with the mocks but runs with the implementation?
<scope>provided</scope>
> * Copy/move status.xml
> - There are some inconsistencies for the current new blocks
> - Some are located in the parent block, some in the impl block
> - Where should they be located?
> - May there be more than one? e.g. for impl, sample, ...
Perhaps you could just keep them at the module level for now and split
them up later when the need arises (eg different implementations for one
block)
Regards
Jorg
Re: Questions on cleaning up trunk
Posted by Reinhard Poetz <re...@apache.org>.
Jean-Baptiste Quenot wrote:
> * Reinhard Poetz:
>
>
>>* Why are databases and xmldb in directory blocks as well as
>>inCocoon trunk?
>>
>>probably the person who moved them forgot to delete
>>them. Jean-Baptist, wasn't it you who did the move? If yes, can
>>we delete them in /cocoon/blocks?
>
>
> I did not delete blocks/xmldb because I didn't know what to do
> with conf and WEB-INF. The rest can be deleted. Let me some more
> time to finish the work, as I see we could finally agree on the
> converted directory structure.
e.g.
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-block-deployer/cocoon-deployer-plugin-demo/
uses this new structure
--
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: Questions on cleaning up trunk
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Reinhard Poetz:
> * Why are databases and xmldb in directory blocks as well as
> inCocoon trunk?
>
> probably the person who moved them forgot to delete
> them. Jean-Baptist, wasn't it you who did the move? If yes, can
> we delete them in /cocoon/blocks?
I did not delete blocks/xmldb because I didn't know what to do
with conf and WEB-INF. The rest can be deleted. Let me some more
time to finish the work, as I see we could finally agree on the
converted directory structure.
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: licensing issues for trunk (Was: Questions on cleaning up trunk)
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Anyway i am concentrating on the source headers.
I need to make a list of directories or filenames
which need to be excluded from having the Apache
license headers inserted.
Can anyone help?
See "Treatment of Third-Party Works"
http://www.apache.org/legal/src-headers.html#3party
e.g.
blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/mattkruse-lib
blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/resources/htmlarea
tools/sitemaptags2daisy/src/main/resources/org/apache/cocoon/documentation/daisy/htmlcleaner.xml
licensing issues for trunk (Was: Questions on cleaning up trunk)
Posted by David Crossley <cr...@apache.org>.
I have started doing the update of the license headers.
Done now for 2.1 branch. It was a huge diff so the svn-mailer
truncated it thankfully.
http://svn.apache.org/viewvc?rev=433543&view=rev
Before committing i tried to check the diffs by grepping
known lines and see what is left. Seems okay, but doing
such mass semi-automated changes is worrying.
Doing the trunk is lots harder. I will be doing it
gradually over the next weeks.
Trying to follow the new policy document
http://www.apache.org/legal/src-headers.html
there are some other issues that we need to attend to:
The NOTICE.txt file has a special purpose and we are not
doing it properly, i.e. we have its content tangled up
with another file called CREDITS.txt
At Forrest i added a banner at the top to explain its
purpose. Not sure what Cocoon want to do.
http://svn.apache.org/repos/asf/forrest/trunk/NOTICE.txt
Another issue is the LICENSE.txt file. Evidently we
also need to "add pointers" in that file to each third-party
license file. I gather some people are experimenting
with a Maven plugin. Not sure how that correlates with
the new policy. So i will leave that to others.
Anyway i am concentrating on the source headers.
-David
David Crossley wrote:
> Reinhard Poetz wrote:
> >
> > Here some more files that need to be moved:
> >
> > # CREDITS.txt - Where do we need them? For the distribution?
> > For now I'd put them into the trunk/commons directory
> > Thinking more about this, I propose to configure
> > the assembly plugin for commons so that we can
> > build distribution packages from there.
> > # DESKTOP.INI - remains where it is
> > # INSTALL.txt - move to trunk/commons
> > # KEYS - move to trunk/commons
> > # LICENSE.txt - move to trunk/commons
> > # NOTICE.txt - move to trunk/commons
>
> According to http://www.apache.org/dev/apply-license.html
> the LICENSE.txt and NOTICE.txt must located at the top-level
> of the "distribution". What does that mean in our new setup?
>
> Any attributions required by third-party products are
> supposed to be in NOTICE.txt but we have them at the
> bottom of CREDITS.txt
>
> -David
Re: Questions on cleaning up trunk
Posted by Jorg Heymans <jh...@domek.be>.
Reinhard Poetz wrote:
> - how to we deal with license stuff (we need to add all licenses of all
> libraries into the distribution)
At the moment this is not handled properly by maven.
IIRC it was once suggested to have a separate module ie
"cocoon-licenses" with all licenses in it and make core depend on this
module. This would make adding new licenses trivial and make sure that
they will always be included in any cocoon project.
> BTW, the simplest possible distribution could be a POM only - the only
> problem is slow M2 repo connections. WDOT?
well if people use the maven2 mirror instead of just central then that
would give a big performance boost already. We should make a BIG
documentation note that this is almost mandatory for a smooth maven2
experience.
I'm in the (slow) process of moving some more libs off cvs.a.o to
central. The outerthought stuff (xreporter,daisy-*) has been requested
for upload and i've contacted the author of the neko libs. Also in
excalibur there seems to be a bit of motivation to do a new maven2 based
release within the next few weeks/months - I'll see what i can more do
to speed things up there as well.
In any case i did some testing with moving all our dependencies on
cvs.a.o to my own server and it worked flawlessly, so worst case we just
move them before the release and be done with it.
HTH
Jorg
Re: Questions on cleaning up trunk
Posted by Reinhard Poetz <re...@apache.org>.
David Crossley wrote:
> Reinhard Poetz wrote:
>
>>Here some more files that need to be moved:
>>
>># CREDITS.txt - Where do we need them? For the distribution?
>> For now I'd put them into the trunk/commons directory
>> Thinking more about this, I propose to configure
>> the assembly plugin for commons so that we can
>> build distribution packages from there.
>># DESKTOP.INI - remains where it is
>># INSTALL.txt - move to trunk/commons
>># KEYS - move to trunk/commons
>># LICENSE.txt - move to trunk/commons
>># NOTICE.txt - move to trunk/commons
>># README.blocksmode.txt - remove it (outdated)
>># README.m10n.txt - leave it where it is
>># README.osgi.txt - remove it (outdated)
>># README.txt - move to trunk/commons
>># TO-SYNC-FROM-BRANCH.txt - leave it
>># announcement.xml - move to trunk/commons
>
>
> According to http://www.apache.org/dev/apply-license.html
> the LICENSE.txt and NOTICE.txt must located at the top-level
> of the "distribution". What does that mean in our new setup?
>
> Any attributions required by third-party products are
> supposed to be in NOTICE.txt but we have them at the
> bottom of CREDITS.txt
My idea is that we create our distributions from trunk/commons as base directory.
What I forgot to mention in my last mail - there are two more things to do
before we can get out a release:
- define what a Cocoon 2.3 release is
- how to we deal with license stuff (we need to add all licenses of all
libraries into the distribution)
BTW, the simplest possible distribution could be a POM only - the only problem
is slow M2 repo connections. WDOT?
--
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: Questions on cleaning up trunk
Posted by David Crossley <cr...@apache.org>.
Reinhard Poetz wrote:
>
> Here some more files that need to be moved:
>
> # CREDITS.txt - Where do we need them? For the distribution?
> For now I'd put them into the trunk/commons directory
> Thinking more about this, I propose to configure
> the assembly plugin for commons so that we can
> build distribution packages from there.
> # DESKTOP.INI - remains where it is
> # INSTALL.txt - move to trunk/commons
> # KEYS - move to trunk/commons
> # LICENSE.txt - move to trunk/commons
> # NOTICE.txt - move to trunk/commons
> # README.blocksmode.txt - remove it (outdated)
> # README.m10n.txt - leave it where it is
> # README.osgi.txt - remove it (outdated)
> # README.txt - move to trunk/commons
> # TO-SYNC-FROM-BRANCH.txt - leave it
> # announcement.xml - move to trunk/commons
According to http://www.apache.org/dev/apply-license.html
the LICENSE.txt and NOTICE.txt must located at the top-level
of the "distribution". What does that mean in our new setup?
Any attributions required by third-party products are
supposed to be in NOTICE.txt but we have them at the
bottom of CREDITS.txt
-David