Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of mfncooper@gmail.com
 designates 209.85.146.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:references:x-google-sender-auth;
        b=fEmZBeZ9shcI9Xp5xTfboSgyqYc8i3UKeeURPJksJj8mNkcRNoecjALwWFQUAxiL3l
         jrTopOMDR9mgNofRaiUgMcdrFcrs7d6QzEztH2MxXP7rCsTmtV0hrkYwjGix0SzBVvuX
         MWHdgy05LUqaLK2mLZK07sk8ZhhS4i0DD1YoU=
Message-ID: <16d6c6200806081046s7650bb69u7db5e33a9d152d54@mail.gmail.com>
Date: Sun, 8 Jun 2008 10:46:40 -0700
From: "Martin Cooper" <martinc@apache.org>
Sender: mfncooper@gmail.com
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: [POLL] Drop strutsel package from 1.4?
In-Reply-To: <b9e663070806072216w632ed700vb378cb07f96d791e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_13221_5059451.1212947200873"
References: <b9e663070806060539y2772a821yeb8b6f85bb37b608@mail.gmail.com>
	 <55afdc850806060831l2ad4a8d7yc801b75bda327794@mail.gmail.com>
	 <adba96190806060920q15384770o2968039685ace353@mail.gmail.com>
	 <b9e663070806061025h225bc42frb078234d74191de9@mail.gmail.com>
	 <b9e663070806072126m7833307bt7e38f2e543994433@mail.gmail.com>
	 <16d6c6200806072143y18deb8d1y9bbe4083c9239bb2@mail.gmail.com>
	 <b9e663070806072153p4014fe33i5af421a00d328357@mail.gmail.com>
	 <16d6c6200806072201m4446e50au32514d0cdb7c8060@mail.gmail.com>
	 <b9e663070806072216w632ed700vb378cb07f96d791e@mail.gmail.com>

------=_Part_13221_5059451.1212947200873
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sat, Jun 7, 2008 at 10:16 PM, Paul Benedict <pbenedict@apache.org> wrote:

> Martin, would you find it acceptable to leave them where they are and just
> relegate them to an optional build profile? That probably makes most sense;
> if we still want them buildable (I think we do), then they really aren't
> "inactive".


Yep, that sounds fine to me.

--
Martin Cooper


>
> Paul
>
> On Sun, Jun 8, 2008 at 12:01 AM, Martin Cooper <martinc@apache.org> wrote:
>
> > On Sat, Jun 7, 2008 at 9:53 PM, Paul Benedict <pbenedict@apache.org>
> > wrote:
> >
> > > Martin,
> > >
> > > If we physically move them out of the struts1 folder (archive is
> sibling
> > to
> > > struts1), then they can no longer be part of the build process if
> > desired.
> > > I
> > > wasn't expecting to cut the life-cord that far! :-) but you desire
> > > differently?
> >
> >
> > As far as I'm concerned, it can stay where it is or it can move to
> archive.
> > I don't have a strong opinion one way or the other. What I object to is
> > multiple flavours of "inactive" within a single project.
> >
> > --
> > Martin Cooper
> >
> >
> > > Paul
> > >
> > > On Sat, Jun 7, 2008 at 11:43 PM, Martin Cooper <martinc@apache.org>
> > wrote:
> > >
> > > > As has already been pointed out, we already have a location for
> dormant
> > > > projects. It's called "archive". I am opposed (-1, if you must) on
> > having
> > > > two locations for inactive sub-projects.
> > > >
> > > > --
> > > > Martin Cooper
> > > >
> > > >
> > > > On Sat, Jun 7, 2008 at 9:26 PM, Paul Benedict <pbenedict@apache.org>
> > > > wrote:
> > > >
> > > > > If other committers haven't chimed in (or want to chime in again
> :-)
> > )
> > > > > please do. I think I will be making these changes eventually:
> > > > >
> > > > > * Move "el" project to "dormant" subfolder
> > > > > * Move "faces" project to "dormant" subfolder
> > > > > * Add a profile that builds them specifically
> > > > > * Up to the future whether the profile is included in the release
> > > build.
> > > > >
> > > > > Paul
> > > > >
> > > > > On Fri, Jun 6, 2008 at 12:25 PM, Paul Benedict <
> pbenedict@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > I started this poll because it is, to Wendy's point, double work
> to
> > > > > > maintain the tag libraries. For every change, I have to update
> two
> > > > source
> > > > > > files -- either two Java or two TLD. Because people have noticed
> in
> > > the
> > > > > past
> > > > > > when the two libraries are not in sync, I was looking for a way
> to
> > > > "move
> > > > > > forward" but not kill anyone in the water. Just looking for a
> good
> > > > > > answer....
> > > > > >
> > > > > > Would a better compromise be to move them into a dormant
> subproject
> > > > (like
> > > > > > apps)? I'd also like to do this with the "faces" module too,
> since
> > > > Craig
> > > > > was
> > > > > > the only committer and dropped support years ago. I am more than
> > > > willing
> > > > > to
> > > > > > continue releasing them as such, but do want to relegate them to
> > > > > > second-class projects.
> > > > > >
> > > > > > Paul
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 6, 2008 at 11:20 AM, Wendy Smoak <wsmoak@gmail.com>
> > > wrote:
> > > > > >
> > > > > >> On Fri, Jun 6, 2008 at 8:31 AM, Niall Pemberton
> > > > > >> <niall.pemberton@gmail.com> wrote:
> > > > > >>
> > > > > >> > I guess I'm just wondering what harm does it do leaving it in
> > the
> > > > > >> > release and the benefit is that it allows people with legacy
> > apps
> > > > > >> > dependant on it to upgrade with no pain.
> > > > > >>
> > > > > >> It seems to require double work to maintain both taglibs.  As
> long
> > > as
> > > > > >> someone is willing to do that work, it can stay...
> > > > > >>
> > > > > >> Honestly, how many apps do you think will upgrade to 1.4?  I bet
> > > most
> > > > > >> of them are still back on 1.1/1.2, and aren't going anywhere. :)
> > > > > >>
> > > > > >> --
> > > > > >> Wendy
> > > > > >>
> > > > > >>
> > > ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > > >> For additional commands, e-mail: dev-help@struts.apache.org
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

------=_Part_13221_5059451.1212947200873--