Re: Final 2.2 release?
Carsten Ziegeler pisze: Grzegorz Kossakowski wrote: Reinhard Poetz pisze: It's right time for someone to explain what the hell WDW is? :-) :) Just try your favorite search engine - but as a hint, it's located in Florida... Ah, right :-) Thanks. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Final 2.2 release?
On Jan 29, 2008, at 4:22 PM, Reinhard Poetz wrote: Vadim Gritsenko wrote: On Jan 29, 2008, at 11:17 AM, Reinhard Poetz wrote: o pipeline-specific error handlers don't work But do you have a patent license for that? ;-) :-( http://yro.slashdot.org/yro/08/01/30/1321241.shtml Vadim
Re: Final 2.2 release?
Vadim Gritsenko wrote:
On Jan 29, 2008, at 4:22 PM, Reinhard Poetz wrote:
Vadim Gritsenko wrote:
On Jan 29, 2008, at 11:17 AM, Reinhard Poetz wrote:
o pipeline-specific error handlers don't work
But do you have a patent license for that? ;-) :-(
http://yro.slashdot.org/yro/08/01/30/1321241.shtml
LOL
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Final 2.2 release?
Hi, did you know that I bought one of those Grumpy shirts last time I visited WDW? So, I *have* to ask what the current plans for the long awaited final release of 2.2 is? Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Final 2.2 release?
Carsten Ziegeler pisze: Hi, did you know that I bought one of those Grumpy shirts last time I visited WDW? So, I *have* to ask what the current plans for the long awaited final release of 2.2 is? Hi Carsten, I think that 2.2 is ready for a final release. JIRA does not report any outstanding serious issues apart from this one: https://issues.apache.org/jira/browse/COCOON-2108 which seems to be fixed by Ralph in r609282[1]. It would be good if Ralph who reopened that issue could confirm his fix and close it. Apart from JIRA issues there was one very serious problem: lack of any documentation on Servlet Service Framework. I was working on writing docs some time ago and I will continue to do so in upcomming days so you can expect something complete really soon. To sum up, it's certainly right time to start preparing the release. [1] http://svn.apache.org/viewvc?rev=609282view=rev -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Final 2.2 release?
Carsten Ziegeler wrote:
Hi,
did you know that I bought one of those Grumpy shirts last time I
visited WDW? So, I *have* to ask what the current plans for the long
awaited final release of 2.2 is?
:-)
On my personal todo list only the creation of non-Maven-2-artifacts is missing.
I will also finish the integration test suite for Cocoon sitemaps next week
(since I need it for Micro-Cocoon).
So far I found two bugs:
o pipeline-specific error handlers don't work
o if you send a response code other than 200, the *first* response will
return 200 nevertheless
IMHO these are not blockers, but it would be nice if somebody could have a look
at it.
Anything else?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Final 2.2 release?
Reinhard Poetz pisze: Carsten Ziegeler wrote: Hi, did you know that I bought one of those Grumpy shirts last time I visited WDW? So, I *have* to ask what the current plans for the long awaited final release of 2.2 is? :-) It's right time for someone to explain what the hell WDW is? :-) On my personal todo list only the creation of non-Maven-2-artifacts is missing. I will also finish the integration test suite for Cocoon sitemaps next week (since I need it for Micro-Cocoon). So far I found two bugs: o pipeline-specific error handlers don't work o if you send a response code other than 200, the *first* response will return 200 nevertheless IMHO these are not blockers, but it would be nice if somebody could have a look at it. Ehkm, I would like to point out (remind?) that we have everything needed for independent release cycle of blocks and Cocoon's core so if issue is not really critical or a fix is already known it should never block a release. If someone comes with fix to issues above we will (hopefully) be able to easily cut a new release. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Final 2.2 release?
Vadim Gritsenko wrote:
On Jan 29, 2008, at 11:17 AM, Reinhard Poetz wrote:
o pipeline-specific error handlers don't work
Can you elaborate? As far as I can see all tests are passing fine
http://cocoon.zones.apache.org/demos/trunk/samples/core/errorhandling/
http://cocoon.zones.apache.org/demos/trunk/samples/core/errorhandling/exception/application?code=1
I tried this (see the comment inline):
map:pipelines
!-- error handling ~~~ --
map:pipeline
map:match pattern=error-handling/custom-error
map:act type=error-throwing/
map:generate src=sax-pipeline/simple.xml/
map:serialize type=xml/
/map:match
/map:pipeline
!-- doesn't work: when this per pipeline error handler is active,
it catches ALL errors and the per-sitemap error handler will never
be reached. --
map:pipeline
map:match
pattern=error-handling/custom-error-per-pipeline-error-handling
map:act type=error-throwing/
map:generate src=sax-pipeline/simple.xml/
map:serialize type=xml/
/map:match
map:handle-errors
map:generate src=error-handling/501.xml/
map:serialize type=xhtml status-code=501/
/map:handle-errors
/map:pipeline
map:handle-errors
map:select type=custom-exception
map:when test=not-found
map:generate src=error-handling/404.xml/
map:serialize type=xhtml status-code=404/
/map:when
map:when test=custom-exception
map:generate src=error-handling/500.xml/
map:serialize type=xhtml status-code=500/
/map:when
map:otherwise
map:generate src=error-handling/503.xml/
map:serialize type=xhtml status-code=503/
/map:otherwise
/map:select
/map:handle-errors
/map:pipelines
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Final 2.2 release?
On Jan 29, 2008, at 11:17 AM, Reinhard Poetz wrote: o pipeline-specific error handlers don't work Can you elaborate? As far as I can see all tests are passing fine http://cocoon.zones.apache.org/demos/trunk/samples/core/errorhandling/ http://cocoon.zones.apache.org/demos/trunk/samples/core/errorhandling/exception/application?code=1 Vadim
Re: Final 2.2 release?
Yes, I fixed 2108. If you are happy that the fix hasn't caused any other problems then I will close it. Grzegorz Kossakowski wrote: Carsten Ziegeler pisze: Hi, did you know that I bought one of those Grumpy shirts last time I visited WDW? So, I *have* to ask what the current plans for the long awaited final release of 2.2 is? Hi Carsten, I think that 2.2 is ready for a final release. JIRA does not report any outstanding serious issues apart from this one: https://issues.apache.org/jira/browse/COCOON-2108 which seems to be fixed by Ralph in r609282[1]. It would be good if Ralph who reopened that issue could confirm his fix and close it. Apart from JIRA issues there was one very serious problem: lack of any documentation on Servlet Service Framework. I was working on writing docs some time ago and I will continue to do so in upcomming days so you can expect something complete really soon. To sum up, it's certainly right time to start preparing the release. [1] http://svn.apache.org/viewvc?rev=609282view=rev
Re: Final 2.2 release?
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Carsten Ziegeler wrote: Hi, did you know that I bought one of those Grumpy shirts last time I visited WDW? So, I *have* to ask what the current plans for the long awaited final release of 2.2 is? :-) It's right time for someone to explain what the hell WDW is? :-) :) Just try your favorite search engine - but as a hint, it's located in Florida... Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Final 2.2 release?
Thanks for all the answers! So, lets just release now! Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Final 2.2 release?
Carsten Ziegeler wrote:
Thanks for all the answers!
So, lets just release now!
As it looks today, the chances are high that I will be able to start the release
process on Feb. 11th. If somebody else can do it earlier, please go ahead.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Non-Maven Cocoon 2.2 release
Ralph Goers wrote:
No. We could take advantage of http://maven.apache.org/ant-tasks.html to
create various ant scripts to do that. However, since I'm still not
sure what this supposed support for non-maven builds really looks like
it is hard to have a good answer to the question.
Yes, that's the question du jour. Since I use Maven 2 in all of my Cocoon
projects, it's not easy for me to give an answer.
Looking at other projects, e.g. Spring might help us. Spring provides two
different downloads: One contains all Spring libraries, Javadocs and general
documentation, the second additionally includes all libraries Spring depends on.
Note that this releases don't contain any samples (at least the last time I
looked into it.)
The situation for Cocoon is similar but not the same. We've been working hard to
break up the monolith and make blocks more independant. A Cocoon block is more
like a Spring sub project (e.g. Spring webflow). In practise this means that you
can add those blocks to your Cocoon app that you need. In difference to 2.1 you
can make this decision at deployment time and not at build time.
Those independant blocks also have the advantage that establish different
release cycles for each: If we want to release e.g. the template block, we only
have to release this one without having to care for all the other stuff.
The first question we have to answer is, whether we want to pass this advantage
to non-Maven users too. If yes, each block also has to become a seperatly
downloadable release unit which could contain the block library itself,
Javadocs, general documentation and even the related samples block.
As an alternative we can create one huge download that contains the most recent
versions of Cocoon core 2.2, the latest versions of all releaseable blocks and a
preconfigured Jetty instance that is able to run Cocoon. The downside of this
approach is that this will create a really huge file (+50 megabytes) which will
not be very appealing for a beginner to start with.
- o -
My proposal is that we create seperate download units for Cocoon core and all
releaseable blocks. That's a bit of work intially but thanks to Maven we already
have all necessary parts. The work will only consist of writing a script
that pulls together all those parts (jar, sources, javadocs, general docs), zip
it, create checksums and sign it. The final result is a Maven free zip, the 2
checksums and the PGP singatures of all those files. This could become part of
the usual release process.
In addition I propose that we create a samples download (jetty + preconfigured
webapp) and a getting-started download which is derived from the output of our
Maven 2 archetypes. These two artefacts will always be created when Cocoon core
is released.
If we follow this proposal I would appreciate any help very much. The work
mainly consist of writing the scripts (I'd prefer Groovy or shell scripts).
On my personal todo list this comes right after setting up integration tests for
trunk (working on this right now) and writing an initial integration tests for
the servlet service framework. When all three things are done I'm ready for the
final release.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: [2.2] Release?
Reinhard Poetz wrote: Carsten Ziegeler wrote: Regardless of the name, I think we should take a little bit more time and use the ApacheCon hackathon to prepare this first release and then release (or upload) right after the ApacheCon. Then let's release in the first week of July *whatever* we have by then. This should also be the starting signal for a time-based release cycle (see my other answer to this mail). :) Sorry to be a little pita here, but I will vote against a release in the first week of July *if* the situation with the samples is still the same. If this is fixed by then I'll be fine :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Release?
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Regardless of the name, I think we should take a little bit more time
and use the ApacheCon hackathon to prepare this first release and then
release (or upload) right after the ApacheCon.
Then let's release in the first week of July *whatever* we have by then. This
should also be the starting signal for a time-based release cycle (see my other
answer to this mail).
:) Sorry to be a little pita here, but I will vote against a release in
the first week of July *if* the situation with the samples is still the
same. If this is fixed by then I'll be fine :)
That's the point I want to make in my other mail: With this attitude we probably
wait forever to get something released as then it's July, holiday time and maybe
we won't even get 3 +1 votes of PMC members.
We have to break this vicious circle _now_ if we want to get quality feedback
from projects that try the migration.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: [2.2] Release?
On 6/19/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...:) Sorry to be a little pita here, but I will vote against a release in the first week of July *if* the situation with the samples is still the same... Which makes me think, once again, that we should focus the ApacheCon EU Hackathon on getting this release out of the door, including samples and whatever's needed for people to be able to use the release. -Bertrand
Re: [2.2] Release?
Reinhard Poetz wrote: That's the point I want to make in my other mail: With this attitude we probably wait forever to get something released as then it's July, holiday time and maybe we won't even get 3 +1 votes of PMC members. Now, currently I see only very few people here talking about a possible release. So it could be very hard to get 3 votes at all! We have to break this vicious circle _now_ if we want to get quality feedback from projects that try the migration. And this is where I disagree. We are developing 2.2 for many years now and if we provide a not-really-running milestone after three years of development, I'm not sure if this will really help. Anyway, we still have two weeks including the hackathon next week, so we should be able to fix the samples and all of us (you and me) will be happy! Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Release?
On Monday 19 June 2006 14:40, Carsten Ziegeler wrote: Reinhard Poetz wrote: Carsten Ziegeler wrote: Regardless of the name, I think we should take a little bit more time and use the ApacheCon hackathon to prepare this first release and then release (or upload) right after the ApacheCon. Then let's release in the first week of July *whatever* we have by then. This should also be the starting signal for a time-based release cycle (see my other answer to this mail). :) Sorry to be a little pita here, but I will vote against a release in the first week of July *if* the situation with the samples is still the same. If this is fixed by then I'll be fine :) Could the compromise be that the 'release' == 'alpha/beta/grokmake' with the README listing '* Examples a,b,c not working,' ?? Striving for perfection before action, is a paradox as perfection can only be obtained by fine-tuning the action. I would +1 a improved release every week. Small steps. Little to consider. Fast Forward. Done, Next!, Done! ... Anybody still around from the Cocoon 1.0 times ?? Cheers Niclas
Re: [2.2] Release?
Niclas Hedhman wrote: Could the compromise be that the 'release' == 'alpha/beta/grokmake' with the README listing '* Examples a,b,c not working,' ?? Ok, perhaps my wording was not the best :) Of course the samples are not working, but this is a hint that the technology used by the samples is not working and not the sample by itself. So releasing in this state means not only that samples are not working but also core functionality. And the biggest block here is the template block. Striving for perfection before action, is a paradox as perfection can only be obtained by fine-tuning the action. :) I would +1 a improved release every week. Small steps. Little to consider. Fast Forward. Done, Next!, Done! ... Anybody still around from the Cocoon 1.0 times ?? If we have fixed the starting problems mentioned above, then we can release every day if we want and incrementally fix things (though I'm concerned by the implications wrt. legal oversight etc.). So, let's just fix the worst things and release :) I'm currently looking into the template block... Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Release?
On Sunday 18 June 2006 12:10, Torsten Curdt wrote: /www/people.apache.org/maven-snapshot-repository (which is the same as the above) is the apache maven2 snaphot repository. Only releases(!!) may be deployed to /www/www.apache.org/dist/java-repository which is getting synchronized with ibiblio. But the problem is that /www/www.apache.org/dist/java-repository is a Maven1 (!) repository, and not Maven2... I asked about this a few days ago on repository@ but I think the mail drowned in the many commit mails presently being posted there. Cheers Niclas
Re: [2.2] Release?
On Sunday 18 June 2006 14:08, Niclas Hedhman wrote:
On Sunday 18 June 2006 12:10, Torsten Curdt wrote:
/www/people.apache.org/maven-snapshot-repository (which is the same as
the above) is the apache maven2 snaphot repository. Only releases(!!)
may be deployed to /www/www.apache.org/dist/java-repository which is
getting synchronized with ibiblio.
But the problem is that /www/www.apache.org/dist/java-repository is a
Maven1 (!) repository, and not Maven2...
Just found the answer on the [EMAIL PROTECTED] list.
/www/www.apache.org/dist/maven-repository/
I am pasting the README file from that directory;
-bash-2.05b$ cat /www/www.apache.org/dist/maven-repository/README.txt
http://www.apache.org/dist/maven-repository
This is a Maven 2.0+ repository for deployment of official Apache releases.
DO NOT INCLUDE THIS IN YOUR PROJECT REPOSITORY LIST - USE A MIRROR
Please follow these rules when deploying to this repository:
- only deploy releases voted on by the PMC
- sign all artifacts and POMs (currently, this is a manual step)
- never deploy snapshots or development releases to this repository
- ensure that if a release is deleted from /dist/, it is removed from here
completely also (excluding archiving)
- no artifacts are allowed from projects under incubation
- make sure you have your maven settings correctly set to make directories
group writeable.
This repository is not currently synced automatically to Ibiblio and the Maven
mirrors. Please request this at dev@maven.apache.org after deploying here.
This repository is archived to
http://archive.apache.org/dist/maven-repository/
and synced to iBiblio with a no-delete option, so things can be deleted from
apache and still available through ibiblio
IMPORTANT:
Permissions should be
775 for directories
644 for files
Which can be done in Maven 2 settings.xml with
server
idapache.releases/id
directoryPermissions775/directoryPermissions
filePermissions644/filePermissions
/server
server
idapache.snapshots/id
directoryPermissions775/directoryPermissions
filePermissions644/filePermissions
/server
Due to a bug in Maven (http://jira.codehaus.org/browse/MDEPLOY-28)
maven-metadata.* files need to have 664 permissions
Run these commands to fix the permissions of your files after deployment:
snapshots:
find /www/cvs.apache.org/maven-snapshot-repository ! -perm 775 -type d -user
${USER} -exec chmod 775 {} \;
find /www/cvs.apache.org/maven-snapshot-repository ! -perm 664 -iname
maven-metadata.xml* -user ${USER} -exec chmod 664 {} \;
find /www/cvs.apache.org/maven-snapshot-repository ! -perm 644 ! -iname
maven-metadata.xml* -type f -user ${USER} -exec chmod 644 {} \;
releases:
find /www/www.apache.org/dist/maven-repository ! -perm 775 -type d -user
${USER} -exec chmod 775 {} \;
find /www/www.apache.org/dist/maven-repository ! -perm 664 -iname
maven-metadata.xml* -user ${USER} -exec chmod 664 {} \;
find /www/www.apache.org/dist/maven-repository ! -perm 644 ! -iname
maven-metadata.xml* -type f -user ${USER} -exec chmod 644 {} \;
Re: [2.2] Release?
But the problem is that /www/www.apache.org/dist/java-repository is a Maven1 (!) repository, and not Maven2... ups... /www/www.apache.org/dist/maven-repository it is cheers -- Torsten
Re: [2.2] Release?
Carsten Ziegeler wrote:
Regardless of the name, I think we should take a little bit more time
and use the ApacheCon hackathon to prepare this first release and then
release (or upload) right after the ApacheCon.
Then let's release in the first week of July *whatever* we have by then. This
should also be the starting signal for a time-based release cycle (see my other
answer to this mail).
--
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: [2.2] Release?
Two final question: Currently we deploy our released artifacts to scpexe://people.apache.org/x1/www/cvs.apache.org/maven-snapshot-repository. Is this the expected location to get our artifacts published to the official Maven repos? /www/people.apache.org/maven-snapshot-repository (which is the same as the above) is the apache maven2 snaphot repository. Only releases(!!) may be deployed to /www/www.apache.org/dist/java-repository which is getting synchronized with ibiblio. If yes, what's the next step to get our artifacts published by the Maven folks? Snaphots: Nothing. Just declare the apache snapshot repo in the pom(s) ...or the settings.xml Releases: Use the above location and send a ping to the maven dev list. Most likely Carlos will the initiate a sync. Due to some maven infrastructure work (related to the recent codehaus outage) this is currently not working automatically. cheers -- Torsten
Re: [2.2] Release?
Ralph Goers wrote: I have no problem with this release as a first step, but I'd hesitate to even call it 2.2M1. OTOH, if I had an idea of what our subsequent milestones are this might make more sense to me. Good point! Now, if you something label milestone or beta people have a specific expectation. I don't think we meet these expectations, so I would suggest calling this release alpha. Regardless of the name, I think we should take a little bit more time and use the ApacheCon hackathon to prepare this first release and then release (or upload) right after the ApacheCon. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Release?
Jorg Heymans wrote:
Reinhard Poetz wrote:
to release. This way the release plugin should work for us as expected
and we don't have to maniupulate any POMs directly. WDOT?
Well, *theoretically* it __should__ yes.
Note that I don't want to sound too negative here, i really hope you can
make the plugin work for you with this release. It is very possible that
my experiments with it a few weeks ago were too demanding or
restrictive. In other words, prove me wrong ;) (and document the process
so we can all do releases afterwards)
Today I've created a reduced version of trunk that only containd the modules I
named in the first mail of this thread. Then I've imported them into a local SVN
repo.
After that I've been able to run mvn release:prepare and mvn release:perform
without any problems.
I noticed that if you do a bulk release, your modules are tagged hierarchally
instead of getting a subdirectory the tags directory for each module.
A bulk release also releases all the modules only POMs which isn't necessary
most of the time.
I guess that the best way of doing a release is doing it for each module
separatly as Jorg suggested. When trying this I had problems with releasing a
POM artifact as the -N parameter doesn't seem to work here. The only solution
that I found was commenting all the modules.
As we've wanted separate release cycles for our blocks for ages, I don't think
following the release a single module-strategy is a real problem - only the
first release takes little more time.
- o -
Here my findings so that we (I) have something to lookup when actually doing the
release:
- When doing the release we should release each module separatly.
- When releasing a POM comment all modules.
- When releasing a module that has a parent artifact, check whether an already
released POM module fits your needs and manually set the version of the
parent module to this version.
- o -
Two final question: Currently we deploy our released artifacts to
scpexe://people.apache.org/x1/www/cvs.apache.org/maven-snapshot-repository. Is
this the expected location to get our artifacts published to the official Maven
repos?
If yes, what's the next step to get our artifacts published by the Maven folks?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: [2.2] Release?
On Thursday 15 June 2006 13:44, Jorg Heymans wrote: The poms are correctly configured for the release plugin AFAIK, you should just be able to run the goals and get something going. Ok, cool. Please note that we don't want to release all blocks, so you'll have to do a non-recursive release of the root pom first, then core, and then all other blocks separately in their normal dependency order. IMHO, that is not very clever, just creates a lot of work for nothing. If something is not official I normally remove the entry from the modules, and as things get ready, add them in. Cheers Niclas
Re: [2.2] Release?
Niclas Hedhman wrote:
On Thursday 15 June 2006 13:44, Jorg Heymans wrote:
The poms are correctly configured for the release plugin AFAIK, you
should just be able to run the goals and get something going.
Ok, cool.
Please note that we don't want to release all blocks, so you'll have to
do a non-recursive release of the root pom first, then core, and then
all other blocks separately in their normal dependency order.
IMHO, that is not very clever, just creates a lot of work for nothing. If
something is not official I normally remove the entry from the modules,
and as things get ready, add them in.
The problem is that it *is* official but not ready to release. If we wait for
all 170+ modules, I expect a first C22 release in 2008 ;-)
But your remark makes me think that we should have a code freeze for let's say 3
days. At this time we comment all modules that we don't want to release. This
way the release plugin should work for us as expected and we don't have to
maniupulate any POMs directly. WDOT?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: [2.2] Release?
Reinhard Poetz wrote: to release. This way the release plugin should work for us as expected and we don't have to maniupulate any POMs directly. WDOT? Well, *theoretically* it __should__ yes. Note that I don't want to sound too negative here, i really hope you can make the plugin work for you with this release. It is very possible that my experiments with it a few weeks ago were too demanding or restrictive. In other words, prove me wrong ;) (and document the process so we can all do releases afterwards) Regards Jorg
Re: [2.2] Release?
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
AFAICT there is not much work left to get a first beta release out of the door.
The only issue that I know of is that the reloading classloader doesn't work
which would be important to get it fixed. Does somebody have time to look into
this problem?
Then we could release
- cocoon-core
- cocoon-bootstrap
- cocoon-template
- cocoon-deployer-plugin
- cocoon-22-archetype-webapp
- cocoon-22-archetype-block
I would like to see those modules released *before* the ApacheCon. Does anything
speak a release on Monday (June, 19th)?
Yes, most samples are currently not working and this includes the
template block
yes, I looked briefly into the issue but haven't found the cause. IIUC the list
cocoon.parameters contains the values instead of the names.
- I wrote an email last week (or the week before), but
got no reply for the problem at hand.
So, imho we should try to get most samples working - it's not necessary
that all samples work, but there should be more working samples than
failing ones. So as long as this is the case, I'm -1 on a release.
which samples are failing?
In addition, I would like to have a support for paranoid classloasding
in the deployer: controlled by a property the deploy could rewrite my
web.xml and add the paranoid servlet, listener and filters. Now, I could
come up with the code for rewriting the web.xml, but have no clue how
and where to add this in the deploy code.
yes I agree but we shouldn't delay a release just because of this missing
feature.
I will give more detailed advise about where you can add your code ASAP.
Finally :) how to we do the actual release? We have to take care of
legal aspects as well, like adding all licenses of the uses dependencies
etc.
I don't think that we should only provide Maven artifacts for our first release,
nothing more. Getting out a perfect sample distribution (which only has demo
purpose - people should *never* use it as the base for their own projects) could
take ages ... and I don't want to wait for it.
--
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: [2.2] Release?
Reinhard Poetz wrote: So, imho we should try to get most samples working - it's not necessary that all samples work, but there should be more working samples than failing ones. So as long as this is the case, I'm -1 on a release. which samples are failing? Just try some of the core module; most of them failed for me (I tested it two weeks ago, so I can't remember which ones exactly failed). In addition, I would like to have a support for paranoid classloasding in the deployer: controlled by a property the deploy could rewrite my web.xml and add the paranoid servlet, listener and filters. Now, I could come up with the code for rewriting the web.xml, but have no clue how and where to add this in the deploy code. yes I agree but we shouldn't delay a release just because of this missing feature. Oh, yes, I agree with that as well. It's just nice to have but not require. I will give more detailed advise about where you can add your code ASAP. Great! I don't think that we should only provide Maven artifacts for our first release, nothing more. Getting out a perfect sample distribution (which only has demo purpose - people should *never* use it as the base for their own projects) could take ages ... and I don't want to wait for it. So this means we release some jars and the plugins? I think one important goal of this release should be to get feedback, so we should try to make the barrier to test 2.2 as low as possible while puttint as less effort as possible into it. I'm not sure if just releasing maven artifacts is enough here. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Release?
Carsten Ziegeler wrote:
So this means we release some jars and the plugins? I think one
important goal of this
release should be to get feedback, so we should try to make the barrier
to test 2.2 as low as possible while puttint as less effort as possible
into it. I'm not sure if just releasing maven artifacts is enough here.
Which kind of feedback do you want?
I think we need feedback from people that migrate their projects to C22. I don't
believe it makes sense to use C22 without a Maven 2 based build. And, as I said
in many previous mails, a distribution that can be compared to a C21 release has
its only purpose in being a demo application, nothing more.
So yes, I think that the named artifacts are enough for a first release.
Releasing forms, fop, javaflow, apples, batik, mail and portal should be the
next step so that more people can start to experiment with a migration. During
this phase we should fix their samples too.
Finally, we don't have to provide *one* release that contains all our 50+ blocks
anymore. Luckily we can release iterativly whenever something is ready :-)
--
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: [2.2] Release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Jun 2006, Reinhard Poetz wrote: Date: Wed, 14 Jun 2006 14:29:41 +0200 From: Reinhard Poetz [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [2.2] Release? Carsten Ziegeler wrote: So this means we release some jars and the plugins? I think one important goal of this release should be to get feedback, so we should try to make the barrier to test 2.2 as low as possible while puttint as less effort as possible into it. I'm not sure if just releasing maven artifacts is enough here. Which kind of feedback do you want? I think we need feedback from people that migrate their projects to C22. I don't believe it makes sense to use C22 without a Maven 2 based build. And, as I said in many previous mails, a distribution that can be compared to a C21 release has its only purpose in being a demo application, nothing more. So yes, I think that the named artifacts are enough for a first release. Releasing forms, fop, javaflow, apples, batik, mail and portal should be the next step so that more people can start to experiment with a migration. During this phase we should fix their samples too. And don't forget the archetypes and plugins. Finally, we don't have to provide *one* release that contains all our 50+ blocks anymore. Luckily we can release iterativly whenever something is ready :-) - -- 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.3 (GNU/Linux) iD8DBQFEkAU5LNdJvZjjVZARArn7AJ4oynf6LGHUCpTTW1oNlxHsqIEc+QCdHHeB 7c7jbp8hLM782mo0jpowRd8= =kjmi -END PGP SIGNATURE-
Re: [2.2] Release?
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 14 Jun 2006, Reinhard Poetz wrote:
Date: Wed, 14 Jun 2006 14:29:41 +0200
From: Reinhard Poetz [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [2.2] Release?
Carsten Ziegeler wrote:
So this means we release some jars and the plugins? I think one
important goal of this
release should be to get feedback, so we should try to make the barrier
to test 2.2 as low as possible while puttint as less effort as possible
into it. I'm not sure if just releasing maven artifacts is enough here.
Which kind of feedback do you want?
I think we need feedback from people that migrate their projects to
C22. I don't believe it makes sense to use C22 without a Maven 2 based
build. And, as I said in many previous mails, a distribution that can
be compared to a C21 release has its only purpose in being a demo
application, nothing more.
So yes, I think that the named artifacts are enough for a first
release. Releasing forms, fop, javaflow, apples, batik, mail and
portal should be the next step so that more people can start to
experiment with a migration. During this phase we should fix their
samples too.
And don't forget the archetypes and plugins.
both already work (for me). I will write documentation for them over the next
days.
--
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: [2.2] Release?
Reinhard Poetz wrote: Carsten Ziegeler wrote: So this means we release some jars and the plugins? I think one important goal of this release should be to get feedback, so we should try to make the barrier to test 2.2 as low as possible while puttint as less effort as possible into it. I'm not sure if just releasing maven artifacts is enough here. Which kind of feedback do you want? I think we need feedback from people that migrate their projects to C22. I don't believe it makes sense to use C22 without a Maven 2 based build. And, as I said in many previous mails, a distribution that can be compared to a C21 release has its only purpose in being a demo application, nothing more. I suspect that Carsten didn't understand what you were saying as this sentence, I don't think that we should only provide Maven artifacts for our first release, nothing more. would lead one to believe that you do NOT want to ship anything regarding maven 2. So yes, I think that the named artifacts are enough for a first release. Releasing forms, fop, javaflow, apples, batik, mail and portal should be the next step so that more people can start to experiment with a migration. During this phase we should fix their samples too. Finally, we don't have to provide *one* release that contains all our 50+ blocks anymore. Luckily we can release iterativly whenever something is ready :-) I have no problem with this release as a first step, but I'd hesitate to even call it 2.2M1. OTOH, if I had an idea of what our subsequent milestones are this might make more sense to me. Ralph
Re: [2.2] Release?
Reinhard Poetz wrote: - cocoon-core - cocoon-bootstrap - cocoon-template - cocoon-deployer-plugin - cocoon-22-archetype-webapp - cocoon-22-archetype-block +1 (I won't be able to help out though as i'm on holiday) Jorg
Re: [2.2] Release?
Carsten Ziegeler wrote: Finally :) how to we do the actual release? We have to take care of legal aspects as well, like adding all licenses of the uses dependencies etc. core has a dependency on the licenses block, does that cover your legal requirements ? As to how to actually do the release, unsure. If it was me doing it next week i would do something like this for the maven part of things: 1. change the poms manually to reflect the correct version number of the core (eg 2.2.0M1 or whatever). Also change the version number of each module itself to be non-snapshot (eg 1.0-SNAPSHOT becomes 1.0). 2. tag 3. mvn source:jar javadoc:jar repository:bundle-create for each module we're releasing, don't forget the module poms 4. bump the version numbers for all modules, 1.0.0 becomes 1.0.1-SNAPSHOT or 1.1.0-SNAPSHOT etc. Reset the version number of core back to 2.2.0-SNAPSHOT. 4. create a jira issue for the jars to be uploaded, described here http://maven.apache.org/guides/mini/guide-ibiblio-upload.html HTH Jorg
Re: [2.2] Release?
On Thursday 15 June 2006 04:39, Jorg Heymans wrote: Carsten Ziegeler wrote: Finally :) how to we do the actual release? We have to take care of legal aspects as well, like adding all licenses of the uses dependencies etc. core has a dependency on the licenses block, does that cover your legal requirements ? As to how to actually do the release, unsure. If it was me doing it next week i would do something like this for the maven part of things: 1. change the poms manually to reflect the correct version number of the core (eg 2.2.0M1 or whatever). Also change the version number of each module itself to be non-snapshot (eg 1.0-SNAPSHOT becomes 1.0). 2. tag 3. mvn source:jar javadoc:jar repository:bundle-create for each module we're releasing, don't forget the module poms 4. bump the version numbers for all modules, 1.0.0 becomes 1.0.1-SNAPSHOT or 1.1.0-SNAPSHOT etc. Reset the version number of core back to 2.2.0-SNAPSHOT. 4. create a jira issue for the jars to be uploaded, described here http://maven.apache.org/guides/mini/guide-ibiblio-upload.html I think that Maven's Release plugin is expected to handle all of that in one go. mvn release:prepare mvn release:perform However, the latest Release plugin (beta4) has regressed and in my cases working less well than the beta3 (which I would recommend). What is needed is that the POM(s) are properly configured for the Release process. At least distributionManagement, scm and the configuration for the release plugin must be correctly specified. Possibly a repository as well. I'll give it a go later today and see what is missing and try to figure out what should go in there... Cheers Niclas
Re: [2.2] Release?
On Thursday 15 June 2006 12:33, Niclas Hedhman wrote: I think that Maven's Release plugin is expected to handle all of that in one go. Let me clarify that; Provided that there are no SNAPSHOT dependencies... Cheers Niclas
Re: [2.2] Release?
Niclas Hedhman wrote: I think that Maven's Release plugin is expected to handle all of that in one go. Yep I know. I experimented with it a few weeks ago but found it quite difficult to get it working for our usecase. mvn release:prepare mvn release:perform ... I'll give it a go later today and see what is missing and try to figure out what should go in there... The poms are correctly configured for the release plugin AFAIK, you should just be able to run the goals and get something going. Please note that we don't want to release all blocks, so you'll have to do a non-recursive release of the root pom first, then core, and then all other blocks separately in their normal dependency order. Jorg
Re: [2.2] Release?
Reinhard Poetz wrote: AFAICT there is not much work left to get a first beta release out of the door. As far as naming goes, since 2.1m1 we adopted 'milestone' naming, so it should be 2.2m1. Vadim
Re: [2.2] Release?
Reinhard Poetz wrote: AFAICT there is not much work left to get a first beta release out of the door. The only issue that I know of is that the reloading classloader doesn't work which would be important to get it fixed. Does somebody have time to look into this problem? Then we could release - cocoon-core - cocoon-bootstrap - cocoon-template - cocoon-deployer-plugin - cocoon-22-archetype-webapp - cocoon-22-archetype-block I would like to see those modules released *before* the ApacheCon. Does anything speak a release on Monday (June, 19th)? Yes, most samples are currently not working and this includes the template block - I wrote an email last week (or the week before), but got no reply for the problem at hand. So, imho we should try to get most samples working - it's not necessary that all samples work, but there should be more working samples than failing ones. So as long as this is the case, I'm -1 on a release. In addition, I would like to have a support for paranoid classloasding in the deployer: controlled by a property the deploy could rewrite my web.xml and add the paranoid servlet, listener and filters. Now, I could come up with the code for rewriting the web.xml, but have no clue how and where to add this in the deploy code. Finally :) how to we do the actual release? We have to take care of legal aspects as well, like adding all licenses of the uses dependencies etc. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Release?
Hi, AFAICT there is not much work left to get a first beta release out of the door. [...] I would like to see those modules released *before* the ApacheCon. Does anything speak a release on Monday (June, 19th)? It would be great to have a milestone release (or something like that) as soon as possible, as it might give some people the ability to give it a test-drive in a 'professional' (means use it in your daily work) environment. It's always easier to argue to take a milestone release than an svn-snapshot. -- * best regards * Jens Maukisch
[2.2] Release?
AFAICT there is not much work left to get a first beta release out of the door.
The only issue that I know of is that the reloading classloader doesn't work
which would be important to get it fixed. Does somebody have time to look into
this problem?
Then we could release
- cocoon-core
- cocoon-bootstrap
- cocoon-template
- cocoon-deployer-plugin
- cocoon-22-archetype-webapp
- cocoon-22-archetype-block
I would like to see those modules released *before* the ApacheCon. Does anything
speak a release on Monday (June, 19th)?
--
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
What does a Cocoon 2.2 release consist of?
Jorg Heymans wrote:
Ralph Goers wrote:
0. Download and install maven version 2.0.4 or later.
1. Create a pom.xml listing the appropriate Cocoon blocks you will be
using. The pom.xml files for all Cocoon blocks specify their
dependencies so other blocks will also be included as required.
2. Create a normal web application structure. In the WEB-INF directory
create an xconf subdirectory and a configuration file to contain all
your application specific configuration items which are not
automatically provided by the included blocks. Sitemap components
should also be configured there.
3. Create the sitemaps necessary for your application.
4. Run maven war:exploded. This will create the cocoon web
application. It will automatically invoke the Cocoon block plugin to
integrate the required Cocoon blocks into your web application.
WDOT?
steps 1..3 can be done in an archetype to make things even easier. The
root pom could contain all blocks commented out, initially the user
would just uncomment the ones he needs - just to get things working
initially. We could precreate the xconf dirs and put some examples there
on how to get things done.
Note that archetypes were suffering from several pesky limitations a few
months ago, i think they're due for another round of evaluation now.
Other than that i fully agree with your email, it's how things were
intented to work more or less. Reinhard's block deployer has never been
far off achieving what you describe here.
I wanted to discuss this some weeks ago but IIRC I didn't get any answers.
Jorg's questions makes me think about it again. What does a Cocoon 2.2 release
consist of?
IIUC a Cocoon 2.2 release is providing artifacts in public Maven 2 repositories.
This is
- cocoon-core
- blocks (for the first we should only release forms and template - and maybe
pdf, apples, mail and javaflow)
- deployer-core and deployer-plugin
- an archetype to start a Cocoon project
Additionally we can provide a cocoon-demo.zip that contains web application that
is created with the cocoon-webapp module but this is only a demo and should
*not* be used by people to start their projects.
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: What does a Cocoon 2.2 release consist of?
Reinhard Poetz wrote: I wanted to discuss this some weeks ago but IIRC I didn't get any answers. Jorg's questions makes me think about it again. What does a Cocoon 2.2 release consist of? IIUC a Cocoon 2.2 release is providing artifacts in public Maven 2 repositories. This is - cocoon-core - blocks (for the first we should only release forms and template - and maybe pdf, apples, mail and javaflow) - deployer-core and deployer-plugin - an archetype to start a Cocoon project Additionally we can provide a cocoon-demo.zip that contains web application that is created with the cocoon-webapp module but this is only a demo and should *not* be used by people to start their projects. WDOT? I think for a first release this is fine, we can add/release more blocks independently afterwards. As important as what the release should consist of is what the release should not contain. Imho we should remove all OSGi related stuff from the release to not confuse users. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: What does a Cocoon 2.2 release consist of?
Carsten Ziegeler wrote:
As important as what the release should consist of is what the release
should not contain. Imho we should remove all OSGi related stuff from
the release to not confuse users.
I think this causes a lot of work without a benefit. As you said some time ago,
user don't look into the internals of jars, they just want to use them.
--
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: What does a Cocoon 2.2 release consist of?
Reinhard Poetz wrote: Carsten Ziegeler wrote: As important as what the release should consist of is what the release should not contain. Imho we should remove all OSGi related stuff from the release to not confuse users. I think this causes a lot of work without a benefit. As you said some time ago, user don't look into the internals of jars, they just want to use them. :) - As long as this is hidden in a jar, I'm fine. But what about configuration files like wiring.xml lying in the root directory? And I don't want to ship OSGi related jars (I know with maven we don't technically ship them). Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: What does a Cocoon 2.2 release consist of?
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
As important as what the release should consist of is what the release
should not contain. Imho we should remove all OSGi related stuff from
the release to not confuse users.
I think this causes a lot of work without a benefit. As you said some time ago,
user don't look into the internals of jars, they just want to use them.
:) - As long as this is hidden in a jar, I'm fine. But what about
configuration files
like wiring.xml lying in the root directory? And I don't want to ship
OSGi related jars (I know with maven we don't technically ship them).
wiring.xml can be deleted and the files in META-INF are not added to the JAR.
Anything else?
--
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: What does a Cocoon 2.2 release consist of?
Reinhard Poetz wrote: wiring.xml can be deleted and the files in META-INF are not added to the JAR. Anything else? The OSGi jars. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: What does a Cocoon 2.2 release consist of?
Reinhard Poetz wrote: IIUC a Cocoon 2.2 release is providing artifacts in public Maven 2 repositories. This is - cocoon-core - blocks (for the first we should only release forms and template - and maybe pdf, apples, mail and javaflow) - deployer-core and deployer-plugin - an archetype to start a Cocoon project +1 (but the archetype only when it actually has proven to be useable again) Additionally we can provide a cocoon-demo.zip that contains web application that is created with the cocoon-webapp module but this is only a demo and should *not* be used by people to start their projects. Agreed. Note that we don't even need to automate its creation at this point, just zip/tar some stuff up manually and get it out there. Regards Jorg
Re: What does a Cocoon 2.2 release consist of?
Carsten Ziegeler skrev: Reinhard Poetz wrote: Carsten Ziegeler wrote: As important as what the release should consist of is what the release should not contain. Imho we should remove all OSGi related stuff from the release to not confuse users. I think this causes a lot of work without a benefit. As you said some time ago, user don't look into the internals of jars, they just want to use them. :) - As long as this is hidden in a jar, I'm fine. But what about configuration files like wiring.xml lying in the root directory? And I don't want to ship OSGi related jars (I know with maven we don't technically ship them). All OSGi dependencies in cocoon-core are in o.a.c.core.osgi, so it is just to filter away that directory and not depending on the OSGi api jars. This can probably be done by using the profile concept in M2. Now, the two OSGi API jars are together less than 150kB, so it is questionable if it is worthwhile to remove them. /Daniel
Re: What does a Cocoon 2.2 release consist of?
Daniel Fagerstrom wrote: Carsten Ziegeler skrev: Reinhard Poetz wrote: Carsten Ziegeler wrote: As important as what the release should consist of is what the release should not contain. Imho we should remove all OSGi related stuff from the release to not confuse users. I think this causes a lot of work without a benefit. As you said some time ago, user don't look into the internals of jars, they just want to use them. :) - As long as this is hidden in a jar, I'm fine. But what about configuration files like wiring.xml lying in the root directory? And I don't want to ship OSGi related jars (I know with maven we don't technically ship them). All OSGi dependencies in cocoon-core are in o.a.c.core.osgi, so it is just to filter away that directory and not depending on the OSGi api jars. This can probably be done by using the profile concept in M2. Now, the two OSGi API jars are together less than 150kB, so it is questionable if it is worthwhile to remove them. I don't see a problem with building them. We can simply not deploy them to a maven repository if we don't want them distributed. /Daniel
