Re: cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null])
Jean-Baptiste Quenot wrote:
> * Marc Portier:
>
>> Anyways, this whole process of finding out what and how kind of
>> convinced me that we can in fact revert the change. (and not add
>> an attribute)
>
> That is the simple way.
It's called an optimum: achieving the desired goal with the least cost
("Perfection is achieved not when...")
> But ending up with empty tags for all
> widgets having the null value is not satisfactory.
You're barking up the wrong three.
If you think optional text-nodes in XML-elements are garbage, you should
turn to the w3c to get the recommendation fixed.
Removing the tags (and thus their attributes) just because you're
unhappy with empty text-nodes is ridiculous.
> And this
> also means that every convertor must check null *and* empty
> string. This also means that if you turn off leniency in the
> FormattingDateConvertor with lenient="false" attribute, you're
> SOL.
>
Sorry, I (again) can't find any valid argumentation in the above.
The current 'fix' shows all the signs of bad SOC:
(repeating myself now)
- it is not the responsibility of the 'save' to solve an issue occurring
after 'load' (note that the binding doesn't need to be used in both ways)
- it is is not the responsibility of the binding to solve converting
issues, there is a mechanism to delegate to convertors, if those need to
interpret "" as null, then they should just do that. If they can't due
to some flaw in the design, then some fix is needed there.
So frankly: All this stress on these false arguments, is just piling up
as more 'bad SOC'-evidence.
Badly enough applying the 'fix' to the wrong place also made it break.
> Anyway, let's close the discussion... I won't take the time to add
> the knob because
dude, currently this is not about "who" and "when" is doing things,
as Antonio's remark is making clear: this is about "what" to do (and
dare I still hope to get through: "what-not" to do)
As I see it: we need to come to an agreement/conclusion on this to avoid
a silly cvs-commit war.
That is why I opened the discussion, closing it without an outcome is
'not satisfactory'.
I'ld hate to see calling a vote over this just because we fail to see
reason.
> I don't use this binding API anymore.
(...)
> If someone shows interest we can always add it later.
In case you didn't notice: "myself" is showing interest "now"
I'ld like to revert the fix so things are back to normal in the upcoming
2.1.10 release.
-marc= (clearly running out of 2MP's)
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Re: [Vote] Java 5 as minimum JDK requirement
On 8/10/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: ...There are many new features in Java 5 which make the life of developers easier... IMHO most of the Java 5 features are syntactic sugar (generics, enums, etc.) which make little difference to the final product, they are "just" convenience for code writers. The one feature that could make an actual difference would be the use of annotations, to generate code or configs, for automatic documentation, etc. Considering Jorg's points, we might want to wait for a compelling reason to require Java 5, which might be some creative use of annotations. -Bertrand
Re: [Vote] Java 5 as minimum JDK requirement
sorry for answering to the wrong mail. I'veresent it to the right one now.
--
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: [Vote] Java 5 as minimum JDK requirement
Joerg Heinicke wrote:
On 08.08.2006 18:47, Jorg Heymans wrote:
As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.
-0, because this means eliminating cocoon 2.2 on "older" application
servers eg weblogic 8.1.
Frankly, I don't see the point in upgrading unless there's a killer
feature in 1.5 that
1) we are likely to use and implement in the near future (2006) and,
2) will improve cocoon by a significant margin.
I second this, but vote even -1. I wonder why a framework should set
such high requirements. Have a look on spring. They have a Java 1.3 as
minimum requirement and only need Java 5 for special features.
IMO we should do it in a similar manner and not set the general
requirement to Java 5.
I've been thinking about your reasoning some time and believe you're right,
there is no killer argument that makes it impossible to continue the development
of Cocoon. There are many new features in Java 5 which make the life of
developers easier and as Java 5 was released almost 2 years ago I and many other
people on this list believe that's long enough. Additionally there is no
existing user base.
As Vadim pointed out that this is our _framework developer_ point of view that
might not reflect the community as a whole. He proposed to poll [EMAIL PROTECTED]
which I will do today.
I will keep the vote open till next week so that you can consider the outcome of
the poll. Having said this I want to stress that there is no pressure to change
your opinion because of the poll in any way.
--
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: [Vote] Java 5 as minimum JDK requirement
Jorg Heymans wrote:
Reinhard Poetz wrote:
As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.
-0, because this means eliminating cocoon 2.2 on "older" application
servers eg weblogic 8.1.
Frankly, I don't see the point in upgrading unless there's a killer
feature in 1.5 that
1) we are likely to use and implement in the near future (2006) and,
2) will improve cocoon by a significant margin.
I've been thinking about your reasoning some time and believe you're right,
there is no killer argument that makes it impossible to continue the development
of Cocoon. There are many new features in Java 5 which make the life of
developers easier and as Java 5 was released almost 2 years ago I and many other
people on this list believe that's long enough. Additionally there is no
existing user base.
As Vadim pointed out that this is our _framework developer_ point of view that
might not reflect the community as a whole. He proposed to poll [EMAIL PROTECTED]
which I will do today.
I will keep the vote open till next week so that you can consider the outcome of
the poll. Having said this I want to stress that there is no pressure to change
your opinion because of the poll in any way.
--
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: cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null])
Jean-Baptiste Quenot escribió: * Marc Portier: Anyways, this whole process of finding out what and how kind of convinced me that we can in fact revert the change. (and not add an attribute) That is the simple way. But ending up with empty tags for all widgets having the null value is not satisfactory. And this also means that every convertor must check null *and* empty string. This also means that if you turn off leniency in the FormattingDateConvertor with lenient="false" attribute, you're SOL. Anyway, let's close the discussion... I won't take the time to add the knob because I don't use this binding API anymore. If someone shows interest we can always add it later. Would you provide a final decision as a issue comment? I should help the next person trying to fix the issue. Best Regards, Antonio Gallardo.
Re: Bug# 33462
Hi Tricia, Would you provide a patch? I will be glad to apply it ASAP. BTW, we migrated to jira, the bug link now is http://issues.apache.org/jira/browse/COCOON-1438 feel free to update it as needed. Best Regards, Antonio Gallardo. Tricia Williams escribió: This bug was reported February 9, 2005 [MAIL] Weird Encoding problem with SendMailAction. I have found similar behavior in another component. I have a flowscript, which uses the cocoon.redirectTo action to redirect to a url outside the pipeline. Similarly the form correctly delivers the form content as UTF-8. It seems somewhere between the redirectTo and the service which handles the url, the parameter encoding is made to be incorrect. I can send the url directly and it will work just fine returning the correct character-encoding. I can apply the same workaround given in the bug description, encoding the parameter as ISO-8859-1. After this change the response from the redirectTo will suddenly work as expected.
Bug# 33462
This bug was reported February 9, 2005 [MAIL] Weird Encoding problem with SendMailAction. I have found similar behavior in another component. I have a flowscript, which uses the cocoon.redirectTo action to redirect to a url outside the pipeline. Similarly the form correctly delivers the form content as UTF-8. It seems somewhere between the redirectTo and the service which handles the url, the parameter encoding is made to be incorrect. I can send the url directly and it will work just fine returning the correct character-encoding. I can apply the same workaround given in the bug description, encoding the parameter as ISO-8859-1. After this change the response from the redirectTo will suddenly work as expected.
Re: Voting policies
Ralph Goers wrote: > Now we are getting nit-picky. This page lists three categories; > procedural, code modification and package releases. Quite frankly, I > don't think this vote has much to do with any of these because: > a) procedural to me is a process - such as switching from ant to maven. > One could argue from a warped point of view that changing a dependency > fits in this category. > b) code modification - no code is actually being modified by changing a > dependency. (At least yet). This "b" is the closest category, i reckon. > c) package releases - well, it is pretty obvious that this doesn't fit. > > So to be honest, I think this is something the PMC has to decide which > process to follow. Yes. We need guidelines so that we can handle each situation without needing to make up ad hoc policies. > Having said that, I'd probably lean toward the more restrictive view > just to be fair. > > Ralph > > Bertrand Delacretaz wrote: > > > >Which is the case, quoting http://www.apache.org/foundation/voting.html: > > > >"Votes on Code Modification > > > >For code-modification votes, +1 votes are in favour of the proposal, > >but -1 votes are vetos and kill the proposal dead until all vetoers > >withdraw their -1 votes." I reckon that Joerg did the perfect thing. He felt strongly enough to vote -1, and then provided an alternative. It takes a lot of guts to vote -1 ... thanks. If we think he is wrong then challenge his veto. Otherwise go back to the drawing board and come up with an alternative proposal to vote on. -David
Re: [CForms] Streaming out widget attributes?
Matthias Epheser escribió:
Antonio Gallardo schrieb:
Sylvain Wallez escribió:
- since only CForms has Ajax integration, people are over-using it
for presentation purposes (e.g. paginated repeater)
I agree with you, mixing binding with form definition is not good. We
want to keep it separated. However, I think it is a first
implementation wich show us a way to implement a paginated repeater
after all it is not released yet. It is a work in progress. Is not
fair to blame to a first draft implementation.
I had my thoughts whether the mixing is appropriate or not from the
start, so thank you for your feedback.
Hi,
I am sorry for to things:
1. The way you got the feedback
2. The late of my reply.
As Simone mentioned in his reply, our main goal was to achieve the
lazy-loading of pages. I agree that using the standard binding to
fetch all rows and just display a subset (page) of them could be
easily done with some simple xsl and without changes in the repeater
implementation at all. But we are not focused just on presentation.
Our implementation is a try to load only the row-data we need to
support persistency frameworks and large collections in general.
Currently lazy loading could be achieved without changes in the
controller except using the advanced collection. Editing data is also
possible yet, adding and deleting of rows will follow.
So concerning this I think pageSave/pageLoad has to be done in the
binding because we have to control the doLoad()-method and prevent it
from fetching and creating all rows from the start. To ensure
seperation of concerns we can maybe try to move everything to the
binding.
A RT: We may extend the repeater with an interface to fetch and store
data in different O/R tools. ie: OJB [1], JDO, ibatis [3], etc.
Currently the form-definition is used to enable pagination and and
setting pageSize and so on. This configuration tag could be easily
moved to the binding definition file without problems.
Sure.
The binding registers its pageStorage object in the repeater object
just for one purpose. In the change-page-action I need to call
pageSave and pageLoad.
Yep. This is also the same as for an ajax enabled application when you
try to stay in ajax mode as long as possible. By now, we are bundling as
a form attribute, the javascript flow formModel. This model allows us in
the form definition access the form binding framework. ie: in the
definition we wrote something like the next code to allow user to save
changes without living the form:
Save
var formModel = form.getAttribute("process").form; // Get the
javascript form model
var facade = form.getAttribute("process").facade; // a bean
facade
formModel.save(facade);
facade.save();
}
This way we are able to access the binding framework without a mix. I
don't know if this is the ugliest hack, but solved our needs. :-)
If I manage to access these methods there directly without
repeater.getStorage().doPageLoad() in a decent way, everything would
work just using the binding and without touching the definition and
the repeater itself.
Please let me know what you think about it or if I'm getting something
completely wrong.
Unfortunately, right now, I don't have an opinion out of hand. I think
AJAX form handling is a different beast than traditional MVC form
handling, hence we need to address it in a different way. Your effort
are well appreciated and we expect to help as much as is possible.
Matthias
Best Regards,
Antonio Gallardo
[1] http://db.apache.org/ojb/
[2] http://db.apache.org/jdo/
[3] http://ibatis.apache.org/
Re: [Vote] Release 2.2M1
Jean-Baptiste Quenot escribió: * Antonio Gallardo: Jean-Baptiste Quenot escribió: I made some tests (outside the scope of Cocoon), and encountered problems with Jetty 6 Beta, which appears to be shaky. If you feel confident, then at least be sure to use version >= 6.0.0beta17. Agreed. We had the same problems locally. Few weeks ago, tired of the unstable jetty6 plugin situation, Carlos did a small research and found we don't need to use jetty6 anymore. We can use the stable jetty plugin now: http://www.nabble.com/Important-jetty-plugin-changes-t1900742.html I don't see any information regarding the Jetty servlet container version itself. Neither at the above link nor at the one below: http://jetty.mortbay.org/jetty6/maven-plugin/howto.html What makes you think you can downgrade Jetty? Dropping the "6" on the plugin name doesn't mean anything. The POM still depends on Jetty 6: http://www.mortbay.org/maven2/snapshot/org/mortbay/jetty/maven-jetty-plugin/6.0-SNAPSHOT/maven-jetty-plugin-6.0-20060723.171850-5.pom Cheers, Yep. I took a closer look and you are right, but somehow it is stable since then. Best Regards, Antonio Gallardo.
Re: Voting policies
Now we are getting nit-picky. This page lists three categories; procedural, code modification and package releases. Quite frankly, I don't think this vote has much to do with any of these because: a) procedural to me is a process - such as switching from ant to maven. One could argue from a warped point of view that changing a dependency fits in this category. b) code modification - no code is actually being modified by changing a dependency. (At least yet). c) package releases - well, it is pretty obvious that this doesn't fit. So to be honest, I think this is something the PMC has to decide which process to follow. Having said that, I'd probably lean toward the more restrictive view just to be fair. Ralph Bertrand Delacretaz wrote: On 8/9/06, Mark Lundquist <[EMAIL PROTECTED]> wrote: ...I would expect that if the ASF meant for a negative vote to have veto power, they would have said so explicitly... Which is the case, quoting http://www.apache.org/foundation/voting.html: "Votes on Code Modification For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos and kill the proposal dead until all vetoers withdraw their -1 votes." -Bertrand
Re: Staging Repository
Jorg Heymans wrote:
Reinhard Poetz wrote:
My understanding was that the staging repo is a mirror of everything
under org/apache/cocoon and when we really want to release, we call a
script that copies our changes to the public sync repo or if we want to
roll back, we copy back the changes by copying the content of the sync
repo over our staging repo (we should be able to do this on specific
paths, but that's a detail).
this would work, even though my understanding was that staging->release
repo is a one way process. You deploy to staging and after verification
you _move_ the files simply to release. If you get it wrong, just zap
staging and try again. I just talked with jdcasey on #maven about this,
he said that we should be ok with overwriting metadata.xml as the
element in there is only used for snapshot resolution.
Release artifacts are looked up directly.
ahh, ok. Then there is no need to for keeping our staging repo in sync with the
public sync repo.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Staging Repository
Reinhard Poetz wrote: > My understanding was that the staging repo is a mirror of everything > under org/apache/cocoon and when we really want to release, we call a > script that copies our changes to the public sync repo or if we want to > roll back, we copy back the changes by copying the content of the sync > repo over our staging repo (we should be able to do this on specific > paths, but that's a detail). > this would work, even though my understanding was that staging->release repo is a one way process. You deploy to staging and after verification you _move_ the files simply to release. If you get it wrong, just zap staging and try again. I just talked with jdcasey on #maven about this, he said that we should be ok with overwriting metadata.xml as the element in there is only used for snapshot resolution. Release artifacts are looked up directly. > Have you already written the necessary scripts? nope. Jorg
Re: Staging Repository
Reinhard Poetz wrote: > > I tried it and run into the problem[1] that when I refer to the already > released Cocoon parent artifact (org.apache.cocoon:cocoon:1), the old > value for the distribution repository is taken. Because of this I > accidently deployed the batik parent pom (org.apache.cocoon:batik:1) to > the official Apache sync repo. > Yes you should've deployed our new root pom first and waited for the sync to maven central before deploying any child blocks. > Any ideas how to override the distribution repository from command line > or do we really have to deploy all our pom artifacts just to propagate > the new location? mmm interesting problem... deploying a new root pom potentially triggers a cascade of module pom deployments. We could get around this by making all poms extend the root pom directly, instead of passing via their parent module poms. This would work if we don't intend to use the module poms for anything else but to aggregate the module components. I'll need to think about this. Jorg
Re: Splitting up cocoon-html-impl?
Reinhard Poetz wrote: > > What do you think about splitting up cocoon-html-impl into > cocoon-html-jtidy-impl and cocoon-html-neko-impl? I think it makes sense > as you usually don't need both at the same time. WDOT? > I think doing that will nudge us over a landmark 200+ poms :) Jorg
Re: Re: Voting policies
On 8/9/06, Mark Lundquist <[EMAIL PROTECTED]> wrote: ...I would expect that if the ASF meant for a negative vote to have veto power, they would have said so explicitly... Which is the case, quoting http://www.apache.org/foundation/voting.html: "Votes on Code Modification For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos and kill the proposal dead until all vetoers withdraw their -1 votes." -Bertrand
[JOB] Cforms/Ajax expert needed
Title: [JOB] Cforms/Ajax expert needed We are looking for a contract developer to help extend the Cforms framework with some new widgets and work towards getting these included in future cocoon releases. Our first project is to develop a replacement file upload widget that can handle multiple files with progress indicators. Contact info at www.displayware.com/contactus.html.
Re: [Vote] Java 5 as minimum JDK requirement
Reinhard Poetz wrote: > > As Java 5 was released almost 2 years ago, I propose making it the > minimum requirement for trunk and all artifacts released from there. > +1 What about http://retroweaver.sourceforge.net/ ? With that we could develop for 1.5 and still make a binary version for 1.4 (since, in the end, 1.5 only has "compile time features" that prevent the programmer from making big mistakes, but actually can run on 1.4). Simone -- Simone Gianni
[jira] Subscription: COCOON-open-with-patch
Issue Subscription
Filter: COCOON-open-with-patch (80 issues)
Subscriber: cocoon
Key Summary
COCOON-1879 Make fd:field whitespace trimming behavior configurable
http://issues.apache.org/jira/browse/COCOON-1879
COCOON-1877 [PATCH] Pageable Repeater
http://issues.apache.org/jira/browse/COCOON-1877
COCOON-1870 Lucene block does not store attributes when instructed so
http://issues.apache.org/jira/browse/COCOON-1870
COCOON-1869 MailMessageSender.java eats exception chain - which does not allow
for proper dubuging and logging
http://issues.apache.org/jira/browse/COCOON-1869
COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the
rigth time with IE
http://issues.apache.org/jira/browse/COCOON-1846
COCOON-1843 LDAPTransformer: add-entry tag doesn't work
http://issues.apache.org/jira/browse/COCOON-1843
COCOON-1842 LDAPTransformer: ClassCastException with Binary fields
http://issues.apache.org/jira/browse/COCOON-1842
COCOON-1838 Always use 3-digit version number
http://issues.apache.org/jira/browse/COCOON-1838
COCOON-1811 [PATCH] Flow Script: Allow dynamic loading of JavaScript objects
even when scope is locked
http://issues.apache.org/jira/browse/COCOON-1811
COCOON-1810 [PATCH] JMSEventMessageListener does not work
http://issues.apache.org/jira/browse/COCOON-1810
COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and
implementation of a move-node binding
http://issues.apache.org/jira/browse/COCOON-1794
COCOON-1776 [PATCH]Reload Bookmarks on bookmark file validity
http://issues.apache.org/jira/browse/COCOON-1776
COCOON-1738 double-listbox problem in repeaters
http://issues.apache.org/jira/browse/COCOON-1738
COCOON-1726 Implementation of Source that supports conditional GETs
http://issues.apache.org/jira/browse/COCOON-1726
COCOON-1717 Use custom cache keys for caching uri coplets using input modules.
http://issues.apache.org/jira/browse/COCOON-1717
COCOON-1706 Allow TeeTransformer to run a system command for debugging purposes
http://issues.apache.org/jira/browse/COCOON-1706
COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text
orientation, color code fix, prefered unit for margins and measure unit
converter
http://issues.apache.org/jira/browse/COCOON-1703
COCOON-1697 Allow request parameters to be used in "for (var k in h)" kind of
Javascript Loops
http://issues.apache.org/jira/browse/COCOON-1697
COCOON-1692 [PATCH] Tree widget not handling on-selection-change events
correctly.
http://issues.apache.org/jira/browse/COCOON-1692
COCOON-1686 [PATCH] COCOON-1671 Form not binding when prefix in binding
definition is unequal to that in the instance data for the same namespace.
http://issues.apache.org/jira/browse/COCOON-1686
COCOON-1648 Add support for ISO8601 in I18nTransformer and Forms
http://issues.apache.org/jira/browse/COCOON-1648
COCOON-1622 [PATCH] SendMailTransformer and HTML body
http://issues.apache.org/jira/browse/COCOON-1622
COCOON-1618 [PATCH] SoapGenerator/Serializer for Axis Block
http://issues.apache.org/jira/browse/COCOON-1618
COCOON-1611 [PATCH] Add additonal constructor to FormInstance.java to be able
to pass a locale
http://issues.apache.org/jira/browse/COCOON-1611
COCOON-1603 [PATCH] handling of alternatives in MailTransformer
http://issues.apache.org/jira/browse/COCOON-1603
COCOON-1573 Improvement SetAttributeJXPathBinding and Contribution
SetNodeValueJXPathBinding
http://issues.apache.org/jira/browse/COCOON-1573
COCOON-1557 [PATCH] Change access to AbstractContinuable.getContext to protected
http://issues.apache.org/jira/browse/COCOON-1557
COCOON-1556 [PATCH] Add a JXPathConvertor for conversion betwean beans and
Strings
http://issues.apache.org/jira/browse/COCOON-1556
COCOON-1535 [PATCH] enhancement to {global:} input module: return all sitemap
globals
http://issues.apache.org/jira/browse/COCOON-1535
COCOON-1527 [PATCH] Cache control logic sheets for XSP to override getKey and
getValidity
http://issues.apache.org/jira/browse/COCOON-1527
COCOON-1526 [PATCH] processToDOM returns a read-only DOM
http://issues.apache.org/jira/browse/COCOON-1526
COCOON-1519 [PATCH] TeeTransformer refactoring
http://issues.apache.org/jira/browse/COCOON-1519
COCOON-1508 [PATCH] Avalonize TranscoderFactory
http://issues.apache.org/jira/browse/COCOON-1508
COCOON-1506 [PATCH] Manually specifying a mounted sitemap's context
http://issues.apache.org/jira/browse/COCOON-1506
COCOON-1488 [PATCH] htmlunit-based testing, needs to be ported to 2.2
http://issues.apache.org/jira/browse/COCOON-1488
COCOON-1467 ESQL exception handling p
Re: cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null])
* Marc Portier: > Anyways, this whole process of finding out what and how kind of > convinced me that we can in fact revert the change. (and not add > an attribute) That is the simple way. But ending up with empty tags for all widgets having the null value is not satisfactory. And this also means that every convertor must check null *and* empty string. This also means that if you turn off leniency in the FormattingDateConvertor with lenient="false" attribute, you're SOL. Anyway, let's close the discussion... I won't take the time to add the knob because I don't use this binding API anymore. If someone shows interest we can always add it later. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null])
Jean-Baptiste Quenot wrote: > * Marc Portier: > >> The argumentation of the fix, namely to make the value-binding >> remove an element upon 'save' seems, currently, to be that this >> avoids after re-'load' some weird formatting result (from "" to >> "1/1/1970") in the i18n transformer caused by some external >> date-parser suggested in a patch that isn't applied? > > You may be right that the date problem may not happen with > SimpleDateFormat because it is lenient by default. This has > nothing to do with the i18n transformer however, but with the > FormattingDateConvertor. > ok, makes sense obvious question then of course is why that formatting-convertor couldn't be made to capture the 'null' and circumvent the replacement to this '0' 'or 1/1/1970? > Now it's up to you to decide whether empty string is garbage or > not. For me, it is. Then your proposal to add an option to > instruct CForms to remove the XML node or to leave it empty makes > sense. > well, I don't think it is garbage at all, it's a hook to add e.g. attribute-nodes, those have reason of existence regardless of the fact that there is a nested text-node or not. suppose you don't have the flexibility to design the input-xml coming from your backend and it doesn't look like that can be optionally removed, but actually looks like then you'll need to solve your issue differently as well so I guess even for you it's only garbage in this particular case, no? > Anyway I should have been more careful when committing this > incompatible change, as you're right most Cocoon users may not > have been impacted by this problem. no worries, mate, I'm glad we're taking and finding time and patience to get to the core of this. Anyways, this whole process of finding out what and how kind of convinced me that we can in fact revert the change. (and not add an attribute) In the event that somebody might want to remove the element when the nested text-node would be empty, then he/she should do so through the nested on-update: .. the logic to remove the path if new value is null, I understand that this is more typing then just adding a @remove-if-null="true" (which was my earlier idea), but it's the kind of explicitness that both holds more flexibility and fits better my feeling that the ValueBinding by itself should not be altering the xml structure. wdyt? regards, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Java 5 as minimum JDK requirement
On Aug 9, 2006, at 3:56 AM, David Crossley wrote: Reinhard Poetz wrote: As Java 5 was released almost 2 years ago, I propose making it the minimum requirement for trunk and all artifacts released from there. +1 ... although it might limit our user base, i reckon that Cocoon 2.2 should move on. +1 —ml—
Re: Voting policies
On Aug 9, 2006, at 7:35 AM, Leszek Gawron wrote: Reinhard Poetz wrote: As the chair of this project I should probably know it better but I wonder whether we have a project policy that contains guidelines about vote resulting. Does the -1 of Jörg mean that the Java 5 proposal is rejected? Looks like you're right. Consensus means 100% agreed to the proposition. Traditionally, consensus is not synonymous w/ unanimity. (Unless, of course, this terms has some kind of special meaning local to ASF history/culture... I presume that it does not). See http://en.wikipedia.org/wiki/Consensus_decision-making ...and in particular, http://en.wikipedia.org/wiki/Consensus_decision-making#If_consensus_is_not_unanimous.2C_who_must_agree.3F Also, I would expect that if the ASF meant for a negative vote to have veto power, they would have said so explicitly. Cheers, —ml—
Re: Splitting up cocoon-html-impl?
On Aug 9, 2006, at 1:27 AM, Reinhard Poetz wrote: What do you think about splitting up cocoon-html-impl into cocoon-html-jtidy-impl and cocoon-html-neko-impl? I think it makes sense as you usually don't need both at the same time. WDOT? +1 IMHO this principle should be followed in general, viz. alternative implementations packaged separately. —ml—
Re: cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null])
* Marc Portier: > The argumentation of the fix, namely to make the value-binding > remove an element upon 'save' seems, currently, to be that this > avoids after re-'load' some weird formatting result (from "" to > "1/1/1970") in the i18n transformer caused by some external > date-parser suggested in a patch that isn't applied? You may be right that the date problem may not happen with SimpleDateFormat because it is lenient by default. This has nothing to do with the i18n transformer however, but with the FormattingDateConvertor. Now it's up to you to decide whether empty string is garbage or not. For me, it is. Then your proposal to add an option to instruct CForms to remove the XML node or to leave it empty makes sense. Anyway I should have been more careful when committing this incompatible change, as you're right most Cocoon users may not have been impacted by this problem. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Voting policies
Reinhard Poetz wrote: As the chair of this project I should probably know it better but I wonder whether we have a project policy that contains guidelines about vote resulting. Does the -1 of Jörg mean that the Java 5 proposal is rejected? Looks like you're right. Consensus means 100% agreed to the proposition. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null])
Jean-Baptiste Quenot wrote: > * Marc Portier: >> >> Jean-Baptiste Quenot wrote: >>> * Marc Portier: >>> Coming back to that original date issue in fact I'm afraid I don't get it yet completely? At which time is this 'org.w3c.util.DateParser' active? How does this become a problem of the binding? >>> CForms was generating , which is not a valid date. >>> It is interpreted as time 0. This is when binding a date widget. >> Well, I still don't get it >> >> Not a valid date for who? Some back-end processing the xml afterwards? >> >> I've just done a small test which shows cforms is perfectly happy to >> bind to some or in the xml... > > OK, and then, what is the date displayed? Say for example the > date is an optional field. You leave it blank, the XML is saved > with empty tag, and then you edit it again. What is displayed? > an empty input-box, and quite unsurprisingly too! >> I also find no references to this mentioned org.w3c.util.DateParser in >> the cocoon code-base, I couldn't even find it in any of the jars we >> distribute... (actually outside cocoon the only references I've found >> to it so far are jigsaw and some css-validator) > > This is part of another patch, see > Add support for ISO8601 in I18nTransformer and Forms > http://issues.apache.org/jira/browse/COCOON-1648 ah, thx, for explaining, but: that patch is not applied, is it? The issue is still open? and to clarify my results, guess what: my test isn't using i18n. Put rather bluntly, here is my current understanding: The argumentation of the fix, namely to make the value-binding remove an element upon 'save' seems, currently, to be that this avoids after re-'load' some weird formatting result (from "" to "1/1/1970") in the i18n transformer caused by some external date-parser suggested in a patch that isn't applied? And even if it would be in the codebase: what if people use this i18n transformer without cforms or the binding framework? What if the XML was never saved before, but just has an empty date element in there? what else am I missing here? -marc= (puzzled) -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Voting policies
On 8/9/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: ...Does the -1 of Jörg mean that the Java 5 proposal is rejected?... ...I'd say yes because a) Jörg gave some good reasons not to switch and b) there are no majority votes but we always need consensus. Hence we have to find a way to gather consensus. Right?.. That's my understanding as well, -1 means veto IIUC. -Bertrand
Voting policies
As the chair of this project I should probably know it better but I wonder
whether we have a project policy that contains guidelines about vote resulting.
Does the -1 of Jörg mean that the Java 5 proposal is rejected?
Quoting http://www.apache.org/foundation/how-it-works.html#management:
"The rules require that a negative vote includes an alternative proposal or a
detailed explanation of the reasons for the negative vote.
The community then tries to gather consensus on an alternative proposal that
resolves the issue. In the great majority of cases, the concerns leading to the
negative vote can be addressed.
This process is called 'consensus gathering' and we consider it a very important
indication of a healthy community."
According to these paragraphs I'd say yes because a) Jörg gave some good reasons
not to switch and b) there are no majority votes but we always need consensus.
Hence we have to find a way to gather consensus. Right?
(Please don't use this thread to discuss the specific problem of whether we
should make Java 5 the minimum JDK requirement. Thanks!)
--
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: [Vote] Java 5 as minimum JDK requirement
Carsten Ziegeler wrote: Ralph Goers wrote: The folks who are decided to maintain their blocks this way did it with the clear understanding that this was the price they would have to pay, so I don't think the clarification is necessary. I can recall at least one instance where a change to one of these blocks had to be backed or modified because it broke the 2.1.x branch. Remember, we voted a while ago for trunk to only support 1.4 and up while 2.1.x supports 1.3, so this problem already exists. Yepp, and I think as soon as we have 2.2 out, we should not share these blocks with 2.1.x anymore as all new features should go to 2.2 only. 2.1.x is then a real maintenance branch where we only do minor improvements and bugfixing. Cool, thanks guys for the clarification. My +1 stands then. :-)
Re: cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null])
* Marc Portier: > > > Jean-Baptiste Quenot wrote: > > * Marc Portier: > > > >> Coming back to that original date issue in fact I'm afraid > >> I don't get it yet completely? At which time is this > >> 'org.w3c.util.DateParser' active? How does this become a > >> problem of the binding? > > > > CForms was generating , which is not a valid date. > > It is interpreted as time 0. This is when binding a date widget. > > Well, I still don't get it > > Not a valid date for who? Some back-end processing the xml afterwards? > > I've just done a small test which shows cforms is perfectly happy to > bind to some or in the xml... OK, and then, what is the date displayed? Say for example the date is an optional field. You leave it blank, the XML is saved with empty tag, and then you edit it again. What is displayed? > I also find no references to this mentioned org.w3c.util.DateParser in > the cocoon code-base, I couldn't even find it in any of the jars we > distribute... (actually outside cocoon the only references I've found > to it so far are jigsaw and some css-validator) This is part of another patch, see Add support for ISO8601 in I18nTransformer and Forms http://issues.apache.org/jira/browse/COCOON-1648 -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null])
Jean-Baptiste Quenot wrote: > * Marc Portier: > >> Coming back to that original date issue in fact I'm afraid >> I don't get it yet completely? At which time is this >> 'org.w3c.util.DateParser' active? How does this become a >> problem of the binding? > > CForms was generating , which is not a valid date. > It is interpreted as time 0. This is when binding a date widget. Well, I still don't get it Not a valid date for who? Some back-end processing the xml afterwards? I've just done a small test which shows cforms is perfectly happy to bind to some or in the xml... I also find no references to this mentioned org.w3c.util.DateParser in the cocoon code-base, I couldn't even find it in any of the jars we distribute... (actually outside cocoon the only references I've found to it so far are jigsaw and some css-validator) As things stand I can't help getting more and more - unsure about what the actual motivation for this change was, - convinced that the chosen resolution which makes fb:value not maintain the xml structure is actually way too drastic - close to doubting we should even support this date-issue -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Splitting up cocoon-html-impl?
Reinhard Poetz wrote: What do you think about splitting up cocoon-html-impl into cocoon-html-jtidy-impl and cocoon-html-neko-impl? I think it makes sense as you usually don't need both at the same time. WDOT? +1 Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: Staging Repository
Jorg Heymans wrote:
Jorg Heymans wrote:
Just agreed on this with Reinhard off-list, i'll make the required changes.
ok this is done now. I hope i got the permissions right (g+w and o+w on
all dirs involved, including my home dir).
Can someone please give it a spin ?
Is it on purpose that the cocoon-staging-repository is completly empty?
> pwd
/x1/home/jheymans/public_html/cocoon-staging-repository
> ls -lsa
total 4
2 drwxrwxrwx 2 jheymans jheymans 512 Aug 8 10:08 .
2 drwxrwxrwx 3 jheymans jheymans 512 Aug 8 10:08 ..
My understanding was that the staging repo is a mirror of everything under
org/apache/cocoon and when we really want to release, we call a script that
copies our changes to the public sync repo or if we want to roll back, we copy
back the changes by copying the content of the sync repo over our staging repo
(we should be able to do this on specific paths, but that's a detail).
Have you already written the necessary scripts?
--
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: [Vote] Java 5 as minimum JDK requirement
Reinhard Poetz wrote: > > As Java 5 was released almost 2 years ago, I propose making it the minimum > requirement for trunk and all artifacts released from there. +1 ... although it might limit our user base, i reckon that Cocoon 2.2 should move on. This will have impact for Forrest, as we use trunk. We can move forward to use the recent 2.2 release. If we decide Java 5 too, then we can move on. -David
Re: Cocoon 2.2 and Java 5
Jean-Baptiste Quenot wrote: > * David Crossley: > > > This will have impact for Forrest, as we use trunk. > > You do? Then tell me how you use it, because IIRC Forrest uses > Cocoon CLI. How to use it in trunk as the shell script has gone > away? We do use Cocoon trunk 2.2, but still stuck at an old version pre-Maven. That stopped us upgrading. I finally got the Maven build just before Cocoon released 2.2, so have been starting to upgrade our packaged Cocoon. Lots of hurdles but getting closer. Yes, Forrest does use the CLI but at this stage i am focussing on Forrest's other dynamic uses. We run Cocoon in a packaged Jetty ... 'forrest run'. We also use Cocoon as a war file in a full Jetty/Tomcat. So we need to catch up with a more recent Cocoon-2.2 -David
Re: [vote] Use servlet API 2.4 in trunk
Reinhard Poetz wrote: > > I propose switching to servlet API 2.4 in *trunk*. This shouldn't > cause any problems as a stable version of Tomcat (5.0.16), the > reference implementation for servlet containers, is available since > Dec, 4th 2003. > +1
Re: Cocoon 2.2 and Java 5
* David Crossley: > This will have impact for Forrest, as we use trunk. You do? Then tell me how you use it, because IIRC Forrest uses Cocoon CLI. How to use it in trunk as the shell script has gone away? -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: Cocoon 2.2 and Java 5
Reinhard Poetz wrote: > > What do people think about making Java 5, which was released almost _2 > years ago_, the minimum requirement for trunk? +1 ... although it might limit our user base, i reckon that Cocoon 2.2 should move on. This will have impact for Forrest, as we use trunk. We can move forward to use the recent 2.2 release. If we decide Java 5 too, then we can move on. -David
Re: Staging Repository
Reinhard Poetz wrote:
Jorg Heymans wrote:
Jorg Heymans wrote:
Just agreed on this with Reinhard off-list, i'll make the required
changes.
ok this is done now. I hope i got the permissions right (g+w and o+w on
all dirs involved, including my home dir).
Can someone please give it a spin ?
I'll give it a try tommorrow and let you know whether it works for me.
I tried it and run into the problem[1] that when I refer to the already released
Cocoon parent artifact (org.apache.cocoon:cocoon:1), the old value for the
distribution repository is taken. Because of this I accidently deployed the
batik parent pom (org.apache.cocoon:batik:1) to the official Apache sync repo.
Any ideas how to override the distribution repository from command line or do we
really have to deploy all our pom artifacts just to propagate the new location?
If there is no way we should find the final location of our sync repo as the
current solution /home/jheymans/public_html/cocoon-staging-repository is of
course just a temporary solution. This way we only have to deploy all the pom
artifacts just once again.
--
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: Splitting up cocoon-html-impl?
* Reinhard Poetz: > What do you think about splitting up cocoon-html-impl into > cocoon-html-jtidy-impl and cocoon-html-neko-impl? I think it > makes sense as you usually don't need both at the same > time. WDOT? I read your post after committing updates to trunk: I ported the work at https://issues.apache.org/jira/browse/COCOON-1639 Feel free to split the blocks if you wish. That makes sense. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null])
* Antonio Gallardo: > Jean-Baptiste Quenot escribió: > >Namely and are known to be broken > >in some cases. > > > Would you provide a test case in order to fix it and avoid a regression in > the future? :-) Not a testcase, but some facts. About : http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/binding/MultiValueJXPathBinding.java?view=markup Look at the TODO in the code. You will see that the XPath expression gets appended the row positions. Example if the row-path is "entry": entry[1] entry[2] entry[3] ... Then what about a row-path "entry/@value": entry/@value[1] entry/@value[2] entry/@value[3] ... It doesn't make sense so basically the whole code is broken. About : There is a user experience related here, but I know many users that avoid like the plague: http://marc2.theaimsgroup.com/?l=xml-cocoon-users&m=111757381624547&w=2 Basically you need to use instead, without support for however, useless anyway when binding to XML IMO. -- Jean-Baptiste Quenot aka John Banana Qwerty http://caraldi.com/jbq/
Re: [vote] Use servlet API 2.4 in trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 8 Aug 2006, Reinhard Poetz wrote: I propose switching to servlet API 2.4 in *trunk*. This shouldn't cause any problems as a stable version of Tomcat (5.0.16), the reference implementation for servlet containers, is available since Dec, 4th 2003. +1 - -- 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.5 (GNU/Linux) iD8DBQFE2agZLNdJvZjjVZARAtjQAJ9gmTd5eL32x9DqIEnzm+R7Ep0bcwCfaMaK zcAZPetaLX06ozJCgI3V/u4= =uA01 -END PGP SIGNATURE-
Re: [Vote] Java 5 as minimum JDK requirement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 8 Aug 2006, Reinhard Poetz wrote: As Java 5 was released almost 2 years ago, I propose making it the minimum requirement for trunk and all artifacts released from there. +1 - -- 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.5 (GNU/Linux) iD8DBQFE2af8LNdJvZjjVZARAqrVAKDKrbP83/H7Y3yNS7Ff6mxGwIOyVgCgkEM6 iNLvm2J3R9zNqlGRMwUT+Xc= =kdRs -END PGP SIGNATURE-
[jira] Closed: (COCOON-1639) [patch] NekoHTMLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1639?page=all ] Jean-Baptiste Quenot closed COCOON-1639. Fix Version/s: 2.2-dev (Current SVN) 2.1.9 Resolution: Fixed Ported to trunk. Please test! > [patch] NekoHTMLTransformer > --- > > Key: COCOON-1639 > URL: http://issues.apache.org/jira/browse/COCOON-1639 > Project: Cocoon > Issue Type: Improvement > Components: Blocks: HTML >Affects Versions: 2.1.8 > Environment: Operating System: All > Platform: All >Reporter: Andrew Stevens > Assigned To: Jean-Baptiste Quenot >Priority: Minor > Fix For: 2.2-dev (Current SVN), 2.1.9 > > Attachments: cocoon.log, combined.diff, htmlblock.diff, > neko.properties, neko.properties, NekoHTMLTransformer.java, > NekoHTMLTransformer.java, samples.diff > > > The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator > and... > hey, where's the NekoHTMLTransformer? > So, just to complete the set, here's one I prepared earlier :-) > I've also included an (empty) neko.properties configuration file, and updated > the neko generator's setup bits to allow for setting parser features as well > as > properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Splitting up cocoon-html-impl?
On 8/9/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: ...What do you think about splitting up cocoon-html-impl into cocoon-html-jtidy-impl and cocoon-html-neko-impl? I think it makes sense as you usually don't need both at the same time. WDOT?... +0, cannot help but it's a good idea. -Bertrand
Re: Splitting up cocoon-html-impl?
Reinhard Poetz wrote: > What do you think about splitting up cocoon-html-impl into > cocoon-html-jtidy-impl and cocoon-html-neko-impl? I think it makes sense as > you > usually don't need both at the same time. WDOT? > +1 Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Vote] Java 5 as minimum JDK requirement
Antonio Gallardo wrote:
Jason Johnston escribió:
On Tue, 2006-08-08 at 08:05 -0600, Jason Johnston wrote:
Reinhard Poetz wrote:
As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.
+1
Thinking about this a bit more, I have a question.
As I understand it there are several blocks (CForms comes to mind) that
are shared between trunk and the 2.1.x branch via svn:external
properties. Unless I'm mistaken this would prevent the minimum JDK
requirement from being raised for these blocks, since it would affect
the branch where Java 1.3 is still supported. Using any new JDK
features in these blocks would break that 1.3 support in the branch.
Should the vote be qualified with an "...except for those blocks that
are shared by the 2.1.x branch"?
Good point. BTW, what if we vote to upgrade 2.1. branch to at least 1.4?
:-)
I don't see much value in this as we should stop to add new features to the
2.1.x branch rather sooner than later. I guess that there will only be one
further _planned_ release (2.1.10) and then we should only backport critical bug
fixes and release on demand.
--
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: [Vote] Java 5 as minimum JDK requirement
Carsten Ziegeler wrote:
Ralph Goers wrote:
The folks who are decided to maintain their blocks this way did it with
the clear understanding that this was the price they would have to pay,
so I don't think the clarification is necessary. I can recall at least
one instance where a change to one of these blocks had to be backed or
modified because it broke the 2.1.x branch. Remember, we voted a while
ago for trunk to only support 1.4 and up while 2.1.x supports 1.3, so
this problem already exists.
Yepp, and I think as soon as we have 2.2 out, we should not share these
blocks with 2.1.x anymore as all new features should go to 2.2 only.
2.1.x is then a real maintenance branch where we only do minor
improvements and bugfixing.
completly agreed
--
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
Splitting up cocoon-html-impl?
What do you think about splitting up cocoon-html-impl into
cocoon-html-jtidy-impl and cocoon-html-neko-impl? I think it makes sense as you
usually don't need both at the same time. WDOT?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: [Vote] Ard Schrijvers as a new Cocoon committer
On 08 Aug 2006, at 15:37, Giacomo Pati wrote: late but wholeheartedly +1 :-) ditto (been on holidays) congrats! -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java & XML stevenn at outerthought.orgstevenn at apache.org
Re: My first steps with cocoon 2.2 mavenized application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 2 Aug 2006, Reinhard Poetz wrote: Date: Wed, 02 Aug 2006 07:12:17 +0200 From: Reinhard Poetz <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: My first steps with cocoon 2.2 mavenized application Leszek Gawron wrote: Leszek Gawron wrote: > Reinhard Poetz wrote: > > > Does that mean that even simplest application needs 2 maven modules? > > > > not necessarily but it is recommended (IMO). If you put all your code > > into the /src/main/java and /src/main/webapp directories it should > > work too. If so wouldn't it be a good idea to provide an archetype that would create both a webapp and a block and additionally a main pom file? We used the webapp archetype and stuffed it with our java code as within normal Maven 2 src/main/java When building you need the install phase to make that code into the webapp structure: mvn clean install cocoon:deploy-war and ready is your WAR File HTH Giacomo - -- 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.5 (GNU/Linux) iD8DBQFE2ZjFLNdJvZjjVZARAje+AKCNKLFQ3I1hyjmzT5OTNMfEYisxmACg9Hov +ev4ML5n9OZE8WE+bLbiOUU= =RSA0 -END PGP SIGNATURE-
