>> We have a local M2 repo today for 1.5.3 and 1.5.4-SNAPSHOT. This is not an
issue and is quite simple to setup.

We have Artifactory internally ourselves.

>> However, I disagree that a local M2 repo will make locally forked code
releases easier to manage...Sure - it would help with the deployment of such
forked code - but that is a deployment issue that has nothing to do with the
argument for / against forking code.

I was speaking more in context of deployment, not managing the forked code
and patching with each new release, as you clarified.

Tim


On 6/3/10 1:06 PM, "Nikolaos (JIRA)" <[email protected]> wrote:
> 
> Timothy,
> 
> I agree with all the standards stuff you mention... however this comment:
> 
>>> >> However, when Stripes can be released through Maven, this would make
>>> locally forked JAR releases easier to manage through a local Maven
>>> repository.
> 
> Is odd.  We have a local M2 repo today for 1.5.3 and 1.5.4-SNAPSHOT.  This is
> not an issue and is quite simple to setup.  Ask me offline if you like.
> 
> However, I disagree that a local M2 repo will make locally forked code
> releases easier to manage.  You still will need to manage the patch and apply
> the patch to each and every release and the code will be forked which is a
> major maintenance problem in itself that a local M2 repo will not solve.  Sure
> - it would help with the deployment of such forked code - but that is a
> deployment issue that has nothing to do with the argument for / against
> forking code.  Just my 2 cents....
> 
>> > Add support ala Struts to generate HTML or XHTML compliant close tags
>> > ---------------------------------------------------------------------
>> >
>> >                 Key: STS-751
>> >                 URL: http://www.stripesframework.org/jira/browse/STS-751
>> >             Project: Stripes
>> >          Issue Type: Improvement
>> >          Components: Tag Library
>> >    Affects Versions: Release 1.5
>> >         Environment: No specific OS required;  no specific Java version
>> required;  etc...
>> >            Reporter: Nikolaos
>> >            Priority: Minor
>> >         Attachments: stripes-xhtml-patch.tar.gz,
>> stripes-xhtml-patches.tar.gz
>> >
>> >
>> > HTML and XHTML documents have some key differences.
>> > For example - if we consider the <input> tag:
>> > - In HTML, the <input> tag has no end tag   e.g. <input name="website.url"
>> type="text" size="30">
>> > - In XHTML, the <input> tag must be properly closed, like this <input />
>> e.g. <input name="website.url" type="text" size="30" />
>> > Stripes 1.5.x however does not have a mechanism to discern whether or not
>> to properly close tags or not and as such takes the safer approach which is
>> to explicitly close tags as it results in valid XHTML and is not an error for
>> HTML but results in a warning when validating HTML documents.  Although the
>> latter is not a critical issue it does result in needless or unnecessary
>> complaints when validating and as such is an annoyance albeit minor.
>> > Struts since 1.x has solved this issue quite easily by allowing the
>> inclusion of the xhtml="true" attribute to mark that closure is required
>> (false indicates no closure).  In this manner authors of XHTML and HTML
>> documents are equally satisfied in not having any errors or extraneous
>> warnings.
>> > Timothy Stone had reported this issue and classified it as a bug here:
>> > 
>> http://www.stripesframework.org/jira/browse/STS-556?page=com.atlassian.jira.p
>> 
lugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11931#action_11>>
931
>> > The issue was rightly closed as "Not a bug" as most of the discussion was
>> based on a non-w3c validator which yielded results that considered the
>> validation unsuccessful which is not the case with the w3c validator (not to
>> mention that it is irrelevant whether or not XHTML is considered dead or we
>> should align to HTML 5 - etc...).
>> > As such this issue report is a re-statement of the above closed issue
>> reported as an improvement and setting the stage for patch to be attached.
> 
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://www.stripesframework.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> 
>        
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Stripes-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-development
> 
> 

-- 
Timothy Stone   |   Director, Application Developer Technical Lead
Barclaycard   |    Business Technology Group, Solutions Delivery
125 S. West Street   |   Wilmington, DE    |   19801
USA   |   www.barclaycardus.com
+1 302 255 8044 direct |   +1 410 441 9450 cell
 
COMPANY CONFIDENTIAL
 
P Before printing this e-mail, or any other document, ask yourself whether
you need a hard copy



Barclays             www.barclaycardus.com

This e-mail and any files transmitted with it may contain confidential and/or 
proprietary information. It is intended solely for the use of the individual or 
entity who is the intended recipient. Unauthorized use of this information is 
prohibited. If you have received this in error, please contact the sender by 
replying to this message and delete this material from any system it may be on.

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development

Reply via email to